Wiki: Vision for a Fedi Specification

Move your thoughts 💭 Ideas
, ,
#1

Social Web Protocol Considerations

Wiki Post. Please Participate! First read the Introduction by @helge.
Status → :brain:  Brainstorming. Gathering feedback.

Contents

    :muscle:  Co-creation log
    :hammer_and_wrench:  Protocol design template
    :people_hugging:  Protocol design process
    :speaking_head:  Feedback summaries

:muscle:   Co-creation log

Only with active participation can we get anywhere! Join the do-ocracy and commit yourself below.

Tasks

:orange_square:  Task title: Some concrete thing to pick up, volunteers sought… (@assign_me, @assign_me2)

:white_check_mark:  Start feedback gathering process: Gauge interest, gather feedback, reconcile ideas and perspectives toevaluate viability for starting a Protocol Working Group ( @helge, @aschrijver )

[TODO]

Commitment / Offers

  • @aschrijver:
    • Facilitator of community channels under social coding umbrella.
    • Represent various social web stakeholder types.
    • Help facilitate & improve design process + governance.
    • I offer fedi.foundation as ready-to-use devportal, a multi-author e-zine.
  • @benpate:
    • Developing ActivityPub applications with focus on interoperation between platforms
    • Will help develop and test interoperability drafts and real-world use cases

:hammer_and_wrench:  Protocol design template

Below we’ll refine structure of a draft Protocol Design doc, as we incorporate our feedback.

[TODO]

:people_hugging:  Protocol design process

Here we collect input for the inner workings of a Working Group that fosters healthy protocol evolution.

[TODO]

:speaking_head:  Feedback summaries

Add your summary to the list. Be concise and to the point. Use the following template:

@mention: url to your feedback comment below

Vision / Concept

[TODO] Brief text.

Functional requirements

  • [ ] Item 1: Brief explainer
  • [ ] Item 2: …
    [TODO]

Non-functional requirements

  • [ ] Item 1: Brief explainer
  • [ ] Item 2: …
    [TODO]

Input @aschrijver: protocol in larger context, conceptual-to-technical breakdown

For easy copy and paste the following is rendered as code

#### Vision / Concept

[TODO] Brief text.

#### Functional requirements

- [ ] Item 1: Brief explainer
- [ ] Item 2: ...

#### Non-functional requirements
- [ ] Item 1: Brief explainer
- [ ] Item 2: ...

Vision / Concept: A common and inclusive language to work on

See Wiki: Vision for a Fedi Specification - #10 by helge

Functional requirements

  • [ ] Provide reusable templates for tasks

Non-functional requirements

  • [ ] Be inclusive; avoid terms that people find offensive, e.g. allowlist not whitelist.
  • [ ] Minimal friction to clarify what something means
  • [ ] Language does not suggest a solution
3 Likes
#3

Welcome!

Introduction

This topic is for people who believe, that we need a better specification underlying the Fediverse. In order to develop such a thing, one needs a group of people that work towards a common goal.

The goal of this wiki is to collect such vision acceptance criteria. By a vision acceptance criteria, I don’t mean that a specification needs to implement them. I see them more as goal posts that can be used to justify decisions. For example, if people would bring up that one should use protobuf as a data format, one could use the above vision acceptance criteria to say NO as it would require the recipe sharing app developer to learn about protobufs. Similarly every body and their cows know how to use json.

I imagine that one can divide the vision into several parts. I’ll have some title below for people to fill out. However, these should just be viewed as suggestions. I might misrepresent things. Your vision might strongly disagree with my own. I’m definitely not aware of some issues and experience a lot of stuff differently than other people.

Developer Experience (DX) vision

  • When building a recipe sharing app, a developer has to worry more about converting three tea spoons of salts into sensible units, than what the exact data structure that represents a message is, or how other applications display the recipe (if they even do).

Social Experience (SX) vision

This probably includes the user experience. It should include stuff like being a safe space, or that one selects who one follows and thus decides what content one sees.

Security Requirements (SR) vision

This should contain stuff like: let’s make surveillance hard. However, that’s too vague. For example, surveillance for who? Are you worried about your ex showing up at your potluck dinner? Or are you worried about the FBI raiding the servers hard drives?

