Notices by Hrefna (DHC) (hrefna@hachyderm.io), page 3

@aburka [everybody disliked that]

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

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/

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/

(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/

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/

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/

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/

_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/

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/

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/

Ugh. Reminded today why I decided to post less on mastodon.

Too much in loco parentis and too little willingness to examine what that means. There are some very good people doing great work in this space, but the state right now is not good, and will remain not good for a while to come.

Success! Managed to get through dinner with my parents without:

* Saying "ok boomer" at any point.
* Telling them why I "don't call them" in no uncertain terms
* Rage quitting

All and all a solid victory.

@godpod Transgender characters in animated films also help to normalize conversations about gender identity, and conservatives genuinely fear movies can turn them and their families LGBT. Idiots.

@jdp23

@ireneista heh, for chat purposes I suspect this quickly runs into essentially an incompleteness theorem unless you have a structured way to engage in a dialog (handshake) about it.

Which at some point starts to look like "can I program a computer to engage in NLP with another computer about something that someone else is saying about something that may only partly be happening where a computer can see it"

@ireneista basically yes ^^

So you have a language that is here to map concepts around, that people aren't using correctly, and that has no true method of communicating the _metamodel_ between groups, and no way to establish that two groups mean the same thing, and no way to even engage in meta-communication to explain what is happening.

How is this supposed to work for a social networking protocol? At all?

8/8

Communication is _incredibly_ complex, and here we have something that essentially is designed to map concepts using a variation on _English_ with English thoughtforms and terminology.

This is not how you build a protocol. It also isn't how you build a database. It isn't how you represent thoughts in a way that others will understand at all…

…at least without a previously communicated shared context.

7/

Someone comes charging up like the coolaid man: WELL ACTUALLY YOU CAN DEFINE YOUR OWN EXTENSIONS AND…

Which is what we did for content warnings, right?

We have a long, rich history of NOT DOING THAT EXACT THING here and then just sort of living with the consequences of not doing that thing.

Let alone cases where we simply don't agree on how they "should" be used (replies coming immediately to mind).

6/