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
Things should be fixed now, Ben.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.
3 Likes
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.
2 Likes
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.
2 Likes
Hey there 
Welcome folks! It is lovely to see response forthcoming, thanks much.
Improving procedure? Channels to use?
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).
1 Like
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.
3 Likes
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.
1 Like
I think there are two aspects:
- Moving discussions that are not about what belongs into a Fedi Specification away from this thread is good policy. So most topics concerning ActivityPub and Mastodon should be moved elsewhere. I said above that defining a protocol in terms of properties is problematic. I hold a similar opinion to defining a protocol based on other protocols or applications using said protocol.
- On Mastodon controlling ActivityPub: I think one of the main reasons why I am here, is that ActivityPub creates a bad power dynamic. A specification should allow people to read it, and then decide if something is right or wrong. ActivityPub does not pass this bar. Instead one asks “Will it federate with Mastodon?” However, the details of the situation are unimportant. What matters is that we want to develop a new approach that allows one to avoid these type of situations.
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.
2 Likes
Howdy folks… a gentle reminder to wiki summarize what’s important.
Oh… and please describe your level of commitment to contributing.
1 Like
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.
2 Likes
Quick insight drop-off to add to the wiki later: @erlend in Muni Town chatroom:
Thinking about ‘protocol as intent’.
Where I think there’s a need split between functionality that is added in upper layers of the protocol & tech stack, and for the protocol itself the Robustness NFR a key requirement to provide a solid enough base to also ‘design with intent’ and deliver said functionality. The functional must be able to stand upon the technical.
I just gave a long reaction to Christine Webber that argues for a more holistic approach to capture the intent of technology and ultimately our own day-to-day efforts in better ways. At the end of that thread I pointed to a proposal I posted today in relation to this effort.
See: https://social.coop/@smallcircles/113528415124633236
Please check out…
Proposal: Start a fellowship to explore the Social Web
1 Like
This issue needs a champion. I’m mostly writing it up, because I think that it is important and I know how. However, I don’t personally have some of these issues, e.g. I’ve never looked at a single like count.
Vision / Concept
The federated / decentralized network can reach eventual consistency.
Functional requirements
- [ ] After a week, if a conversation is shown on a server, it is complete, i.e. contains all replies, likes, shares, …
Non-functional requirements
- [ ] Is cheap on cost for server admins
- [ ] Respects privacy
For background:
and
2 Likes
Christine Webber: “These are the missing parts of ActivityPub”
" Alright you’ve heard enough critiques of Bluesky for a bit and I SAID I was gonna critique the fediverse and I am a WOMAN OF MY WORD. So let’s get into it! "
Consider Christine’s thread MUST READ, preferably from the top, scrutinising Bluesky.
https://social.coop/@cwebber/113528750380675735
How decentralized is Bluesky really? -- Dustycloud Brainstorms
Correctiverse™ … what is fedi done right?
Cristine: Here is your recipe for making the “Correct Fediverse IMO ™”:
- Integrate ocaps, which is possible because actor model + ocaps compose
- Content addressed storage!
- Decentralized identity (notice the y, I did not say DIDs) on top of ~mutable CAS storage
- Petname system UX
- Better anti-spam / anti-harassment using OCapPub ideas
- Improved privacy with E2EE (“encrypted p2p” even a better goal)
Below I’ll highlight just a few bullet points from the thread …
- Spritely aims for a for a socially collaborative revolution, is yet first focuses on a technical revolution.
-
It is too hard to build systems. We need stronger foundations (for ocaps, yet applies generally).
- “It’s too hard to build massively, securely collaborative tools right now.” (that are full-ocaps).
- “Conway’s Law flows in 2 directions”, technical system reflects social structure, and vice versa.
- “The tech flows from goals. So too does the social structure flow from the tech.”
- Important thought experiment: “In which ways are tech and social systems bidirectional?”
- At minimum fedi installed base should adopt content addressed storage + decentralized identity.
- Adoption of object capabilities is likely too big a step for most current implementers.
- Support content addressing (see Christine’s demo), “content can live anywhere”.
- Content can survive server shutdown (based on content addressing support).
- OCapPub critiques anti-abuse features of AP as inadequate. Lead to “nation state’ification”.
- OCaps to fill giant holes in AP specs wrt auth and authz. Proposed multiple times (here for Bluesky).
- OCap adoption must be bottom-up. Real challenges backporting right designs to existing systems.
- The ocap vision is critical to Christine’s bigger vision (which involves the PoC of the Fantasary).
- Intent is, but time will tell, to see if we can retrofit Spritely onto ActivityPub.
- Avoid getting accidental ACL’s that lead to confused deputies and ambient authority trouble.
- More detail: Christine offered to advise Solid project on ACL dangers, but was ignored.
- An actually decentralized network will have directed messaging, face challenges handling replies.
2 Likes
Oh, I like your division and additions of the top-level wiki into Vision / Component sections, with the section title indicating purpose or functionality. That is an improvement.
I just added added another resource to the inspirational resources list… Protocols, Not Platforms: A Technological Approach to Free Speech | Knight First Amendment Institute
(Copied from Muni Town) It occurs to me that in the given the current maturity of social web technology, in the open social stack there are likely multiple delivery models for information exchange. For instance loosely coupled event-based for service choreography, direct RPC for querying the social graph and knowledge network, and generic p2p local-first (app-)state synchronisation. And more in different slices of the stack e.g WASI/WIT interface definition language for polyglot component oriented development and service orchestration.
This relates to this reply by me. I’m just going to post it here and maybe people will get involved in discussing it
This is not a finished 
vision. It’s more like a first stab at something that is both necessary and false in the Fediverse.
Vision / Concept
The data / message format of our specification is easy to unambiguously parse.
Functional requirements
- [ ] Assuming a JsonLD inspired syntax: The type property tells me how to parse an object.
Non-functional requirements
- [ ] documentation, tests
Call to Participate
The discussion at Wiki: Vision for a Fedi Specification are 100% aligned with social coding movement.
Indications from our discussions thus far:
- There’s likely no ‘one size fits all’ social protocol. A rich social web is truly multi-protocol.
- The social web is still pure Innovators territory (except Microblogging++).
- New and existing initiatives still need multi-year investment and evolution to become viable.
Any form of success needs prolonged ecosystem participation. Hence I call to …
Align your independent initiative(s) to other autonomous ones under movement’s umbrella.
Proactively benefit from the “Leveraging the ecosystem” strategy the movement follows.
Join “Protocols for Social Web” fellowship with your initiative, and let’s get the ball rolling.
In Groundwork Labs chat @helge refined a list of 3 criteria for open social protocols that allow focus beyond the technology onto the ecosystem itself.
I think that I can simplify these criteria to:
- welcoming
- evolvable
- self-hostable
Making a list of 3 adjectives that a “Fediverse successor must satisfy” seems like right for the buzzword culture world.
I’m actually not
. One should formulate stuff as the experience of the user.
Or even as the experience “you can expect”. For example:
- You can host your own instance. means something that one can experience. It’s cool. I can sit down with the tutorial and a week to kill and get my own full service instance running.
- The network is dezentralized. is mostly meaningless for the experience. It’s [buzzword bingo].
Below my reflection on the list…
Yes, the current fedi doesn’t invite thinking out-of-the-box and build something innovative. It invites a deep focus on how the heck to get your feature into what exists already, and then the next feature, etc.
Good to describe this focus shift away from pure tech perspective. Indeed, decentralization is mostly an ‘implementation detail’, not a real feature. When generalizing to this list of just 3 adjectives they likely converge into universal qualities to pursue in the protocol design and/or design process that will make it “fit for purpose”.
I agree with Evolvable. I think that both encompasses Extensible (make new things) and Adaptable to change (existing solutions).
As for the other two… not so sure. I think here we should diversify the audience and separate into different stakeholder groups. I think at least 3 types should be considered:
- Technology adopters (providers)
- Solution designers (creators)
- Fedizens (clients)
I wouldn’t list “self-hostable”. It is more of a derived feature. I would say “self-sovereign” instead. Full control and ownership of social network solutions by creators and ultimately clients. The protocol design can facilitate clients to certain extent.
“Welcoming” is interesting. How would that translate? Good onboarding, ease of use, good DX, good basis for good UX. But also able to “carry healthy culture”? In that last bit is a whole world of SX to be applied. I think at the level of protocol design, here it comes to the extent at all levels that the technology is readily usable and useful. Technology “access” is then the word I’d choose. See:
The article presents the Five A’s of Technology access:
- Availability
- Affordability
- Awareness
- Abilities
- Agency
The “welcoming” is then an emergent quality of the technology becoming ubiquitous and gets out of the way as solutions are built. Ability to ‘compose’ solutions based on the right abstractions and building blocks. So then…
Key protocol traits
- Accessible
- Self-sovereign
- Evolvable
I find this notion of “self sovereignty” to be extra important, as there is this opportunity to apply new technology paradigms and open entire new markets with big opportunity for Sustainable open social software (SOSS). A self-sovereign social client has all the data under the control of a person operating a set of identities from there. Technology trends of local-first and vendor-neutral components may see both the role of the cloud and of browsers diminished.
(It is a pity that the term “self sovereign” has also been tainted somewhat by cryptobro shenanigans. Using just “sovereignty” may be better)
What the “Five A’s” above demonstrate, is the beginning of a nice breakdown structure of the protocol design.
So e.g. Evolvable may breakdown to:
- Modular
- Extensible
- Backwards-compatible
- Composable
Just musing. There are likely better ways to slice. Thinking also of Adaptable.
A concept like “vendor neutrality” may be deeply considered. To what extent can a protocol design enforce this?
1 Like
I’m still thinking about this. I think one of my main conclusions from all this. Our specification vision should be focused on what it gives you, and what is required of you. I would imagine it something like:
Our goals in writing this protocol and our expectations on you are as follows.
Evolvable
You can evolve the protocol into something that suits your needs. For this, we provide clear interfaces with specified extension points for you to use. As an offshoot of the “ActivityPub” based Fediverse aka the Mastodon protocol, we have also aimed to be compatible to it.
Our protocol is separated in layers, e.g. a wire format different from a content format, so that the layers can be evolved separately. We are glad if you want to work on a single layer! Clear interfaces allow you to do so. By supporting the behavior, we expect, you will be sure that your new layer is usable.
Self-sovereign
We do not feel the need to tell you what to do. You can build your own instance. You can modify an existing instance. You can change stuff as much as you want. All we provide is a framework for you to coordinate things.
Welcoming / Accessible / Be kind
Our goal is to create a community. This will require people to interact. This will require to attract new people. This will require not antagonizing people working on stuff. So be a good person.
Something like:
would then fall under enabling “Evolvable”.
1 Like
It is interesting to consider some non-AP ActivityStreams uses…
Linked Data Event Streams
Semantic Interoperability Community, part of EC’s Interoperable Europe (see also: github org) fosters:
Linked Data Event Streams
LDES Event Sourcing on Web-scale
LDES is a specification for publishing an append-only collection of immutable members. Consumers can then host one or more always in-sync Linked Data Fragments views on top of an Event Source. See specification, matrix chat. The objective of a Linked Data Event Stream is to allow consumers to replicate all of its items and to stay in sync when items are added.
DCAT-AP and DCAT-AP Feeds
Under maintenance by the same organization as LDES above, and recognized by Interoperable Europe is the Digital Catalogue Application Profile linked data spec, and its companion DCAT-AP Feed specification, described as:
This spec describes how to publish your DCAT-AP entity changes using the Activity Streams vocabulary and LDES.
Linked Data Event Notifications
Event Notifications in Value-Adding Networks
And the paper related to this specification:
Event Notifications in Value-Adding Networks
Patrick Hochstenbach, Herbert Van de Sompel, Miel Vander Sande, Ruben Dedecker, Ruben Verborgh
Linkages between research outputs are crucial in the scholarly knowledge graph. They include online citations, but also links between versions that differ according to various dimensions and links to resources that were used to arrive at research results. In current scholarly communication systems this information is only made available post factum and is obtained via elaborate batch processing. In this paper we report on work aimed at making linkages available in real-time, in which an alternative, decentralised scholarly communication network is considered that consists of interacting data nodes that host artifacts and service nodes that add value to artifacts. The first result of this work, the “Event Notifications in Value-Adding Networks” specification, details interoperability requirements for the exchange of real-time life-cycle information pertaining to artifacts using Linked Data Notifications. In an experiment, we applied our specification to one particular use-case: distributing Scholix data-literature links to a network of Belgian institutional repositories by a national service node. The results of our experiment confirm the potential of our approach and provide a framework to create a network of interacting nodes implementing the core scholarly functions (registration, certification, awareness and archiving) in a decentralized and decoupled way.
See also:
(Note: This can be interesting for ASK: Aggregating Software Knowledge, similarities to Murmurations)