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

in some ways this is reinventing HTTP but that’s mostly fine because HTTP is between machines and MLS is between client resources

an alternate path is, again, just use HTTP directly. give every resource its own FQDN (lol) and then publish DNS records at that FQDN. now issue a cert for the machine/server/app running on that host. do mutual TLS between any two machines. this is pretty inconvenient and “low level” but it does technically work!

one of the interesting consequences of all this: trust management

DNS poisoning is a thing, DNS is easily blocked, and so on

RNS has the same issues (same conceptual model really), but it is generally more diffuse; you are still vulnerable depending on which resolver you are using as your entry point, but it would be generally easier to run your own RNS than to run your own DNS. authority cascades similarly, you could have RNSSEC, and so on. but it’s easier to manage RDF/JRD/whatever than DNS.

taking a step back to the TCP/IP/DNS/TLS/HTTP/"RNS"/"MLS" stack

just as WebFinger is a type of "RNS", you could swap "MLS" for anything that lets resources communicate instead of only letting host machines communicate. so LDN works in the same way the actual MLS spec would work, with what the MLS spec calls a "Delivery Sevice".

the best way to conceptualize something like ActivityPub within this system is not as its own protocol, but instead as a "semantic profile" for interpreting messages...

so in a big picture architectural sense you have:

- machines communicating with machines
- machines host resources
- resources need a way to communicate too

the fundamental paradigm shift is to stop treating resources as machines virtualized within other machines, and to start treating resources as resources hosted by machines.

in the same way that processes can communicate within the same machine (IPC, DBus), we need an interface to allow them to communicate with processes on other machines.