This topic serves to explore a fediverse based on “app-free computing” where services are composed, choreographed and orchestrated into social experiences.
I’d like to cross-reference two SocialHub topics related to the subject at hand:
- Social Web and App Free Computing - Fediverse Futures - SocialHub
- Thoughts on Actor Model versus Fediverse - Fediverse Futures - SocialHub
Heterogenous Fediverse: Components & services
Just for shits and giggles, I drew an example occurence that one might one day see on a Mastodon timeline, in a more heterogenous Fediverse:
This is still very much a UI sketch as a microblogging app might present it. A different (C2S) client may have a completely different representation, and may for example drop the notion of a Timeline altogether. In this presentation the Group, the Event, and the Recipe might’ve been provided by separate independent services that are combined. And none of those by Mastodon.
The various widgets in this timeline section may have their own business logic and side effects. Many incoming msgs need not lead to additional timeline additions, but could just be dynamically updating a widget that was received earlier.
Taken from thoughts on the Actor Model vs. Fediverse …
I don’t know how useful this is in practice, but it strikes me that in actor-based applications the top-level actor represents the entire application e.g. a full-blown webshop or banking app.
On the Fediverse our Person actors are like top-level actor systems. A Mastodon actor represents the full microblogging app, a single “email” address that exposes the full “API” to the world for integration. That’s a complex actor right there.
In the sketch I drew yesterday on the Social Web and App Free Computing topic, when I as a person am interacting witht the Recipe, then that involves a long-running task with the remote RecipeService that offered me this dynamic view. The business logic is owned by that service, and not by Mastodon that only displays it in a timeline.
So I shouldn’t exchange Recipe activities with the Mastodon actor, but with RecipeService in the context of both the Mastodon actor and the particular Recipe I want to cook. The top-level Person actor in an actor model would spin up a child actor hierarchy dynamically, delegating all this processing.
If some person provides an Ingredient for the Recipe and that information is exchanged between (remote or local, but network-transparent) child actors, then these don’t need intricate Inboxes. I can only find information on our particular prior exchanges/transactions.
And after the Activity has been processed by all actors involved, the child actors will be killed, they no longer need to exist. And the msg exchanges related to them can be discarded. Only higher level actors remain. If I want to have further interaction with the Recipe then new actor hierarchies are spun up.
Service management ontology
Given that the extension mechanism of the ActivityPub social web protocol depends on Linked Data and recent discussions with various people about the merits and pain points of linked data vs. current fediverse, I looked briefly into existing linked data ontologies for Service Management.
Found this old work (dating 2004) around “Services on the Semantic Web” once posted as a submission to W3C in OWL Web Ontology Language for Services (OWL-S).
The ontology is designed to enable:
- Automatic Web service discovery.
- Automatic Web service invocation.
- Automatic Web service composition and interoperation.
Our structuring of the ontology of services is motivated by the need to provide three essential types of knowledge about a service (shown in Figure 1), each characterized by the question it answers:
- What does the service provide for prospective clients? The answer to this question is given in the “profile2,” which is used to advertise the service. To capture this perspective, each instance of the class Service presents a ServiceProfile.
- How is it used? The answer to this question is given in the “process model.” This perspective is captured by the ServiceModel class. Instances of the class Service use the property describedBy to refer to the service’s ServiceModel.
- How does one interact with it? The answer to this question is given in the “grounding.” A grounding provides the needed details about transport protocols. Instances of the class Service have a supports property referring to a ServiceGrounding.
PS. There are many other service introspection linked data ontologies around. Maybe one is usable to discover the capabilities of Actor endpoints on the fediverse.
1 Like