Plugins for fediverse platforms.

Where is this up to? Is anyone thinking along these lines?

I’ve seen @db0 espouse such (eg https://lemmy.dbzer0.com/comment/8581651) (sorry for the tag if annoying).

I’ve certainly thought of it myself … because it’s a pretty obvious idea for an ecosystem aiming for richness and sustainability.

Seems a perfect fit for reusable moderation tooling too, rather than each new platforms having that trouble.

This is essentially #bluesky 's idea it seems.

@fediverse
#fediverse

  • Jeff Sikes@mastodon.social
    link
    fedilink
    arrow-up
    0
    ·
    3 months ago

    @maegul @db0 @fediverse

    The most promising project in terms of plugins is Bonfire (they call them extensions)

    Forkeys have a plugin system already. I’ve built a few things with it, but usage isn’t widespread, at least outside of Misskey. I wrote a bit about it and created some documentation. (Maegul your name is super familiar, apologies if you already knew about this)

    https://box464.com/posts/firefish-plugins-conclusion/

  • Skull giver@popplesburger.hilciferous.nl
    link
    fedilink
    arrow-up
    0
    ·
    3 months ago

    How would this work? Would there be some kind of standard API? How would you apply thread plugins to Mastodon, or timeline plugins to Lemmy? How do you deal with non-ActivityPub protocols?

    With the flexibility ActivityPub allows, I don’t think a single plugin interface makes sense. You’d need something with a ton of optional APIs.

    I don’t think the “plugin” model Bluesky has will work with any current ActivityPub server. Bluesky’s federation is set up completely differently, and its plugin architecture relies on there only being one single type of server software (the official one). I’m not even sure if they have federation enabled in production yet.

    I have theorised about an ActivityPub “firewall” that would allow for spam filtering and other moderation activity for any ActivityPub server, but I came to the conclusion that the requirement to intercept both incoming and outgoing traffic for effective usage would make the project quite complex.

    • db0@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      0
      ·
      3 months ago

      I don’t think generic apub plugins will work, but a plugin system for lemmy makes a lot of sense and pople like me could then help add the features we need

      • Skull giver@popplesburger.hilciferous.nl
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        3 months ago

        Perhaps, but as far as I understand the Lemmy code base, that would be pretty difficult to pull off. With changes that intensive, you’ll probably end up with a Lemmy fork.

        • db0@lemmy.dbzer0.com
          link
          fedilink
          arrow-up
          0
          ·
          3 months ago

          Plugin a thing in so many software, from firefox, to wordpress, to godot engine, to unity engine to whatever else. I doubt it’s something extraordinary to pull off

          • Skull giver@popplesburger.hilciferous.nl
            link
            fedilink
            arrow-up
            0
            ·
            3 months ago

            Yes, and they all have very deliberate APIs to make that possible. I’m sure it can be done, but I don’t think it’ll be merged into Lemmy with how overworked the devs already are.

            But don’t feel too discouraged, I’m sure the community will welcome your contributions if you can design a good API and build a proof of concept!

  • imaqtpie@sh.itjust.works
    link
    fedilink
    arrow-up
    0
    ·
    3 months ago

    It’s definitely a good idea. I’m not sure how high it is in priority when we still need to work on basic federation mechanics, but eventually I think it makes a lot of sense.

    • maegul@lemmy.ml
      link
      fedilink
      English
      arrow-up
      0
      ·
      3 months ago

      Well, the thing about establishing a plugin interface is that it facilitates 3rd party work on the platform by decoupling core development and its build processes from the development of any additional feature which can be done in whatever tech stack or manner the plugin developer wants.

      When it comes to moderation tooling I’m honestly a little confused that there isn’t more work or noise around a developing a sideloaded tool. With the current lemmy APIs for instance, surely one could make a web app, for admins/moderators only, that consumed feeds, exposed the admin/moderator powers and then added whatever additional information or views, filters, notifications or aggregations that moderators want in whatever UI that works better for moderators. Any ML/AI could also be added, with resultant metadata (or any other data for that matter) stored in a separate database. I’m probably missing something here, but I’m honestly a little confused.