Recent searches
Search options
Some theorycrafting for a social network that is _like_ AP-derived systems, but is not based on AP.
First, some premises:
1. I am following a traditional actor pattern here. When I say "actor" I do not mean "AP actor" but rather an object with an inbox and a name that has some black box mechanism behind it.
2. I am _not_ discussing security or half a dozen other things that would be vitally important for a full proposal.
3. I am very, very rarely going to be discussing payload.
1/
First, let's define a _message layer_. Here we have a concept of an _actor reference_.
An actor reference has:
1. An inbox.
2. A URI id that just returns this reference object.
3. A structured type field, indicating what class of messages it takes and some basic behaviors around it. This can be simple or relatively complex
These are functionally immutable references. A _user_ is a distinct concept and may change actors around at any point. They can also refer to a central actor via DNS
2/
_Messages_ are ephemeral, immutable objects that contain the following information:
1. An incrementing id that is unique per server.
2. A server.
3. A URI for the _payload being referred to_.
4. A type.
5. Any routing information.
So I could say:
Create {
id: <uuidv7>
server: <uri>
canonical_uri: <uri>
from: <originating user>
to: [<list of users>]
}
That's it. No payload. There are other fields that may be interesting here, but we're being a bit minimalist.
3/
Now when someone goes to the server's canonical URI you'll get a full AS2 object (or whatever) in some normalized form. The details don't matter so long as the canonical_uri matches the id.
So you can see how this starts to develop:
Alice sends Bob a message saying that she created a Note (1).
Alice sends Bob a message saying that she created a Note (2).
Alice sends Bob a message saying that she created a Note (3).
Alice sends Bob a message saying that she updated a Note (1).
4/
So now we have a message passing system and an actor reference. Cool.
But what does a user look like? How about a server? What about these payloads?
Well. For that we need a _data layer_.
5/
The data layer is responsible for serving the payloads of objects.
We _could_ have Bob go to alice and systematically call each message in a row, but that's a waste of time and energy.
Better would be to provide a single endpoint on the server where I can say "give me all objects from Alice that were sent to Bob or are marked as:Public starting with id <foo>"
This may be attached to Alice directly but it doesn't have to be: it could be a generic per-server endpoint.
6/
(nb. I am cheating a bit with terminology, technically this would be a _service layer_ not a data layer, but data layer is cleaner for what we're talking about and I don't want confusion with the message layer).
The core here is that this is a single, paginated request that fetches _objects_ or _payloads_. The type can be content negotiated with HTTP, it can use different wire formats, all of that is less important.
7/
Now what about the user?
Users do not exist in the message layer. They _are not actors_.
Rather they _contain_ actors.
You get the user information from anything. DNS, a credentials server, I don't care about that for right now, but it has on there an inbox object, or maybe multiple named inbox objects, and they have actor _references_ (see above) that you can now send messages to.
8/
Now it does not matter if the same actor serves multiple users, or multiple inboxes for a user, or whatever else. It does not matter if they are all distinct actors that then forward their information to a central actor that then fans them out to other servers entirely.
What matters is that you fetch the user object from a canonical store and it tells you where the actors live and information like how to fetch posts from this person.
9/
One could also envision a series of redirects.
My information is stored on server <foo> but all of my canonical ids reference hrefna.dev/whatever.
Why? Because I'm proxying the calls over to a backend server that I reserve the right to change in the future.
There are a thousand things you can do from here, but basically we now have a basic lightweight framework for a scalable, message-passing-based social network.
10/10