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)

@jens hmm, i think what you're saying mostly lines up with an MLS type of architecture, where "clients" communicate in "groups"

but i think the resource-centric view of the world tends to be more universal or at least more generalizable

resource-centric being core to RDF et al where "everything is a resource" -- i'm a resource, you're a resource, this post is a resource

HTTP lets you retrieve either resources or resource descriptors, XMPP lets you address clients as xmpp: resources, and so on

@jens more precisely i guess the distinction really is whether you view the "userpart" or "localpart" as something different than a resource

like imagine if https://trwnh@mastodon.social identified not "HTTP Basic Authentication", but instead identified "the user `trwnh` on the host `mastodon.social` as accessed over HTTPS"

@trwnh You're thinking in locators, not resources.

A resource is the thing the locator points to, and a locator encodes location, i.e. access methods are implied.

I'm talking about the thing that's being pointed at. It must have an identifier, but has no need for a locator, because it doesn't need to have any specific location.

You can build identifier triples for RDF, if you like. In parts it treats locators as identifiers anyway.

@trwnh So this very much is a resource oriented view. You can have resources that express something about actors, sure.

But at the protocol level, that isn't particularly useful. Here you need identifiers of sorts, and most likely cryptographic ones (i.e. public keys) that you can do access control stuff with.

The reason it's group oriented is, to loosely quote @dentangle , that one-to-one communications is a special case of group comms where the group happens to consist of only two parties.

@jens right, but when you say you discarded that "actors are resources", then what does this imply? i took it in the same sense as a URI, which is to say that actors need to be identified in a different way than resources. hence me talking about `user@host` instead of `host/user`

if you have the time to get into that discussion, that is -- i'm okay with you coming back around to this whenever you feel up to it!

@trwnh The point is, you can build something on top where some resources say something about actors, and others say other things, and they can all be linked in an RDF-y way.

It's the underneath I'm more concerned with: you have a reason to communicate, and that reason is represented by some identifier which represents a resource. You can read and write from/to the resource, and so can anyone who shares in the group that forms around this resource.

That needs to be managed at protocol...

@trwnh ... layers in some way, both for transport and access control reasons.

What you share in such a resource is sufficiently unimportant to the shape of those layers that I don't deeply care about it.

But I do think an AP like thing could be done on top, sure.

@jens >identifiers of sorts

ids can be locations or names, generally; although locations are *also* names in a roundabout way. by my understanding, this is why semweb people use http: or https: in rdf statements -- they want to make statements about things, and they also want to ideally be able to use the Web to get more statements about that thing. given a choice between "name" and "name that can be looked up", they choose the latter.

@jens which is why i propose / am toying with "RNS" as a generic, scheme-independent way to look up resources

@jens ah, i think i get what you're saying -- is it that you separate "protocol" from "thing shared over protocol"?

if so, then i weakly disagree, at least insofar as we currently use the protocol to confer some level of identity to the Thing

one thing that came about in a subthread is the idea of further separating "resources" from "identifiers", in what i interpret as similar to the distinction between a "resource" and a "resource descriptor"

for example, the concept of a "user" as something other than a "resource", but still living on a "host" machine.

something like xmpp lets you identify xmpp://a@trwnh.com while something like http(s) instead uses the userpart for HTTP Basic Authentication

i guess the distinction really is whether you view the "userpart" or "localpart" as something different than a resource

like imagine if https://trwnh@mastodon.social identified not "HTTP Basic Authentication", but instead identified "the user `trwnh` on the host `mastodon.social` as accessed over HTTPS"

if HTTP(S) allowed it, you could directly type your handle into a web browser and get back some kind of representation, like a descriptor document with details about that user