I was wondering if anyone has experimented with a composable server where an inbox and outbox could be lightweight micro services?
Any ideas what a minimalist setup would look like?
Would there need to be additional micro services e.g. to look up the public key of a User/Agent/Actor?
I’d like to build something like this to extend my personal homepage to become part of the fediverse, but I’d like to reuse existing solutions or designs, where possible (PS current preferred language JavaScript)
I’ve written up a concept for this here:
Feedback welcome!
I very much align with that notion as described on the website. I also think it is the way forward for a more powerful task-oriented fediverse that breaks out of its application silo’s. I see such services as building blocks that might result from a domain-driven design exercise and define a single concept of bounded context well. For that a dedicated 'micro-'ontology/vocab can be created, and standardized on, together with some description of ‘domain logic’ that you’d need to adhere to in order to interoperate.
The only thing maybe unfortunate thing in your choice of title / domain name, is that ‘microservices’ are already so much tied to a very specific architecture in the minds of many people, i.e. of fully decoupled individually deployed services that you invoke over the network through (oftentimes ‘REST’) API’s. But they could just as well be defined in a monorepo or monolith app.
If this can inspire you, SemApps use microservices (via the MoleculerJS framework). Here’s how ActivityPub services look like:
I’m wondering if you’ve seen Solid before? The idea of separating profiles/authentication from the application reminds me of the Solid Pod concept, and there are some relevant specs like Solid-OIDC to facilitate this
Solid is using WebACLs, which Christine Webber felt was a significant split with the direction of ActivityPub (capability-based security)
Personally I’m a big fan of the idea of separating services in the way that you describe, I think this is where the real strength in interoperability is. I’ve been working on a decentralised adventure game, and using micro-services is the whole why of the decentralisation - the idea that game worlds could share features with each other and expose game state to unanticipated/interesting changes (the post is a bit outdated, but hopefully I’ll have some new stuff to write about it soon:tm:, and if it interests anyone reading then join our Discord 
). We’re using Solid at the moment, switching to ActivityPub is an open question, but certainly the separation of profile/authentication from the application logic is a big help in using Solid
Yes, Im aware of Solid, and helped in its creation
WebACLs I guess we modeled that on the UNIX file system. Certainly not the only way to do things, just one way to get started
I pushed quite hard for separation of concerns. In particular, cleanly separating Identifers (just a string of characters as a URI) and authentication (verifying that identifier). The idea is that each part could be modular
I built a lot of services against solid, and also hit lots of walls. This lead me to realize I needed more robust frameworks with lower maintenance burden, better orchestration e.g. data orchestrations, perhaps with linked data orchestration, but also temporal orchestration for history, version control, race conditions, is under developed. I want mirco services that do one thing well, and just run, and you dont have to worry about them
Funnily enough I also had the idea of linked decentralized game worlds. I even built a MUD based on each location is an HTTP page, but didnt finish building items or the ability to hyperspace from one game world to another. We have better tools for that now. It’s a fun thing tho
Will join your discord, thanks for the pointer!
What kind of problem would this solve, exactly? I feel like that problem would be “we’re not using microservices, we should start using them”. It’s kinda like trying to add a blockchain to everything.
Good question!
It allows different teams to work on different services
In a given system you can take (and compose) the services you need, but no more
And also add new services that no one has done yet.
Agree with your comment about adding block chain. Mostly you dont need it. And normally it’s just folks trying to sell tokens by spamming links. They can be useful tho in resolving race conditions in a distributed environment. For example in the instance of a distributed game, two players want to pick up an item. Who did it first? A block chain can provide a tie-breaker in such a situation
In such as way you can create new workflows and new apps, without having to start from scratch every time
In light of the recent discussions on linked data here and on Solid forum here, I’d like to highlight some things I say in my last 2 comments on solid forum in [1] and [2] (no need to read, they are long). They relate to Interoperable serendipity by Noel de Martin.
And that is that unless you focus both on the processes and on the social aspects of software development and in a broader sense of the entire ecosystem, you will end up in a situation of what I call Ad-Hoc Interoperability. That happens to be where the Fediverse is now. It is where everyone just bolts on extensions they need for their app, but don’t the take the time to make those easily accessible for others to reuse. And making broadscale interoperability a bit harder with every such extension that goes into production.
I am a big believer of the conceptual idea behind this Microservices initiative, namely a focus on further modularization, a breakdown of apps into separately reusable modules and services. We have a number of such frameworks already with Bonfire, Go-Fed, SemApps etc. But without processes and social activity they will all be used to practice ad-hoc interoperability within their own ecosystem.
Micro services on their own just end up replacing one complexity with another
However they can be made useful if there is a good sense of orchestration. Perhaps this ties in to what you call social aspects
Solid was born out of the fact that we wanted to make better and smarter social profiles. I feel the fediverse in general can be orchestrated around your profile page, which links to your inbox, your followers, your pub keys and more
In recent days I’ve made a push to make WebID which was the inspiration behind solid, simpler, and more aligned to Activity Pub by translating them to JSON(-LD). We’ve also created a context to make developer’s lives easier:
The first examples are springing up. And that will be a start for social on microfed
The aim and next step will be to add activity pub to the vocabularies so that actors as well as foaf person and agent will be compatible
There is one general incompatibility around the two systems. And that is that the person entity in solid is different from the profile document. In mastodon they are generally the same. I’d want to keep this nice clean separation of a page having many entities because it will be useful later for orchestration when we have keys, friends social accounts and many concepts orchestrated from a profile
Yes, though “orchestration” in the broadest sense of the word. So orchestration between people and possibly with help of supportive technology to make that easier. The goal is that if I create an app in business domain XYZ, and there are already 4 other apps in that domain, there’s the greatest likelihood that we’ll create interoperable services that can be further integrated and built upon.
Part of this is laying good foundations, such as is the objective of the issue you linked. Another part is the ease of getting informed about domain-specific stuff others have done before me, and the ability to reach consent on how to extend this further.
Where Solid is going into more utopian directions can be seen from this quote from Noel de Martin (who in his article describes that this is tricky):
“So even if you made up a vocabulary and no other app uses it, the community will be able to start using your vocabulary, or implement tools to convert from your data to other formats, without your involvement.”
This is “Semantic Web”-scale thinking, where layers of tech complexity and rock-solid ontologies make it possible to minimize the social aspects, and just reuse what’s out there. I don’t think we’ll get here anytime soon, and maybe never.
Imo the ‘microservices’ approach aligns more to defining micro-ontologies that do not aim to become world-wide standards (though they can be). Instead there’s cooperation between a set of interested parties to be compatible with them and collaboratively maintain them, and advocate for more parties to also adopt them.
In the Ad-hoc Interoperability reality we have now, none of the well-defined processes and efficient means of social interaction exist. We only have the intent to create them (like with the FEP process).
A proliferation of as:Group implementations, and no consensus about standardization after 2 years of discussion on SocialHub.
Video domain. When Owncast wants to be compatible with Peertube, they first have to delve into Peertube codebase and bother the devs with any questions they have. Then they create their own video federation flavour. Now for the third federated video app they have to coordinate like this with 2 projects separately. There’s no place where they can be informed on the common denominator.
Code forges domain. Recently various code forge federation projects picked up where ForgeFed stranded. ForgeFed was a cool example of a specification effort for forges. Time will learn if these projects will coordinate the specifications for forge federation. I proposed bundling them into forgefriends FSDL.
The semantic web is about creating both human and machine readable data
Creating shared vocabs is one part of that. It tends to be either under used (each site has its own api) or over used (the burden to create a simple app becomes too high)
Shared vocabs I would say are useful in a minority of situations. SEO and schema.org has found a good use case for it. To push for vocabs in all situations is usually far too dogmatic
Sandro Hawke, who created the acronym “Solid” and is a reknown expert in the semantic web summed it up nicely. RDF doesnt give you interop, it gets to to the edge of the abyss.
What happens when a vocab just isnt really very good. For example AS2 is a good but not exceptional vocab. We can and probably will do better in future. What happens when data is messy? What when some relations are one-many vs one-one. What when things are modeled differently. Real world concerns are often met with hand waving from people that dont use the system. It gets worse. One of the inventors of RDF said it was unsuitable for things like arithmetic. It’s actually to this day an unsolved problem how to do age = age +1. Think about that for a moment. Basic arithmetic.
The better way is to standardize around JSON. And then give URLs to things that are of common to different systems. Give things types that have similar ‘shapes’. Introduce vocabs to support systems as they get larger. Vocabs should be much easier without the excessive content types and redirections that cause so many issues and confusion
The semantic web is a good idea, it’s just implemented in a buggy way, using tools that date back 20 years. It’s a good start to solving some problems. But it doesnt solve every problem. We can surely do better with modern tooling
I think the place to start is with user profile, because that seems to tie everything else together. And most profiles dont really work well together today. So microfed would start with that. Add authentication, add followers, inboxes, and outboxes. Links to other accounts, and other systems (e.g. AP, or nostr) and add more things as they become useful to users …
I don’t want to veer too much off topic in this thread (maybe I did already, and them I’m sorry… I could move my posts to a new thread).
I’d say that on Fediverse shared vocabs are underused (ad-hoc interop) and Solid there’s a tendency to over-use (universal interop, semantic web). Looking from a practical standpoint: We’d like to have the average dev to be able to iterate on an app quickly, while retaining a ‘just-enough’ level of interoperability, plus the incentive to keep it interoperable as more apps target the same business domain.
In that light the specific business domain and the user stories that the dev wants to implement come first, and the interoperabilty second in priority. This is also what we see on fedi. Entering a new domain means one can “invent” the data formats on the fly, and the practical focus on the own app means it will probably be a messy vocabulary extension initially.
I think we are mostly on the same page. These micro-ontologies need a minimal level of specification. Just enough to make them useful for the next person, and with some documentation to them about business rules to take into account when implementing. But this needs to happen and these specifications needs to be findable and followed. And subsequently evolved if there’s a need for that. Doing so is the Process part I’m refering to.
IMHO you’re raising great points
I think in general, micro services need to evolve at the same pace as the shared vocabs and state
The situation today is slow moving vocabs, and fast moving software
So match the change control of the vocab with the speed at which you would like to innovate. Some slow fixed vocabs, some medium paced evolving stuff, some move fast and break things, as well as plain old JSON as first class
I agree. For SocialHub I proposed in the past processes along 3 tracks. I guess with 3 different speeds to them, and decreasing levels of formality that are needed:
Track 1) and 2) exist, but have stalled. 3) doesn’t exist other than in numerous fedi app codebases.
Update: Note that we have some informal agreement to have a FEDERATION.md and some projects have that. It is a form of documenting track 3), but not easy to find. There’s a possible Improvement to FEDERATION.md convention: Murmurations, and various discussions about capability discovery which in theory need not be a very complex thing if only referring to specific vocab extensions that are supported.
I’ve added some more design docs to microfed
And I’ve come up with a high level overview with codename: “Activity-LD”. Explanation below: