Dereferencing non-HTTPS URIs as `id`

ActivityPub
21

Precisely.

Now I have to add some useless text to meet the minimum reply length.

22

Personally I think datashards are the way to go for nomadic content. Datashards can be composed into a bearcap too, but some work needs to be done to figure out how precisely that construction would work.

basically, if it’s nomadic, it should be a datashard, if it it’s transactional, it should be a bearcap and then anything else would typically just be https URIs as they are now.

2 Likes
23

I think there’s probably mixing of concerns to treat non-HTTPS as primarily an issue of nomadic content; while there is potential application toward this, I think the incompatibility issue is probably more pressing in the long run. You can claim that a software is “compatible with ActivityPub”, but this is a statement that needs clarification and qualification. And this is also something that would become even more of an issue if ActivityPub is implemented via networks other than HTTP(S).

In that sense, there is no “ActivityPub network” – there is only currently an “ActivityPub over HTTPS network” (using HTTPS ids), as well as a sub-network of “ActivityPub over HTTPS network, with WebFinger” (perhaps more colloquially referred to as “the Mastodon network”).

Even if every (or the majority of) software implementation(s) moves to adopt bear: URIs as id, there is now still the question of which URI schemes are supported with the u parameter of the bearcap. The draft for bearcaps defines u as “The stable URL that the bearer capability URI is associated with for requests”, which is, again, not specifically HTTP(S). But even then, specifying a “stable URL” means that we are precluding URNs as a form of reference.

As nightpool mentions:

So I guess my main concern is that so-called “ActivityPub” software will settle around the lowest common denominator or the most restrictive set of requirements for interoperability. I’d like to lessen that if possible, so that individual implementations have the option to explore alternative lookup strategies for other “publicly dereferencable” schemes without that implying a choice between “hard break in network compatibility” or “stuck using HTTPS for id because everyone else is”. Although a hard break might be desirable in some cases, e.g. “if you don’t understand bearcaps then you can’t interact with this object”.