What if we considered ActivityPub less as enabling ‘distributed Microblogging’, and more as a universal interoperability standard to knit together any kind of business and application domain?
In Fediverse Futures until now I have highlighted the opportunities to extend federated capabilities to many different domains (making more use of AP’s Linked Data foundations). Another thing then to address is how these domains are working together. The interoperability story, let’s say…
Now the AS/AP specs lend themself very well in interoperable application designs… witness the Fediverse. But they are only a small part in the overall picture. As we are planning to pitch ActivityPub to the European Union as the interoperability standard to be chosen for the EU Services Act (see: #meeting:fediverse-policy) we have to admit that interop is very, very hard to achieve, atm.
We are now at a stage where the grassroots and ad-hoc evolution of the Fediverse starts to work against us!
There is ever growing (accidental) complexity if we continue this way. At this moment:
- Onboarding has new devs following the steepest of learning curves (by experimenting, hearsay, and studying codebases).
- Documentation materials, tutorials, reference material is sorely lacking or incomplete.
- The very small SocialHub community currently simply lacks the time to improve things. We move at a crawl.
I digress. This is not new, of course, we know this very well. What I want to address in this topic is the way in which we design federated apps.
I co-maintain the very interesting and ever growing ActivityPub application watchlist, and what I observe is that - while federated apps are the goal - application design approach is more or less as follows:
- I want forum → I develop forum → How can forum federate?
- I want video → I develop video → How can video federate?
And because the federation is mostly a Microblogging domain, the last step boils down to “How can I map my domain to microblogging?”. App domains being added are pictured as boxed sets of features. They are application silo’s still, and the federation is mostly a bolt-on capability.
Wouldn’t it be great if from the outset we’d design for the tasks (workflows, procedures, whatever…) we’d like people to achieve with our app, and be able to easily knit things together that are already out there, choosing from a growing ‘library’ of federated capabilities and services?
Isn’t that what we are working towards in the end? A situation where the individual application boundaries are no longer visible in the end result for the people performing these tasks?
I would like to dedicate this thread to discuss what is possible here, what already exists, and where we can make progress.