I’m reading the ActivityPub spec here and it seems pretty fit for client-to-server communications. Yeah, it might be somewhat bulkier than your typical rest api, but it’s more universal, which begs the question: why do mastodon and lemmy both decided to implement custom (and incompatible) APIs for their clients to talk to the servers? Wouldn’t it be more straightforward if e.g. my voyager app talked ActivityPub to lemmy.world which then talked ActivityPub to lemmy.ml or something.

What am I missing?

    • farcaller@fstab.shOPEnglish
      1·
      1 year ago

      I wouldn’t quite call Lemmy’s protocol much friendly either. I’m trying to implement it and it’s a bit of a mess, honestly. There’s absolutely no documentation, private database specifics leaking into the public interfaces, and an absolutely horrendous authentication scheme.

  • Max-P@lemmy.max-p.meEnglish
    1·
    1 year ago

    It could probably work but would quickly turn into a mess of custom extensions.

    For example, ActivityPub has no concept of sorting by hot or active or new. ActivityPub also doesn’t specify how a client would authenticate to a server to post on your behalf. There’s definitely no ActivityPub message for registering a user account.

    So it makes sense that S2S only does the bare minimum for the purpose of federation of content, while instances with varying implementations can implement whatever C2S protocol makes the most sense.

    For example, should ActivityPub expose a Lemmy post as a nested thread, or a Mastodon microblogging-like format and let the clients reassemble the thread? How should a Mastodon client present a Lemmy community and threads? How about a Lemmy client connecting to a Mastodon server?

    If we put that in ActivityPub, you’re pretty much bound to supporting it forever because other servers will eventually expect those protocol extensions, whereas it’s much safer to change a C2S protocol.

    Keeping the ActivityPub simple has a lot of benefits if we don’t want the fediverse to remain really interoperable. A Lemmy client can reasonably expect that a given server supports a given set of features, providing a much more reliable experience than basically spaguetti of supporting every possible features and presenting the data weirdly.