What we need

Requirements to create a better specfification were described here as

Fundamentally though I think what is required is:

  1. A working group
  2. Chartered outside of the w3c
  3. That does not work piecemeal
  4. With a vision to move past AP and a willingness to break compatibility

I replied to this with

I think alone clearly stating what this vision is, and formulating acceptance criteria for it, would be of immense help.

My personal acceptance criteria (of a social networking protocol) is: When building a recipe sharing app, a developer has to worry more about converting three tea spoons of salts into sensible units, than what the exact data structure that represents a message is, or how other applications display the recipe (if they even do).

Why here: @aschrijver has offered to help facilitate the discussion here.

Next steps

When I originally this post, my though was “Let’s make it a wiki, and people will just be able to add stuff”. Unfortunately, this is probably not sufficient to create a vision or have sufficient buy in. One not only wants a vision, but one sufficiently many people can agree on.

So we will need to determine once one has a sufficient list of vision items, which ones to actually include. My tendency here would be to aim for a smaller set than a larger one. However, I welcome a discussion on how to determine such a list.

Second, once one has this list, one should publish it somewhere. The obvious answer for me would be a FEP. Unless somebody has a beter idea.

2 Likes
DX Requirement content format
#4

:robot:  Please participate! How to provide your feedback?

  1. Remember we are brainstorming now. Withhold criticism of other people’s ideas, unless it adds something to the discussion.

  2. Provide your feedback in replies on this thread. Format into neat paragraphs and sections. You can expand or react to other comments, but avoid veering off-topic or too deep in nitty-gritty details.

  3. Summarize your own feedback in the Wiki post at the top of the thread. It is important to not forget this, for your feedback to be taken into account!

Active involvement is required in this process, so that chores are spread fairly between the participants.

Useful info

:gem:  IETF Resources

Do you have good resources on Protocol Design? Mention them in your feedback.

:gem:  Papers

3 Likes
#5

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.

#6

:rainbow: 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:

  • 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:

image
image1297×1798 159 KB

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

Diagram showing how ubiquitous language is consistently used in all communication, code and docs

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.

  1. Collect feedback – Inform relevant people, collect resources and links.
  2. Discuss – Collective brainstorming on input & feedback. Ideation, NOT criticism!
  3. Aggregate / Summarize – Gather results in a co-curated wiki document.
  4. Distill – Elaborate (one or more) protocol directions that seem feasible / attractive.
  5. Present – Iterate on step 1 to 4 until a Protocol draft(s) can be presented.
  6. 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:

:point_right:  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… :thinking:

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:

  1. The ease with which robust protocol implementations can be developed.
  2. 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).

3 Likes
#7

Two quick comments:

  • Offline first is not something you tack on afterwards. There’s a reason I presented Interpeer to space communications engineers, and that is that it’s still very challenging for most to consider what offline first really means. Space with RTTs to Mars of 44minutes or so makes for a good case, and most IETF folk still react to that by saying “oh, sure, timeouts will be longer”. No. Roundtrips suck, that’s the lesson. And if you want to avoid roundtrips, you avoid making requests in the first place. It’s a completely different design approach.
  • I’d personally stay away from the “social web” term. Most people will read “web” and think HTTP. That’d clash with the above shift in design approach.
2 Likes
#8

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.

1 Like
#9

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.

2 Likes
#10

Hi jens. Welcome :wave: 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.

Vision / Concept: A common and inclusive language to work on

Functional requirements

  • [ ] Provide reusable templates for tasks

Non-functional requirements

  • [ ] Be inclusive; avoid terms that people find offensive, e.g. allowlist not whitelist.
  • [ ] Minimal friction to clarify what something means
  • [ ] Language does not suggest a solution

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.

2 Likes
#11

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.

2 Likes
#12

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

2 Likes
#13

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.

2 Likes
DX Requirement content format
#14

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?

1 Like
#15

Welcome @benpate and @Damon! Great to have you here :hugs: Things should be fixed now, Ben.

1 Like
#16

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.

1 Like
#17

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.