fair chance that "activitypub" (really activitystreams) as used in fedi software goes the way of "html" as used in web browsers.

anyone trying to do schemas for fedi documents will probably be about as successful as xhtml

so i guess the natural followup question is, which WHATWG-like entity is going to arise and fork activitystreams away from the W3C

"meta and mastodon" sounds a lot like "google and mozilla" and i wonder if the numbers are similar too

anyway i don't really want this to happen but if it does happen then let the record show that i fuckin' called it.

honestly from an activitypub standpoint what fedi does is not terribly removed from activitypub, if you take "activitypub" to mean "POST to inbox based on addressing properties". that part generally works. the following protocol is like 80% there. no one actually uses the liking or sharing protocols, they just send the activities.

it's what's *in* those activities that is left completely open. y'know, the entire "rest of the protocol" bits.

in the same way that an HTTP POST can have arbitrary headers and arbitrary body content, that is.

by which i mean: HTTP is less of an "application protocol" and more of a "transport protocol implemented in the application layer". OSI layers 3-7 virtualized within OSI layer 7.

the virtual layer 3 "network" of the web is all the web servers as identified by DNS names or IP addresses -- IANA is the network.

the virtual layer 4 "transport" of the web is HTTP messages -- both requests and responses.

the virtual layer 5 "session" has not been built in a standardized way, and neither has virtual layer 6 "presentation", and neither has virtual layer 7 "application".

for the most part the "virtual layer 5 session" is ephemeral, and it exists for the lifetime of the HTTP request or response only

"virtual layer 6 presentation" is mostly about the data serialization over HTTP -- your xmls and jsons and whatever.

"virtual layer 7 application" is where we want to be. it's where anything useful happens when "on top of HTTP".

from this we can envision potential options:

a) go back to the real "layer 3/4" and start over from on top of that. (this is what xmpp does, by building on top of TCP/IP)

b) stop at the real "layer 7" and just directly use HTTP messages. (not too dissimilar from activitypub proper, except instead of AS2 JSON we use the full HTTP message)

b.2) build a new "layer 8" for user agents.

c) virtualize layers 3-7 within the real "layer 7". (basically fedi)

d) expand layer 7 to encompass everything.

just one big application layer. The App

i think somewhere between a and b is what i’m leaning towards, because my thinking is crystallizing re: “virtual osi on top of 7” being mostly bad.

which is to say, in a world where we have:

- TCP/IP/DNS/TLS/HTTP
- TCP/IP/DNS/TLS/XMPP
- TCP/IP/DNS/TLS/SMTP
- etc

why would we poorly reinvent a virtualized transport layer? why not use what already exists?

i think the trap we have fallen into is that we want to use https: identifiers that work in a web browser, because http(s) web browsers are ubiquitous.

but to make https: identifiers the basis of our identity layer is to find ourselves in a situation where we need to reinvent DNS and TLS, but for HTTPS resources.

so we need a “resource name server” (RNS) and a “message layer security” (MLS oh wait that one’s already taken)

essentially our TCP/IP/DNS/TLS/HTTP/RNS/MLS stack would let resources send messages to each other, instead of being limited to servers or machines sending messages to each other.

@trwnh the Industry simply decided that HTTPS was the fundamental optimization of the next decades and would replace TCP entirely

@alice i hate it here

@trwnh yea

@trwnh if it wasnt for ruby on rails we'd have collided xmpp and activitystreams by now (false. not true)

RNS here being analogous to what the MLS spec calls an “Authentication Service” — basically you give it a name and it looks up records about that resource and provides you with a resource descriptor

WebFinger is a type of RNS, roughly speaking

You could do this over HTTPS-based “Controller Documents” as well, but that limits you to https: identifiers. Having an “RNS resolver” lets you make the transport pluggable. You’re not limited to a single protocol.

@alice someone did it i think? libervia?

@alice anyway idk if activitystreams is ideal here but i think you could negotiate a profile of it in theory, i do think semantic profiles ought to be negotiable in the same was as cipher suites