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?

  • Skull giver@popplesburger.hilciferous.nlEnglish
    1·
    1 year ago

    C2S leaves a lot of things open and isn’t documented the greatest. It also doesn’t really provide many of the features people expect, leaving it all up to the client to provide a comfortable experience.

    In theory this isn’t a problem. The Lemmy frontend could just be an abstraction layer over the AP server, providing a web interface for all of its features. Apps could also implement threads and such on any C2S capable server if they agree with each other how things like voting works.

    However, that is all incredibly I efficient. Though Mastodon and Lemmy have purpose-built databases, they still run into performance issues. A basic ActivityPub server would be absolutely terrible for performance when you have a decent amount of users.

    There are a few C2S clients, but no pure C2S servers that you can just set up and use. With some extensions, I can see C2S becoming more relevant, but as it stands right now, it’s just not a friendly protocol to develop against. I tried, and I couldn’t even find a good reference for how to do authentication from the client (there was a mention of OAuth but very little details) and I couldn’t find anything that offered a plain and simple C2S API.

    • 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.

      • Skull giver@popplesburger.hilciferous.nlEnglish
        1·
        1 year ago

        You’re not wrong, Lemmy’s API is rather crudely documented. It’s not 1.0 yet and they have plenty of funding related milestones to hit before the end of the year, so they have good reason not to invest too much time, but the Lemmy API certainly needs some docs.

        Alternatives on the Fediverse (Mastodon/Calckey/Akkoma/etc.) all have much better API docs. Lemmy and Kbin are relatively unfinished and unfortunately that comes with all the downsides.

        However, Lemmy has an SDK available (that you may need to generate). The ActivityPub C2S API has gems like:

        Unfortunately at the time of standardization, there are no strongly agreed upon mechanisms for authentication. Some possible directions for authentication are laid out in the Social Web Community Group Authentication and Authorization best practices report.

        Servers MAY support uploading document types to be referenced in activites, such as images, video or other binary data, but the precise mechanism is out of scope for this version of ActivityPub. The Social Web Community Group is refining the protocol in the ActivityPub Media Upload report.

        “How do I log in” and “how do I upload an image” isn’t specified by the C2S API at all. All you have is suggestions. That makes the entire protocol kind of useless to implement in its current state. You can pick a backend implementation you like and write your application for that, but that does come at the cost of breaking all other clients.

        There are a few C2S implementations. You can use Pleroma and forks or Fedbox together with a client like Andstatus if you want to use C2S. The main design of AndStatus is oriented around Twitter/Mastodon more than anything, but it does allow reading threaded comments (like on Lemmy).