So, you're captivated by the fediverse—the decentralized social web powered by protocols like ActivityPub. Maybe you're dreaming of building the next great federated app, a unique space connected to Mastodon, Lemmy, Pixelfed, and more. The temptation to dive deep and implement ActivityPub yourself, from the ground up, is strong. Total control, right? Understanding every byte? Sounds cool! But hold on a sec. Before you embark on that epic quest, let's talk reality. Implementing ActivityPub correctly isn't just one task; it's like juggling several complex standards while riding a unicycle… blindfolded. It’s hard. That's where Fedify comes in. It's a TypeScript framework designed to handle the gnarliest parts of ActivityPub development, letting you focus on what makes your app special, not reinventing the federation wheel. This post will break down the common headaches of DIY ActivityPub implementation and show how Fedify acts as the super-powered pain reliever, starting with the very foundation of how data is represented.Challenge #1: Data Modeling—Speaking ActivityStreams & JSON-LD Fluently At its core, ActivityPub relies on the ActivityStreams 2.0 vocabulary to describe actions and objects, and it uses JSON-LD as the syntax to encode this vocabulary. While powerful, this combination introduces significant complexity right from the start. First, understanding and correctly using the vast ActivityStreams vocabulary itself is a hurdle. You need to model everything—posts (Note, Article), profiles (Person, Organization), actions (Create, Follow, Like, Announce)—using the precise terms and properties defined in the specification. Manual JSON construction is tedious and prone to errors. Second, JSON-LD, the encoding layer, has specific rules that make direct JSON manipulation surprisingly tricky:Missing vs. Empty Array: In JSON-LD, a property being absent is often semantically identical to it being present with an empty array. Your application logic needs to treat these cases equally when checking for values. For example, these two Note objects mean the same thing regarding the name property:// No name property{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "…"}// Equivalent to:{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "name": [], "content": "…"}Single Value vs. Array: Similarly, a property holding a single value directly is often equivalent to it holding a single-element array containing that value. Your code must anticipate both representations for the same meaning, like for the content property here:// Single value{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": "Hello"}// Equivalent to:{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Note", "content": ["Hello"]}Object Reference vs. Embedded Object: Properties can contain either the full JSON-LD object embedded directly or just a URI string referencing that object. Your application needs to be prepared to fetch the object's data if only a URI is given (a process called dereferencing). These two Announce activities are semantically equivalent (assuming the URIs resolve correctly):{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Announce", // Embedded objects: "actor": { "type": "Person", "id": "http://sally.example.org/", "name": "Sally" }, "object": { "type": "Arrive", "id": "https://sally.example.com/arrive", /* ... */ }}// Equivalent to:{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Announce", // URI references: "actor": "http://sally.example.org/", "object": "https://sally.example.com/arrive"} { /* ... */ });// Now GET /.well-known/webfinger?resource=acct:username@your.domain just works! { /* Handle follow */ }) .on(Undo, async (ctx, undo) => { /* Handle undo */ });// Define followers collection logicfederation.setFollowersDispatcher( "/users/{handle}/followers", async (ctx, handle, cursor) => { /* ... */ });.lhr.life/✔ Sent follow request to @@activitypub.academy.╭───────────────┬─────────────────────────────────────────╮│ Actor handle: │ i@.lhr.life │├───────────────┼─────────────────────────────────────────┤│ Actor URI: │ https://.lhr.life/i │├───────────────┼─────────────────────────────────────────┤│ Actor inbox: │ https://.lhr.life/i/inbox │├───────────────┼─────────────────────────────────────────┤│ Shared inbox: │ https://.lhr.life/inbox │╰───────────────┴─────────────────────────────────────────╯Web interface available at: http://localhost:8000/.lhr.life/r/2 │╰────────────────┴─────────────────────────────────────╯
  • sorrybookbroke@sh.itjust.worksEnglish
    131·
    9 days ago

    I’d argue this is more like “I want to build a competitor to spotify so let’s decide between using mariaDB or writing an SQL compliant database from scratch”

    In your example, a database is the end goal and you can either start with a premade or make your own.

    Here, a social media platform is the end goal. Activitypub is a very important part of it but it’s not the entire piece.

    If we replace the parts of your analogy with the original your example would parse out to “I want to make a competitor to lemmies ActivityPub integration, so let’s start with fedify” which is not the same as the article states.

    Now, should you re-impliment a protocol yourself or use a generic library is the real question. Both have their benefits. With option A you have full code ownership and can wrap your solution around your end goal without the issue of dealing with the original to get needed changes accepted. You don’t have to worry about code not written by or understood by you. With option B, you get a more robust and almost certainly more accurate implementation. Along with, for free, better integration with any service using the same library. Very useful for a federated service when talking about cross platform.

    Both have many more positives and negatives of course and each person should decide on their own how to proceed.

    My opinion? I think it’s usually best to own anything which could feasibly be understood by a single dev. Even if each dev doesn’t. Anything larger shouldn’t be internal in my strong opinion unless very good, specific reasons apply that makes an external solution impossible or increadibly difficult. Most negatives of an external library also apply at that point with enough time.