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?

  • rglullis@communick.newsEnglish
    1·
    1 year ago

    why don’t everyone just use a generic fediverse server and let the clients make it into Mastodon/Lemmy/Kbin/Pixelfed/Friendica/Firefish/PeerTube/whatever else?

    Yeah, I’d love that!

    That’s the point of the fediverse, it’s interoperable but you’re also not limited by one single standard as to how you want to expand.

    Just like the world wide web has always worked, and we managed to get by with only one single client (the web browser)?

    Lets say we settle for Mastodon’s implementation.

    Then we’d be off by a really bad start, because Mastodon does not implement a lot of the ActivityPub standard and hides a bunch of functionality under their own API?

    If you make a rigid spec outlining every possible feature, then you need a group of people to decide what the spec is

    Maybe we are talking about different layers of the OSI model, but the spec I’m concerned about already exists.

    If you want to make a superserver and superclient

    No, there is no need for a “superserver”. Other than storing messages, the server doesn’t really need to do much. Everything else can be done by the clients. There is also no need for a “superclient”, we can have different clients doing different things depending on what we want.

    My point is that I don’t mind have separate “lemmy” and “mastodon” clients to have the respective “link sharing” and “microblogging” applications, but I do mind the fact that I need to register two separate accounts and two separate actor identities to do it, because currently these applications are providing functionality on the server-side that could (should?) be on the client.