Hrefna as always posted some intriguing thoughts and mentioned actor behavior on the Fediverse, among which:
On FediDevs chat @trwnh mused further on this:
i’ve thought about this sorta as well – we need a way to know what an actor will do mechanistically. imagine a signal “this actor sends and receives Create” or “this actor wraps everything in Announce” which can be used to denote mastodon profile or lemmy profile for example
because an actor’s behavior is undefined, we should have some way to define it
i would imagine a FEP defining a conformance profile would be able to also define a type and then multitype their actor? there may be a better way but that’s what comes to mind. imagine a lemmy actor has type [Group, FEP-1b12] or some such pattern indicating that their actor behaves according to FEP-1b12
the challenge is then to figure out what each of those mechanisms can be collapsed onto
So I thought I’d add some musings and brainstorming of my own, as Actor Model interests me a lot, but I never fully saw how to neatly map that to the Fediverse…
If I purely think of an actor model, like e.g. Akka, then you have this hierarchy of actors with Actor System at the top of the hierarchy. Any actor can create child actors at will and then gain control over their lifecycle with a strategy pattern (e.g. ‘restart upon failure’). Each actor is wholly independent. It processes msgs from their inbox queue, and that processing changes its internal state that’s not accessible to outsiders. Each actor carries out specialized tasks, they are special-purpose, and state changes may alter their behavior. They may create more child actors as they see fit to delegate work. And may send msgs/events that may or may not trigger additional behavior elsewhere.
If you try to map that onto the Fediverse, how would it look like? Suppose that Actor System represents the User. User spins up an arbitrary set of Fediverse Actors representing what they are interested on doing on the Fediverse. That may be a Microblogging actor and a Calendaring actor and a Podcasting actor. Each of those will manage their own hierarchy of specific child actors for that particular domain or app. E.g. the Microblogging actor may have a set of N child actors that represent the ongoing discussion threads I am engaged with. The Calendaring actor manages all the upcoming Events on my calendar as separate actors.
What does that look like from the perspective of the federated network? If I am a different User (i.e. an Actor System, my root actor) I have no need to know the hierarchy of actors of some other User (or Organization, or Application, or Bot … all actor systems too). All I need to know, and all I perceive are many different types of actors ‘reaching out to me’ in some way or other, or whose events I am subscribed to that activate me.
I would have to know about specific actor types and how I can expect to interact with them. Here’s where the AP extensibility mechanism and possibly “Compliance Profiles” (is “conformance profile” better terminology?) would play a role. The multi-type JSON-LD would only work if it was better defined. In your example of
[Group, FEP-1b12]the Group would seem to be like a parent actor type, and FEP-1b12 a specialization and/or child actor (“Lemmy Group”). I would like to have a semantically descriptive term in the body of the JSON-LD, btw. E.g.[Group, fep:Community]or[Group, lemmy:Community]if app-specific. But indeed this whole mechanism needs to be sorted out well then.What all this gives as a result is a different kind of Fediverse, where encountering a Mastodon actor wouldn’t mean that its endpoint exposes me to a metric ton of functionality that it spits out to me. As a FireFish user encountering a Mastodon actor in the wild, what would I need to know about it? Not nearly as much as currently the case. Both FireFish and Mastodon are Microblogging apps and, suppose they are both well-behaved, implement the common Microblogging Compliance Profiles. Their true communication of exchanging Posts would take place between child actors, and parent actors need not know about that. They delegated that processing and just manage all the delegate tasks à la Actor Model.
That might go as fine-grained as you like. One quality of the actor model is that the number of actors is never an issue. Actors should be incredibly lightweight and there can be millions of them, even within a single actor system. A single toot can be its own actor, and allow remote parties to learn about its side-effects that are caused by incoming msg processing.
certainly. I thought I found a better way, and the other day asked the latest