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.

as always, i am only half joking whenever i talk about the "activitypub vm". actors are resources within a network of other resources. their interface is typically AP/LDN/HTTP, for some semantic interpretation of AP.

but the architecture of current fedi is not correctly layered. actors are treated not as resources, but as puppets of the server, the machine which hosts them.

it is, strictly speaking, unnecessary for everyone to have their own inbox, except as an implementation detail.

(extremely inconsequential side note: i am realizing maybe instead of TCP/IP/DNS/TLS/HTTP/"RNS"/"MLS" i should call it "MLS"/"RNS"/HTTP/TLS/DNS/TCP/IP -- where "/" means "over")

(slightly more consequentially, since DNS runs alongside rather than on top of TCP/UDP, that might make it "MLS"/"RNS"/HTTP/TLS/DNS/IP since TCP vs UDP is just a way of breaking up packets into datagrams, not fundamentally changing the overall message)

ok got it

HTTP/TLS/DNS+IP (where IP can be subdivided into TCP, UDP, QUIC)

so we can also rename "MLS" for disambiguation, let's call it "IRC" for inter-resource communication ah shit wait that's taken too

ok uhhh "RMTP" for resource message transport protocol wait that's too similar to RTMP

"RMT" for resource message transport? i guess that works

let's also say "MSP" stands for "message semantic profile" to bring it full circle

"MSP"/"RMT"/”RNS"/HTTP/TLS/DNS+IP

i guess if i were to attempt to formalize this further

"RTRT"/”RNS"+"MTMT"

- "RTRT" = resource to resource transport
- "RNS" = resource name system
- "MTMT" = machine to machine transport
- HTTP/TLS/DNS+IP
- XMPP/TLS/DNS+IP
- SMTP/TLS/DNS+IP

where "resource" is defined as "thing hosted by machine" (where the machine can answer authoritatively for that resource, either by providing the resource directly, or by providing a resource descriptor)

@trwnh I wish I had the time to pick this conversation up properly, but today isn't the day.

But a similar line of reasoning has led me to start @interpeer - though I wasn't so much interested in AP at the time. The idea was to find a common human oriented set of layers.

Turns out, actors as resources was something I ended up discarding (TL;DR), or rather treating as a less important part. The main part is group communications *about* resources, which requires identifiers (of actors),...

@trwnh ...and that leads to a bunch of other things becoming necessary at some point.

Hmm. Maybe this is interesting to you?

Interpeer Architecture

Videos exploring Interpeer's architecture, in contrast to those of the Web, as well as alternative approaches being explored.

MakerTube (makertube.net)