From silo-first to task-oriented federated app design

(For this topic also see a related set of toots posted on the Rethinking Humanity and Role of the Fediverse? toot thread)

In #fediversity: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.

Silo-based application design

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.

Task-oriented application design

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.

1 Like

Overall Ack and Thank You for this post.
Just some remarks

The specs do but certain “Actors” do not.
For the felt 1000th times I am linking the

SECTION 2 OF THE SPECS: “Conformance”

ActivityPub conformant Client
This designation applies to any implementation of the entirety of the client portion of the client to server protocol.

ActivityPub conformant Server
This designation applies to any implementation of the entirety of the server portion of the client to server protocol.

ActivityPub conformant Federated Server
This designation applies to any implementation of the entirety of the federation protocols.

It is called out whenever a portion of the specification only applies to implementation of the federation protocol. In addition, whenever requirements are specified, it is called out whether they apply to the client or server (for the client-to-server protocol) or whether referring to a sending or receiving server in the server-to-server protocol.

So can we, can the authors PLEASE DEFINE

entirety ???


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.

If I understand “entirety” like I do, interop is easy if we speak (talk) more and not less like now again with the SocialCG which otherwise makes no sense at all.

We should say “webstandards” and W3C recommendations (hard to understand for politicians) and then name ActivityPub as the probably best matching “interoperability standard” see Sandro’s tweet to Evan

What I favour in first place is what MdB Anke Domscheit-Berg demanded in the German Parliament and several MEPs support:
An EU funded fediverse


And I would like to leave here:

and

https://ethicsfordesign.com

and unfortunately

Both a healthy and active SocialCG as well as strong SocialHub community are vital, imho, to get anywhere in this effort. One of the big hurdles in this is: People doing the chores of community-building and knitting things together. An EU-funded fediverse is a great idea, and we should consider having a funded community commons, to alleviate time investment and commitment issues.

Think the focus should be on “standards and processes”, offering the methods and practices to ease interoperable implemention of the standards.

(wow, the Ethics for Design page is horribly designed for unusability)