TL;DR: If a protocol only consists of extension, is that a useful protocol at all?
In another thread I said this:
I’ve since thought about this over and over. It gets kinda interesting when you really take it to the logical extreme of making everything into an extension, because you end up with basically nothing in the core spec. All you define in the spec is some common way to define extensions and… That’s it.
But can such a “protocol” even be said to be a protocol? The core part of such a protocol doesn’t even say anything! It feels more like a “meta-protocol” that you can extend to create a protocol or a mix of protocols.
The spec may come with a few “blessed”, highly recommended extensions that ought to be supported, but does that change the situation much? As extensions, there can’t be any true requirement to support them, which is kinda the point.
Would such a protocol be useful? There is no guaranteed base of common communication between two implementations - you would only be able to communicate with someone who you share at least some extensions with. Is that okay or would it just lead to a fractured ecosystem? I guess it’s not that different from the current situation, to be fair.
Would love to hear any thoughts, I just haven’t been able to stop thinking about this.
Before discussing the potential utility of it, is it “basically nothing” or actually “nothing”? If you mean the latter, every protocol that’s ever existed is an “extension” of something or “nothing”, so I don’t think that adds much value. If it is “basically nothing”, you’ll need to define what this is, in an ActivityPub context, before I could make any comments.
The activitypub-mincore thought experiment was my “basically nothing” proposal to build extensions upon.
When I was defining activitypub-mincore, I thought about what can be taken away from the AP Recommendation (S2S only) before one could reasonably claim “that’s not ActivityPub any more”. Most of the Recommendation is optional anyway. My answer was that federation and content publication are the key concepts in S2S and the follow relationship is the key to federation. So, my mincore focused on that interaction and publication via inboxes. If you remove AS2, then you have no protocol at all since the AP protocol is defined in terms of AS2. In that sense, it is a special vocabulary in an AP context. However, it’s so flexible that you can tunnel other JSON-LD vocabularies (like schema.org or WADL) via AP too (if you’re careful with the JSON-LD context). However, very few servers support doing that (the LD/RDF servers tend to be exceptions).
To be clear, I don’t think activitypub-mincore is useful per se, but it could be useful as a foundation for defining AP “extensions”, which could include behaviors already in the AP Recommendation, but with better definitions for message structure and constraints, expected behavior, security, etcetera.
Not “actually nothing” but essentially the core of the “protocol” would just be a common way to define extensions in such a way that extensions would not conflict, so that different extensions could work independently.
It wouldn’t really be as much of a protocol at that point as there would be no communication requirements in that core spec (that would be specified by extensions as well). This makes a protocol built on top of such a framework extremely flexible as an implementation could choose/define exactly the extensions it wants to support, but obviously there is not very much mandated common ground then.
The activitypub-mincore thought experiment sounds interesting - I guess my thought experiment here is basically taking it to a further extreme where even things like publishing to the web and following actors and such is not part of the core protocol, but would be specified in extensions. This could obviously not be considered ActivityPub proper any more.
extension of what, though? “following actors” is the core of ActivityPub, and i would even argue it is more or less the entire protocol if you consider only S2S. actually, that protocol is basically “send an as:Follow over LDN, wait to get back an as:Accept”. basically AP S2S provides three “protocols” as extensions of LDN:
a “follow protocol”
a “likes protocol”
a “shares protocol”
i think you might be interested in looking into this less in terms of “extensibility” and more in terms of “protocol layering”. for example, AP is layered on top of LDN which is layered on top of HTTP which is layered on top of TCP/UDP/QUIC and so on. if you go “one layer down” to LDN then you have an inbox and you can HTTP POST some notifications to it, but AP adds an extra restriction that this notification is specifically an AS2 Activity. you could theoretically do the same “follow protocol” but carried over different transports like SMTP or XMPP. you could do it over raw TCP if you wanted to. but in general, it’s better to build on what already exists than to go “down the stack” and throw out some valuable parts along the way. AP doesn’t have a hard requirement on HTTP but it is written with HTTP+LDN in mind as the transport layer (and this transport layer is virtualized within the application layer of HTTP)