FediForumTM

Upcoming Events

Project Map

@fediforum@mastodon.social
FediForum September 2024:

Unwritten Rules of Fediverse Development: What Do We Need to Know?

/2024-09/session/9-d/

Convener: Sean Tilley (@deadsuperhero@social.wedistribute.org)

Participants who chose to record their names here:

Notes

Premise: This is an open discussion for people, not a prescriptive talk. Building your first Fediverse application is enough of a challenge at the technical level, but there’s a whole body of information that people need to know about, but don’t have access or insight to without experience.

A few example situations:

  • Content Nation: got hit with CSAM because people didn’t know it was a bot / scraper.
  • Bridgy Fed: lots of people freaked out about a bridge from ActivityPub to Bluesky. The outcome eventually settled down, and Ryan found a good opt-in consent mechanism as a result of conversations, but the backlash was really hostile.
  • Maven: bad culture fit, didn’t research the space at all, just kind of jumped in all at once.
  • Hiveway: forked Mastodon and made it crypto, got John McAfee to present it as this groundbreaking new thing.
  • Various Fediverse search attempts: many prior attempts didn’t think about opt-in vs opt-out.

What areas are pain points for new developers?

  • Communication: not announcing intentions or taking feedback from existing communities, establishing relationships ahead of time.
  • Resources: formal specs don’t necessarily always spell out grassroots conventions. Mastodon, for example, does some bespoke stuff, and other platforms copy what Mastodon does. Informal standards are not things that are distilled into easy resources for people to learn about.
  • Points of entry: “Where do I go to learn what I need to know?”
  • Confusion: “What the heck is the @context property?”
  • Obscure-ish topics: HTTP Signatures, Webfinger, how servers react to different Content Types.
  • Spec conformance vs flexibility / alternative approaches: if there are two ways to do something, is the recommended approach to do the first way, the second way, or both?
  • Incorrect assumptions: sometimes, the community or group around the ecosystem just has incorrect assumptions about how things work, like “ActivityPub is push-only” or “ActivityPub is inherently private”.

Some key things to consider:

  • While having dedicated resources is a good thing, there’s a certain level of rigor that’s required to fact-check and evaluate community assumptions about how things work.
  • We should think about what things are being presented to people, and how, and why.
  • We don’t want to focus purely on the technical aspects. All ActivityPub software is inherently social, and requires more than just technical concepts to be factored in.

Note on my comment: Is there a particular app or program that you could point developers to as best in class?

Resources:

Tools