Could Inbox and Outbox be Microservices?

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)

3 Likes

I’ve written up a concept for this here:

Feedback welcome!

1 Like

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.

1 Like

If this can inspire you, SemApps use microservices (via the MoleculerJS framework). Here’s how ActivityPub services look like:

1 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 :slight_smile: ). 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

2 Likes

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.

2 Likes

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