Today I discovered an interesting inconsistency in Activity Streams specs while investigating a Fedify issue.

The question: How should we interpret URLs like "icon": "https://example.com/avatar.png"?

JSON-LD context (https://www.w3.org/ns/activitystreams): @type: "@id" → “This is an IRI reference, dereference it to fetch an ActivityStreams object.”

Activity Streams Primer: “assume that a bare string is the href of a Link object, not an id” (no dereferencing)

Result: JSON-LD processor-based implementations try to parse PNG files as JSON and fail.

Turns out w3c/activitystreams#595 already discusses the same issue for href properties. I added a note that icon, image, etc. have the same problem.

Once again reminded of how tricky spec work can be…

#ActivityPub #Fedify #ActivityStreams #fedidev #specifications

@hongminhee It's a place where our loosey goosey style goes into nondeterminism. We should tighten it up in the next version. My main answer would be: publishers, don't do that.

@hongminhee I would assume the same URL can represent both a PNG image and a JSON-LD document.

Here's how I do it in ONI.

The URL https://releases.bruta.link/icon represents the icon for the application actor found at https://releases.bruta.link.

If you fetch it using an Accept header for a json+ld document, that's what you'll get, if you ask it for an image/* document, then you'll get the raw image.

So, from a client point of view, the server returns the raw image, unless asked specifically for a JSON-LD document.