Hey everyone,

I’ve been pondering an idea thats been stuck in my head since forever and wanted to get your thoughts on it.

Has anyone ever considered the possibility of developing a line of code or a platform that runs on Activitypub that allows non-ActivityPub protocols to integrate seamlessly into the Fediverse?

Imagine a system where platforms like Bluesky, NOSTR, or other Protocol-based networks could “plug in” to the Fediverse.

This would effectively translate their unique protocols into ActivityPub, enabling interaction without requiring these platforms to adopt ActivityPub themselves.

Think of it like a tree: ActivityPub serves as the trunk, while non-ActivityPub platforms form the branches.

This approach could SIGNIFICANTLY expand the Fediverse and make it accessible to platforms reluctant to natively support ActivityPub.

As well as allow various platforms with different protocols to interact with each other, without the need to use “Bridges”, “Mirroring”, etc.

Don’t get me wrong, im not hating on Ryan, Fedy bridge, etc., but services like those are basically using Sticking Plasters, Duct Tape, and Chewing Gum to try and stick together different platforms.

I find this idea interesting, but I lack the coding skills, time, and energy to pursue it.

I’m curious if any developers or tech enthusiasts here have ever thought about, or worked on, something similar.

What challenges do you foresee, and could this be a viable path for potentially expanding the Fediverse?

Looking forward to hearing your thoughts and ideas.

  • johntash@eviltoast.org
    link
    fedilink
    English
    arrow-up
    17
    ·
    6 days ago

    Isn’t what you’re describing basically a bridge? If not, what’re you proposing to do differently?

  • rtxn@lemmy.world
    link
    fedilink
    English
    arrow-up
    10
    ·
    edit-2
    6 days ago

    You mean a service that translates between ActivityPub and another API? I’m pretty sure that’s just a bridge.

    As for the challenges:

    • It would have to be maintained constantly.
    • It would have to be updated to reflect changes to an API in a timely manner.
    • It would need to handle different versions of APIs (goodness knows even Lemmy instance operators have trouble with that).
    • It would need to handle features that don’t translate one-to-one between instances.
    • It would have to be transparent enough to allow a non-technical user to use it, but opaque enough that a non-technical user doesn’t blame issues with the bridge on the connected services (see for example: the Bottles packaging kerfuffle).
    • …and so on. Lots of challenges.
    • mesamune@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      5 days ago

      As a software developer this sounds a lot like zapier. And it’s a very hard problem to solve. If someone wants to do it sure but every time an API changes…whoo boy. Not fun.

  • macattack@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    6 days ago

    I use the bluesky bridge. One of the issues is that it is opt-in instead of opt out. I feel like most of the people I find that are using the bridge are likely also part of the federated universe to begin w/.