Today I discovered an interesting inconsistency in Activity Streams specs while investigating [a Fedify issue].
-
@trwnh well, I'll agree to disagree with you.
GoActivityPub has as a first order type representation the json-ld document, which for this specific type (Image, well, others too) can be represented *also* as a binary. So we just do that.
This is simpler, bidirectional in ensuring both the info about a thing, and the thing itself can be reached knowing only *one* piece of information (it's ID/URL), and is supported by long existing HTTP mechanisms, like content-negotiating.
For me pragmatism trumps whatever philosophical reasons people can come up with for it being incorrect. So that's where I'm at.
@trwnh sorry to be snarky, but you'll probably have a fit when I'll tell you that the on-disk representation for these json-ld documents representing binary stuff, actually hold the binary data as base64 encoded data URLs inside of their content properties. (This is *one* direction in which I went which I kinda regret, and hope to find a better method for storing binaries)
https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Schemes/data
-
@trwnh sorry to be snarky, but you'll probably have a fit when I'll tell you that the on-disk representation for these json-ld documents representing binary stuff, actually hold the binary data as base64 encoded data URLs inside of their content properties. (This is *one* direction in which I went which I kinda regret, and hope to find a better method for storing binaries)
https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Schemes/data
@trwnh and one final thing.
This insistence of thinking of the underlying data for ActivityPub as separate from it's document representation makes it so the fediverse is as fractured as it is.
ActivityPub deals only with these documents and yet every service, maps whatever data they store, to these imperfect representations which sometimes are very far from the spec, because contorting existing data paradigms into RDF triplets and JSON-LD is cumbersome.
Storing json-ld metadata, or the full document itself, like I do, allows you to think in clearer terms about addressability, access, location, etc..
-
@trwnh and one final thing.
This insistence of thinking of the underlying data for ActivityPub as separate from it's document representation makes it so the fediverse is as fractured as it is.
ActivityPub deals only with these documents and yet every service, maps whatever data they store, to these imperfect representations which sometimes are very far from the spec, because contorting existing data paradigms into RDF triplets and JSON-LD is cumbersome.
Storing json-ld metadata, or the full document itself, like I do, allows you to think in clearer terms about addressability, access, location, etc..
@mariusor @thisismissem @oranadoz @hongminhee i don't think it's cumbersome at all. if people used the as2 data model directly and operated on activities instead of transforming statuses, they wouldn't have that issue (and it is a different issue).
the issue i'm talking about is ambiguity. when you use the same identifier for two different things, you can no longer distinguish between them. this is known as equivocation.
example: does an Image have a width of 800 pixels? no. the repr does.
-
@mariusor @thisismissem @oranadoz @hongminhee i don't think it's cumbersome at all. if people used the as2 data model directly and operated on activities instead of transforming statuses, they wouldn't have that issue (and it is a different issue).
the issue i'm talking about is ambiguity. when you use the same identifier for two different things, you can no longer distinguish between them. this is known as equivocation.
example: does an Image have a width of 800 pixels? no. the repr does.
@mariusor @thisismissem @oranadoz @hongminhee using content negotiation as an example: i can ask for the same Image as either image/png or image/jpg, right?
```
GET /image
Accept: image/png303 See Other
Location: /image.png
```or...
```
GET /image200 OK
Content-Type: image/png
```the Image is the same Image even if i resize it, or convert it to a different format. we are generally uninterested in reasoning about representations instead of reasoning about the thing itself.
-
@mariusor @thisismissem @oranadoz @hongminhee using content negotiation as an example: i can ask for the same Image as either image/png or image/jpg, right?
```
GET /image
Accept: image/png303 See Other
Location: /image.png
```or...
```
GET /image200 OK
Content-Type: image/png
```the Image is the same Image even if i resize it, or convert it to a different format. we are generally uninterested in reasoning about representations instead of reasoning about the thing itself.
@trwnh you seem to be speaking of "a platonic ideal" of the internet.
Tell me which ActivityPub service is capable of giving you png or jpeg versions of an image just because you ask for it. The same for the sizes. Nobody serves you different sized images from the same "resource", because computing that at access time is expensive to do, there's no standard way to ask for a specific size, etc.
While in my case, there is a standard way: content negotiation.
Please understand that you won't convince me. Like I keep saying: pragmatism should trump the philosophy of identity when we program applications.
-
@trwnh you seem to be speaking of "a platonic ideal" of the internet.
Tell me which ActivityPub service is capable of giving you png or jpeg versions of an image just because you ask for it. The same for the sizes. Nobody serves you different sized images from the same "resource", because computing that at access time is expensive to do, there's no standard way to ask for a specific size, etc.
While in my case, there is a standard way: content negotiation.
Please understand that you won't convince me. Like I keep saying: pragmatism should trump the philosophy of identity when we program applications.
@mariusor it's perfectly practical to serve what the requester asked for. it's not very practical to serve something they *didn't* ask for, instead of the thing they asked for.
any http server is capable of this. maybe they use query strings, maybe they don't. there are defaults in any case.
i mean, you probably encounter a cdn serving images like this multiple times every day, without even realizing it.
-
@mariusor it's perfectly practical to serve what the requester asked for. it's not very practical to serve something they *didn't* ask for, instead of the thing they asked for.
any http server is capable of this. maybe they use query strings, maybe they don't. there are defaults in any case.
i mean, you probably encounter a cdn serving images like this multiple times every day, without even realizing it.
@trwnh I'm starting to feel you just like being contrarian.
I just said I serve what requesters ask for because my service employs content-negotiation. So if they ask for an image they get an image and if they ask for a document they get a document.
-
@trwnh I'm starting to feel you just like being contrarian.
I just said I serve what requesters ask for because my service employs content-negotiation. So if they ask for an image they get an image and if they ask for a document they get a document.
@mariusor no, i'm just trying to reach a mutual understanding.
content negotiation is fine if you are serving the same information for the same identifier. you have this idea of images being documents, people being documents, etc., and i have the idea that the representations are not the thing itself.
take for example the very popular and common pattern of doing something like this:
/image
/image.avif
/image?width=600
/image/thumbnail
/image@2xthese might all be "the same image" at the end.
-
@mariusor no, i'm just trying to reach a mutual understanding.
content negotiation is fine if you are serving the same information for the same identifier. you have this idea of images being documents, people being documents, etc., and i have the idea that the representations are not the thing itself.
take for example the very popular and common pattern of doing something like this:
/image
/image.avif
/image?width=600
/image/thumbnail
/image@2xthese might all be "the same image" at the end.
@mariusor again, this isn't theoretical, there are plenty of web servers doing exactly this.
you can find services of this sort all over the place:
and many widely-used softwares as well:
https://www.contentful.com/developers/docs/references/images-api/
-
@mariusor again, this isn't theoretical, there are plenty of web servers doing exactly this.
you can find services of this sort all over the place:
and many widely-used softwares as well:
https://www.contentful.com/developers/docs/references/images-api/
@mariusor the problem (for others) is that when you use the same URI to refer to different things, you can no longer distinguish between them. it's why the naive approach is to just use file extensions -- less ambiguity. you can trade content negotiation for explicit identification ahead-of-time. but it's quite tenuous to say that foo.jsonld and foo.png are "the same" in any meaningful sense. one is a description of an image, the other is a representation of the image. neither are the real thing
-
@mariusor the problem (for others) is that when you use the same URI to refer to different things, you can no longer distinguish between them. it's why the naive approach is to just use file extensions -- less ambiguity. you can trade content negotiation for explicit identification ahead-of-time. but it's quite tenuous to say that foo.jsonld and foo.png are "the same" in any meaningful sense. one is a description of an image, the other is a representation of the image. neither are the real thing
@trwnh who are these "others" that have issues with content negotiation?
The target for my software - this particular one I gave the icon example from - are browsers. And in a browser this content negotiation works perfectly fine, have a look see -> https://releases.bruta.link
Can you see the icon? You can. Can you open the icon in the browser in a new tab and still see it. Yes you can. Can you use curl on the icon URL, yes, and as it defaults to json, you get the JSON-LD representation. I think that's good enough for me. I accept that it's not for you and wish you good luck with the software that you're developing. I'll stop engaging now.
