Lovely that you kicked this off! I made you moderator so that you have the tools to facilitate this first stage of exploration. It will be a challenge to properly collect, aggregate and summarize the chaotic feedback in free-roaming discussion threads. So one or more people should commit to this task, I think. What I think those people should do in parallel is:
- Iterate on a Protocol Design Template that can properly facilitate the feedback.
- Iterate on a Protocol Design Process to evolve the template as well as the Protocol Design itself.
Here’s some 1st high-level feedback. I might start by including a recent #ShowerThought:
This shows how the Protocol support shields us from technical details, so we can focus on Solution design and pay more attention to socio-cultural aspects of the Social experience we deliver with our solution.
Common understanding
Most important that we start speaking a common language, a Ubiquitous language (UL), right from the start. We should maintain a Glossary that defines the important terminology used. And avoid current Babylonian confusions and terminology flamewars at all cost.
Elaboration process
It will be difficult to find alignment. I propose a process that is roughly as follows:
Gather feedback → Discuss / Brainstorm → Aggregate / Summarize → Distill → Present → Kick-off?
Active participation is required, meaning that people are responsible to do the tasks and chores to see their own feedback being taken into account properly, according to procedures we define.
-
Collect feedback – Inform relevant people, collect resources and links.
-
Discuss – Collective brainstorming on input & feedback. Ideation, NOT criticism!
-
Aggregate / Summarize – Gather results in a co-curated wiki document.
-
Distill – Elaborate (one or more) protocol directions that seem feasible / attractive.
-
Present – Iterate on step 1 to 4 until a Protocol draft(s) can be presented.
-
Kick-off? – Organize kick-off event, launch a Working Group based on interest.
Conceptual model
Domain
In terms of UL a first question is: What is the top-level (business) domain?
This is an important question. We are at the forefront of technology innovation. There’s paradigm shifts, new computing paradigms, potentially disruptive technologies to explore. As well as their related design methods and tools. We should not delve into deep technical areas without having a good mental model on where all of these fit in the larger picture.
Top-level domain →
Social networking: All direct and indirect interaction between people.
Both offline and online. You might think this is crazy broad, but it is baseline for a mental model where we focus on evolving solutions that satisfy people’s needs. I.e. the reason we write software. We can drill-down quickly from here, elaborating specific subdomains.
Social web: Online support for Social networking.
This definition spans up an entire technology field, including open standards, protocols, enabling technologies and the entire ecosystem facilitated by these. More definitions:
Social web solution: Application or service that supports the Social web.
Fediverse: Installed base of Social web solutions on the Social web.
Fedizen: Person interacting with their Social graph on the Fediverse.
There will be a bunch more terms to define at this high conceptual level. Key is that all these are totally non-technical, yet can serve us all the way down the stack to increase common understanding.
ActivityPub?
It would be fabulous if the conceptual / mental model of social networking as conveyed by the AS/AP open standards were the reality of our DX (instead of a complex mess we can’t seem to untangle):
ActivityPub: Social web network communication protocol that facilitates Actors to exchange Activities and interact with their Social graph.
Given a robust extension mechanism there might be great SDK’s that directly benefit Solution developers by offering a very intuitive DX at such conceptual levels, shielding from the entire lower-level techstack.
An important realization given the definition above:
In the conceptual model of an ActivityPub-based social network there are No Apps or Platforms.
App silo and platform thinking may severely restrict the delivery model of social experiences for consumers.
Social web
I won’t delve deeply into this subject, but I would like to mention that in general I find the approaches I see people take to developing Social web solutions are too bottom-up technical. And that typical (often implicit) FOSS development processes aren’t optimal to develop Social web solutions.
Insufficient for ‘weaving’ a diverse and inclusive social fabric, where everyone can be safe and participate. Key to reimaging social. The Social Coding movement is dedicated to “Reimagine Social” and on this forum topics of Social experience design (SX), Sustainable FOSS (for the Social Web), and Free Software Development Lifecycle (FSDL of Social experiences) will be further explored, independently of any protocol initiative that may or may not be started.
Paradigm shifts?
It is remarkable that after 6 years of building with “distributed actors exchanging activities” the predominant use case is “Decentralized Twitter”. Some niche domain-specific apps, some poorly interoperable protocol extensions.
What is the full potential of decentralized social networks?
What are other new computing paradigms and how do relate?
What innovative technologies can be adopted and combined, or just inspire?
There’s a plethora of buzzwords circling our timelines. Which ones are feasible and what opportunities do they unlock? Spritely’s OCapN? Local-first P2P Social networking? Component-oriented polyglot development (“Wasm Everywhere”)? Content addressing? Solid? Small web? Etcetera …
To me the concept of “local-first computing” is quite interesting. Be in full control of all your data AND your apps. How’d we design and develop for a Local-first Social web? Make the cloud optional. Make the browser optional. Well, hmm… 
Requirements
Here some good thinking on a Protocol Design template (outlining the domain model of our protocol) may help slice things nicely in different categories / perspectives. We may find good inspiration for requirements and UL naming in existing protocol design efforts, e.g. the ATProto specs, or CloudEvents where they explicitly define protocol bindings and adapters as extension points.
Giving some random thoughts for now…
Protocol layers
There needs to be a well-layered protocol and/or protocol stack, layers easily discernable and named.
We’ve had long discussion re:ActivityPub’s unclear and confusing mixup in this regard, and ways we might bring more structure to it. That there may be an AP core / minimum profile, transport layer. And that there may be separate moving parts of the protocol that should be less intertwined, separately documented. Like e.g. a linked-data Knowledge API and a Message bus. Defined, as Sub-protocols? A Data layer maybe, where domain models and msg payloads are defined. Through a rigorously defined extension mechanism.
How we slice layers, modules, extensions, profiles has big impact on the DX of Fediverse solution developers.
Modules, extensions, profiles?
Have an absolute minimum profile, a core protocol. Anything that is optional is spliced into Modules possibly, where the module itself may consist of multiple artifacts. Just musing out loud.
Modules are different than Extensions. Modules _affect_the protocol itself (change behavior) while Extensions are built on top of the protocol, stacked on the Data layer. Extensions are commonly addressing domain-specific use cases.
Service delivery model
Currently we have mostly an Apps & Platforms delivery model, to use these much overloaded words. You choose an App (Mastodon) and then you choose a Platform access point (Mastodon instance) to sign up to and then you choose a compatible Client interface.
I envision a distributed social network of heterogeneous apps and modular services that can be orchestrated or choreographed into intricate Social experiences. Where you say “App” I say “Social experience” (and yes, it may be just an app). A lot of innovation is needed to get anywhere close.
We might call this an Apps & Services delivery model. However, if the conceptual model is “Actors exchanging Activities” as defined above for AP, then a more nuanced and innovative service-oriented delivery model might be defined, and “App” is not necessarily a meaningful concept.
In a pure service delivery model a person might use a universal client, a ‘social browser’ that can mash up / scaffold the front-end UI of the Social web solution.
Heterogenous services
The goal of support for heterogenous services is to empower people and facilitate greater levels of reuse in the ecosystem and provide richer social networking experience than one that can be offered in an ‘app silo’ delivery model.
The flexibility offered by protocol layers / modules / extensions allows for the design and deployment of solutions targeting wildly different use cases and business/application domains. Functionality should be able to be bundled and provided as a service, that can compose with other services (to form the solution / App / Social experience).
Various different facilities might be specifically supported in the specs, like service registries and service discovery, as well as service registration and invocation at runtime.
We come to thinking about spec + ecosystem support for service composition, component-oriented development here. Many opportunities for innovation.
At what level would I like to do service composition? Well, say you offer Moderated Communities, and I offer a Policy Engine service. Now you compose our services to become Community Governance. And then someone else integrates Community Governance with their Sociocracy service library.
All these integrations happening high in the stack, based on the conceptual / domain model facilitated by the protocol, and supported by language SDK’s.
Solution design focused DX
For the Social web to live up to its full potential and the Fediverse to sustain healthy growth it is crucial that a vibrant ecosystem emerges that starts to address a multitude of various social networking use cases, ideally in collaborative processes of creative co-creation.
In the Protocol Design we should take care both of:
- The ease with which robust protocol implementations can be developed.
- The resulting DX for solution developers who adopt a particular protocol implementation.
A DX focused on solution developers would support a more top-down inclusive design process (in addition to the bottom-up more technical elaboration we are familiar with). And for instance it might offer support for Domain Driven Design (DDD) and Event modeling.
This focus fosters rapid diversification of the ecosystem, that is also more likely to attract a broader developer base, to in turn speed up adoption rate.
NFR: Robustness
Follow the Robustness principle for protocols and protocol maintenance. The poor and poorly supported extension mechanism of AS/AP has shown the importance of this NFR.
NFR: Versatility
Versatile not in the sense of being a huge Swiss army knife of functionalities out-of-the-box, but being able to - from lower-level principles - model a wide range of social web use cases. Furthermore lower layers in the protocol stack should be flexible. Like not be tied to HTTP binding, but support multiple protocol bindings (like CloudEvents which also supports AMQP, WebSockets, MQTT, etc).
Please participate! How to provide your feedback?
IETF Resources
