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
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.
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
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
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
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
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.
2 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.
1 Like
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.
2 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
1 Like
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.
1 Like
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.