I hope it is clear that “a recipe sharing app” is an example. One can replace it with other contexts. For example see James Smith 💾: "@TheFederatedPipe@fedia.io @smallcircles@social.c…" - mastodon.me.uk for the case of An open source, self-hosted 3D file asset manager.
I say this as dev of @manyfold; I’d like to be able to provide custom types that have meaningful semantics, but instead I need to use the restricted set of types that Mastodon will react to.
Let’s Reimagine Social
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:
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.
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.
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.
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.
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.
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.
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… 
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…
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.
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.
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.
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.
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:
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.
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.
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).
Two quick comments:
Great that you mention this. Local-first is a very broad concept, and we lack good system design practices and experience. Most use cases are for first pioneers. In the context of Leaf / Iroh / Willow protocol stack I started this discussion thread at Muni Town collective:
I consider “Social Web” to be what the average person experiences, i.e. the concept as it exists in the conceptual layer, and a top-level domain to explore. People say “internet” and “web” as non-technical language terms, without having this association.
hi! this will be my first post here… but I’ve discussed this topic a bit over on fedi. I was specifically encouraged to participate here, but I’ve been super lacking in time and spoons lately. I’m responding to the thread anyway so that I’ll be cc’d on future additions to it and will at least be thinking about it a bit more. I hope that’s okay.
Hi jens. Welcome 
And thanks for your contribution.
I have a long list of thoughts on this. I start with the following quote
I think these two statements go hand in hand: We need a language to describe a Fedi specification that has a few properties. I’m using the vision concept from above.
Second @jfinkhaeuser Would you be willing to take a look from time to time that we do not preclude the use of non HTTP technologies when not necessary?
Third: I personally think I made the first mistake here by talking about “Vision for a Fedi Specification”. I think the use of “a” implies that the result will be a single document. This is kind of not what I expect. I think that the result of “specifying the Fediverse” would be a sequence of documents, some of them being able to be used by arbitrary network technologies, some requiring HTTP.
Thanks for setting this up. I’m happy to join and contribute in any way I can.
I’ll probably focus mostly on practical aspects (UX and DX) and leave the meta-discussions to others.
I will attempt to keep my thoughts collected. I believe whatever is to come next needs to build upon the promises of the fediverse that go unfulfilled or have asterisks. The bulk of my focus will be user-centric. Users should be able to own & control their data without self-hosting, portable identities and accounts including content, resiliency to severed connections due to broad decision-making powers of admins/mods. I don’t recommend an instance only model there should also be empowered clients similar to how Nostr functions.
• What needs to be defined: lexicon/schemas (broadly), what is a user? What is a group? What is a post?
• Adoption of modern standards and technologies that are also backward compatible.
• Flexible architecture that allows for efficiency in costs and operations.
• Compatibility with ATProto, ActivityPub and Nostr as these are the most popular decentralized social networking protocols and this would incentivise developers and users
I think the “recipe app” is a great example, specifically because it’s not “yet another microblogging Twitter clone” that seems to permeate the Fediverse.
If we are serious about interoperability, it means that people on my music sharing site should be able to collaborate at some level with people on your recipe app. Each app should participate in the global ecosystem, instead of making siloed, incompatible networks surrounding each applications (with FunkWhale’s as an example of this)
Obviously, every app can’t be everything to everyone (which is kinda how AP currently operates) so what are the commonalities? What is the “Lowest Common Denominator” of the Fediverse?
I’ll propose that it’s: 1) identity, and 2) notifications. My username should be the master key that opens every door on the Fediverse, and allows me to subscribe to events in a myriad of other services. In this model, my Mastodon account doesn’t need to know how music (or recipes) are handled on remote servers, but I can get access to them, and seamlessly connect to those other specialized services when I want to.
Hey @aschrijver @helge — I want to sign my name in the commitment/offers section but I can’t see how. It the main article of the Wiki locked behind some permission setting?
A few things I’d like Fedi (v2?) to be based on:
Boundaries and consent should not be an afterthought. The protocol should be built around the idea that unwillingness to accept certain interactions is part of the core spec. That they can be rejected as well.
Identity should not be controlled by a system administrator. It should be cryptographic and in the hands of the people.
Similar to identity, data should be portable and not tied to an “app”. So yeah, local-first is a must.
Like mentioned in “* With a vision to move past AP and a willingness to break compatibility”, I don’t expect nor frankly care about compatibility with existing protocols if it breaks fundamentals. This shouldn’t be a concern, at least in the beginning. Bridges can be built later.
Data structure should be decentralized, with the MUST availability of metadata (i.e: types and semantic meaning) that can be considered, discarded or expanded. No “profiles”, or similar things to avoid falling for the same app-centric trap.
Networking and delivering should not be reliant on an “instance”. This is a single point of failure, and gives ample control to the system administrators over what people see without enforced transparency. Instances instead should act as relays, capable of lifting off typical battery, storage and always-online constraints of P2P social applications.
Howdy @d3v0,
One of your points – about backwards compatibility – has come up a few times, and I think it would be good to discuss in more depth.
I’ll agree there are huge issues with the existing ActivityPub specs (that’s why we’re here, yeah?) but I also think that cutting off backwards compatibility is the same as starting a new network from scratch. I think this effectively hands the distributed future to existing, large networks like BlueSky (and maybe Mastodon).
So architecturally, a clean break might be the best, easiest way to go. But in practical terms I think it dooms this effort before it begins.
I’m happy to be out-voted, but I’d like to keep “backwards compatibility” on the table, even if it’s only a stretch goal. As we start to finalize the features/specs we want to change, hopefully we can identify ways to make them backwards compatible, or at the very least identify a migration plan for how we could roll out breaking changes across the network.
Hello!
I understand the network effects and how hard life can be with a protocol that has no one on it, this is why I think breaking (native) compatibility should be okay if it breaks fundamentals, and also why bridges would be very useful.
I think this effectively hands the distributed future to existing, large networks like BlueSky (and maybe Mastodon).
Isn’t Mastodon already handed much of ActivityPub? It’s effectively their protocol. The non-standard quirks and abandoning a standard C2S API by almost every Fedi software for compatibility with Mastodon’s give me that impression at least.
That aside, I think there is an interesting idea to be discussed regarding Bluesky. The trade-offs made are to make it a better “public town” vs the more private/owned/decentralized AP box-to-box delivery. There is a lot to discuss there in terms of how we want this to go forward.
I’m happy to be out-voted, but I’d like to keep “backwards compatibility” on the table, even if it’s only a stretch goal. As we start to finalize the features/specs we want to change, hopefully we can identify ways to make them backwards compatible, or at the very least identify a migration plan for how we could roll out breaking changes across the network.
I agree it should stay on the table, but not a hill to die on, depending on what kind of technical trade-offs we face later 
+1 on a migration path regardless of the choice, one of the things that concern me with current Fedi software is lack of a way to smoothly switch software, a lock-in of its own. Data and identity portability being a minimum requirement would help with that.
Hey there Welcome folks! It is lovely to see response forthcoming, thanks much.
I do wonder how we best deal with questions like these. Whether we should move those to parallel discussion threads, and focus here exclusively on gathering people’s input and molding that into a comprehensive summary document?
I’d say we’d also need a chatroom to discuss my question (discussing here and the thread will TL;DR immediately). I have a Matrix chatroom available for this that is already appropriately scoped to “Laying the groundwork for the social web”, called Groundwork Labs
(Note: The chatroom is also available to associate with fedi.foundation. I’ll update Offers in the wiki).
I’m stealing a picture from @aschrijver to emphasize what I’m talking about:
For me it is
For me describing behavior is easiest to understand. In particular, it enforces that one supplies sufficient context to understand the problem. One example of a bad non behavior statement. I would call this assigning properties to a service:
We should have encryption
Stated like this property is meaningless. There is already plenty of encryption going on in the Fediverse. Everybody uses TLS to talk to each other. A more meaningful statement would be:
Given two users Alice and Bob.
When Alice sends Bob a private message.
Then the admins of Alice and Bob’s servers are not able to read the message.
Unfortunately, this is still too weak to constitute real secure messaging, as the admins would still be able to tell Alice and Bob are messaging. However, it is easy to decide if the behavior is satisfied or not.
All of these belong somewhere in the picture. Some at conceptual levels, functional, technical. We might thinks of good protocol layers or modules where each concern fits best. Knowing that there can be an elaboration from Gherkin behavior downwards, and elaboration from NFR’s upwards to fill in available options and blanks.
PS. I considered adding a “Protocol inspirations” section to the Instructions post for this. Like e.g. MIMI Architecture and CloudEvents.
I think there are two aspects:
Here new approach does not mean new new, but rather use what has worked in the past in similar situations and avoid what hasn’t worked for ActivityPub. See useful information above.
Howdy folks… a gentle reminder to wiki summarize what’s important. Oh… and please describe your level of commitment to contributing.
This vision needs a champion.
Another point to address in a vision is how to map social connections. As
describes ActivityPub has modeled the Publisher/Subscriber pattern with Follow. From a technical point of view Follow and actors forwarding activities should be enough. However, from an UX/SX perspective it’s awful.
Me subscribing to the account of my favorite farmers market merchant doesn’t make me their follower. Same for work colleagues or a fitness club.
Things should be fixed now, Ben.