Today I discovered an interesting inconsistency in Activity Streams specs while investigating [a Fedify issue].
-
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
hrefof aLinkobject, not anid” (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
hrefproperties. I added a note thaticon,image, etc. have the same problem.Once again reminded of how tricky spec work can be…
#ActivityPub #Fedify #ActivityStreams #fedidev #specifications
-
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
hrefof aLinkobject, not anid” (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
hrefproperties. I added a note thaticon,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.
-
R ActivityRelay shared this topic
-
@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.
-
@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.
@mariusor Indeed the server should not return a PNG file if asked for jSON-LD doc, and instead return a 406 HTTP code.
-
@mariusor Indeed the server should not return a PNG file if asked for jSON-LD doc, and instead return a 406 HTTP code.
@oranadoz you say "indeed" but you end up contradicting me.
Why do you think the server should not return a json-ld document if asked for one?
-
@oranadoz you say "indeed" but you end up contradicting me.
Why do you think the server should not return a json-ld document if asked for one?
@mariusor I meant: I agree that:
- content negociation must be performed
- if asked for JSON-LD, the server returns JSON-LD if available, else return 406
- if asked for image/*, return the PNG.I thought this was what you meant: this is up to the client to ask for what it can handle.
-
@oranadoz you say "indeed" but you end up contradicting me.
Why do you think the server should not return a json-ld document if asked for one?
@mariusor @oranadoz @hongminhee the document describing a resource and the resource itself are not necessarily the same thing. So the response for json-ld for the icon isn't necessarily equivalent to the icon itself.
This has been a long-standing thing in json-ld for ages: is the document describing the resource or is the document the same as the resource.
This is perhaps best described by a document about a person, that's not the same as the person themselves, though that document may be used by that person to describe themselves.
-
@mariusor I meant: I agree that:
- content negociation must be performed
- if asked for JSON-LD, the server returns JSON-LD if available, else return 406
- if asked for image/*, return the PNG.I thought this was what you meant: this is up to the client to ask for what it can handle.
@oranadoz cool, cool. That's indeed what I meant.
-
@mariusor @oranadoz @hongminhee the document describing a resource and the resource itself are not necessarily the same thing. So the response for json-ld for the icon isn't necessarily equivalent to the icon itself.
This has been a long-standing thing in json-ld for ages: is the document describing the resource or is the document the same as the resource.
This is perhaps best described by a document about a person, that's not the same as the person themselves, though that document may be used by that person to describe themselves.
@thisismissem I don't ascribe to the semiotic theory of the web where the map is not the territory.
I like to keep things simple and therefore a json-ld document is a valid representation of an object that can exist as a binary.
People keep forgetting that ActivityPub is meant to be used on top of other web standards like content negotiation.
-
@thisismissem I don't ascribe to the semiotic theory of the web where the map is not the territory.
I like to keep things simple and therefore a json-ld document is a valid representation of an object that can exist as a binary.
People keep forgetting that ActivityPub is meant to be used on top of other web standards like content negotiation.
@mariusor @oranadoz @hongminhee right, but here a description of the icon isn't the same as the binary of the icon itself.
The binary gives you very different data to the description of it, e.g., fetching the binary doesn't indicate where to send replies to or how to interact with it; where as html <-> json-ld generally gives you similar enough representations.
Generally con-neg suggests the same data just in different formats; what you're giving here is different data in different formats.
-
@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.
@evan @hongminhee more and more i am thinking that Link was a bad idea from a data modeling perspective. "assume bare href instead of bare id" is something that can never make sense. if we really want to maintain validity of Link then it should *always* be embedded as an anonymous object:
icon: {
type: Image
url:
{
type: Link
href: foo
height: 400
width: 400
mediaType: image/png
}
}here, Image.url means "representation of the Image"
-
@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.
@mariusor @hongminhee > the same URL can represent both
bad idea. an identifier should unambiguously refer to exactly 1 thing
