Federated Processes: Combining Valueflows and ActivityPub

In follow-up to From silo-first to task-oriented federated app design - #5 by aschrijver may I suggest a more interesting (to me) use case?

Here goes:

I want to organize a lovely dinner for some assembled Fediversians. (I know, I know, after we are all immune to Covid…)

So I request contributions of recipes, ingredients, equipment, a kitchen, a dining room, people with cooking skills, etc etc.

Then the assembled catering crew will want to coordinate their activities and contributions also using the fediverse.

(All of that could be expressed using the Valueflows vocabulary, but would require some of those Processes and Methods you mentioned. Or start with one recipe and the activities to assemble the requirements and deliver the food to one or more people.)

For Processes and Methods, this thread about Flow-Based Programming and compositionality might provide some ideas: LIBRANET.de | Display

1 Like

I have followed FBP, but from a distance out of interest. Fiddled with NoFlo UI a couple of times (didn’t find it really intuitive, tbh). The idea is fascinating. Question is, if it is the most fitting model for future fediverse… and in this distributed, task-oriented environment.

At FBP on wikipedia, you see mention of the Actor Model and this model will be taken to next-level by @cwebber Spritely project:

Mandy component: “[…] Thankfully this should be a very clean mapping, because both Goblins and ActivityPub follow the classic actor model. Mandy’s design is to bridge the worlds of distributed Goblins programs and ActivityPub by providing an easy mapping between them.”

We have concurrent, distributed processes / workflows / orchestration, and it would be interesting to see how they can be modeled. And especially while still being easy to reason about, design, implement, test, control, etc. at scale.

There’s not really a lot of information out there.

As I said elsewhere, I am really interested in domain-driven design (where ‘bounded contexts’ match linked data vocabulary designs), because of the ways it allows non-technical people be directly involved in the translation of their needs to technical solutions, as well as well as advantages in terms of modularity and testability later on.

I know DDD and actor model go well together. Also there’s a recent talk by Vaugn Vernon about Reactive DDD that comes close in terms of concepts. Traditionally Microsoft with .NET solutions are exploring the DDD fields, and in the past I’ve briefly worked with a (then just released) Akka actor model, where you can also find distributed workflow processes solutions.

The image above shows something close to a microservices architecture, except the green services are much larger than is common in these designs. They represent a single domain’s bounded context.

In part 3 of this distributed systems article series Actor Model Hidden in Plain Sight a lot comes together with DDD, CQRS, Actors. And workflows, where they exclaim “It’s a finite state machine!”:

Lastly there are other cool projects that might take a lot of the work away from app implementers. A notable example is:

From their docs:

Temporal Workflows are suitable to implement scalable actor systems. A Workflow execution represents a single actor, uses signals for events, and automatically keeps track of the state using the backend service.

A typical pattern is to have a Workflow instance per business entity:

  • A Workflow that tracks the status of a single IoT device.
  • A loyalty program that accumulates reward points per customer.
  • A routine that manages a unique resource in a conflict-free manner.

Each flow responds to asynchronous events from a target entity, persists some corresponding state, and takes actions according to the defined rules.

REA (the ontology behind Valueflows) is an example of Domain Driven Design. Eric Evans, author of the original DDD book, and Martin Fowler, another practitioner, were on my shepherding (review) committee for this pattern http://mikorizal.org/dependent_demand.pdf in the 1997 PLoP conference:
PLoP 97 -- Washington University TR 97-34

Evans and Fowler thought it qualified as DDD.

Dependent Demand is one of the other main patterns behind Valueflows: Dependent Demand · GitBook

1 Like