@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.

@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 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 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..

@thisismissem @oranadoz @hongminhee

@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

@thisismissem @oranadoz @hongminhee

@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.

@thisismissem @oranadoz @hongminhee

@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.

@oranadoz @hongminhee

@oranadoz cool, cool. That's indeed what I meant.

@hongminhee

@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?

@hongminhee

@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.

Also at this pace I might run out of things to document if my NGI0 grant proposal will be approved, as a lot of the deliverables I set are for decreasing the friction new developers will have in using the library, which relies heavily on good documentation.

It's a nice problem to have I guess.

Writing documentation was good for #GoActivityPub.

It gives me the opportunity to go through some user scenarios for the tools I'm documenting and make sure that they work the way I'm describing.

I've fixed a couple of issues in this way these past days.

https://man.sr.ht/~mariusor/go-activitypub/go-ap/pitfalls.md#changing-the-type-of-an-object

#ActivityPub #ActivityPubDev