tux spinning

codeberg: https://codeberg.org/asudox

aspe:keyoxide.org:D63IYCGSU4XXB5JSCBBHXXFEHQ

  • 15 Posts
  • 490 Comments
Joined 9 months ago
cake
Cake day: January 18th, 2025

help-circle







  • Yep. I did use those endpoints with the ModeratorView (The bot doesn’t need posts or comments from communities it doesn’t moderate) on my first attempt. I went with the federation approach at last because of future scalability issues. Though that is probably an exaggeration. If the default rate limit is 180 read requests per minute, that would be more than enough, honestly. The scale at which the scalability issues I mentioned would appear at about more than 4500 comments/posts per minute. Frankly, I think we’ll never reach that in the near future. So actually the rate limiting issue is practically not an issue for the foreseeable future.

    The plugin system would work. The fetching problem would disappear.

    Though I don’t think the federation code would be huge. I am not trying to make it compatible with all platforms. For example I’ll write the required Lemmy ActivityPub structs to send moderation related activities and actors. The Group’s instance would handle distributing the activities, so even though this project might not federate with Piefed for example, it would still receive the activities the bot sends to the Group’s inbox through the instance’s software, Lemmy.

    If someone wanted to get the bot to work on another Ap platform that supports groups, they would have to write the necessary Ap actors, activities, and a bit of glue code, and that would be it… or at least that’s how I’m planning it.

    I guess I’ll try to work with the plugin system if I can’t achieve what I want and keep it simple. It would at least be a learning experience, if nothing else. Thank you for the info.


  • Well, my initial idea was to build this only for lemmy and yes it would be easier that way if I didn’t care about scalability.

    However, the API was not good enough for my use case. Polling new posts and comments was my main issue with it. So mostly scaling issues. You could miss some posts and comments. The amount of API requests would get bigger with the amount of communities the bot moderates. There are also some problems with the rate limits.

    They can be solved by directly querying the database, but who’s going to give you database access? So you’d have to host lemmy yourself just for the bot. And I’d imagine the database would grow pretty fast with the number of communities. I explicitly do not want to store any posts or comments.

    Another solution would be using Lemmy’s new webhook system, but I don’t know how reliable it will be.

    So I stopped halfway through and started a new project with new goals:

    • Make a new federated platform

    With federation, the problems above would be solved. This also allows it to be hosted without having to find a suitable Lemmy instance for it or even self host one yourself.

    • Stronger integration with platforms via a modular federation system

    If I made it depend on Lemmy, a strong integration with other platforms wouldn’t be possible. Piefed has features that Lemmy doesn’t, for example. People can maintain a set of platform specific activitypub structs and enable the bot to federate with that platform.


    Not really answering your question, but I’d like to make a clarification: The bots will only be able to operate within the boundaries of the communities they are appointed to (or I guess groups). They cannot manage any instances. Furthermore, my main intention is for them to be used primarily as moderation bots, but they can also be used as general purpose bots within the community.