Wish list for Fediverse standardization and other Fediverse technical “commons” activities

By Johannes Ernst


This is an update to my previous wish list, now incorporating discussions of a recent meeting I helped put together of the the W3C Social Web Incubator Community Group (SWIG) and FediForum, as well as discussions in several other FediForum sessions as well as various one-on-one conversations.

This wish list enumerates the work that I believe needs to be done by the technical Fediverse community to put the Fediverse on a more solid foundation, and make it ready to attract more developers and users. Note that obviously, not all these items are of similar importance and urgency. Note also this list does not include less-technical work, such as on moderation or culture.

Your feedback – and help making it so – very much appreciated!

Standards maintenance work on the core specifications

Fixes to the the core spec

  • According to reports, ActivityPub as-is is incompatible with common shared hosting environments (e.g. typical WordPress host), as it requires HTTP content negotiation.
  • Issues backlog

A design to reduce certain loads

  • Reduce protocol chattiness
  • Fan-out
  • Video
  • (Not my area of expertise, so I don’t have details)

Decide on the future of ActivityPub Client-to-Server

  • Split the C2S spec from the S2S spec?
  • Standardize the Mastodon API instead?
  • Invest in convincing developers to implement it?

Significant extensions of the core specifications with a view on standardizing them

Improved security and privacy

  • Signed content
  • Private messages

A standardized way to express terms under which content is provided

  • As I understand it, Bob Wyman calls that a Rights Expression Language
  • This probably should start with a use case collection


A single-document basic [Fediverse] interop spec, ie.

  • when I have written code for everything it says, my code will interoperate in some basic fashion with all other software that has implemented this document
  • no need to consult or understand other implementations
  • may be quite basic, e.g. text content only, only a minimal set of activity types
  • enables implementors to have a “MVP”-style interop at lowest-possible engineering effort (including the time required to read/understand the specs!)
  • This could be done as a “minimal profile” of a stack that contains a subset of AP [ActivityPub], AS [ActivityStreams], and Webfinger

Other profiles for specific use cases

  • E.g. propagation of event / calendar invites / RSVPs

Documentation and test

A test suite for the minimal profile

  • suitable to add to automated test suites
  • over time, this test suite can grow beyond the minimal profile

Documented behavior of leading ActivityPub implementations

  • What subset of the spec does each implement
  • What extensions does it implement, and which are required
  • Document the “folk wisdom” how to interact with a given implementation, so not every new developer has to learn everything from scratch
  • Get out of “trial and error mode” when attempting to interoperate with another ActivityPub implementation

A branding program for products that have passed the test suite

  • As an implementor, you get to put the sticker on your product.
  • In particular, in the places in the product where users “connect” to other servers in the Fediverse, like “Visa” is displayed at the POS terminal
  • I believe this will become critical if/when larger orgs with potentially different value systems connect to the Fediverse

JSON-LD conformance

  • Tests to make sure implementations are JSON-LD conformant

Libraries in the major languages

  • Full stack, not just ActivityPub

User expectations and usability across the Fediverse

A set of web “intent buttons” for Like, Follow, Post, etc that work across sites

  • like they exist for centralized social media
  • as easy to use for the user
  • we can argue how this can be accomplished technically. I have opinions, but for this wish list, they are immaterial, as long as I get those buttons :-)

A design for search that meets the requirements of all relevant parties and points of view

  • This is probably far less a technical problem than one of successful communication

Best practices for content propagation

  • E.g. resolve the “It has 5 likes here but 10 over there” issue and related.

Improved identity management across the Fediverse

  • Easy-to-use single-sign-on across servers. Use case: I use several apps for different content types (like micro blog and video). Bonus: they all post from the same identifier
  • Easy-to-use persona management. Use case: I have a personal and a work account, bonus if they can be on the same server
  • Identifiers not tied to the domain name system

Attract more participants

  • Get major implementors involved (e.g. Mastodon)
  • Make the place where technical work is done welcome and the work pleasant