Wiki: Vision for a Fedi Specification

Ecosystem Care 🌅 Fedi Foundation
, ,
#22

I think there are two aspects:

  1. 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.
  2. 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
DX Requirement content format
#23

:robot:  Howdy folks… a gentle reminder to wiki summarize what’s important.

:robot:   Oh… and please describe your level of commitment to contributing.

1 Like
#24

:information_source: 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
#25

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…

:rainbow:  Proposal: Start a fellowship to explore the Social Web

1 Like
#26

:information_source: 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
#27

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! "

:point_right:  Consider Christine’s thread MUST READ, preferably from the top, scrutinising Bluesky.
:point_right:  https://social.coop/@cwebber/113528750380675735
:point_right:  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
#28

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.

#29

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 :bulb: 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
#30

:people_hugging:  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 …

:point_right:  Align your independent initiative(s) to other autonomous ones under movement’s umbrella.

:point_right:  Proactively benefit from the “Leveraging the ecosystem” strategy the movement follows.

:point_right:  Join “Protocols for Social Web” fellowship with your initiative, and let’s get the ball rolling.

Protosocial fellowship logo

#31

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:

  1. welcoming
  2. evolvable
  3. 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 :100: . 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:

  1. Technology adopters (providers)
  2. Solution designers (creators)
  3. 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:

  1. Availability
  2. Affordability
  3. Awareness
  4. Abilities
  5. 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

  1. Accessible
  2. Self-sovereign
  3. 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:

  1. Modular
  2. Extensible
  3. Backwards-compatible
  4. 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
#32

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
#33

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

Diagram. Conceptual overview of Event Notifications

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)

#34

What is our status?

  • We know high-level what we want. We have collected a ton of notes.
  • We do not have a good overview of what is happening re:social web. Compile shortlist for comparison, case studies
  • We can prepare a bootstrap process, and have a roadmap (without dates first, just sequence).
  • We can raise our voice on our plans, attract more people to walk together in this initiative, as a growing fellowship with a mission an objective and wild lands of potential in front of us.
  • Coupled to a growing diverse group of differently skilled people thinking about social experiences and the design thereof.
1 Like