

Lemmy and Piefed both support disabling federation for specific communities, if you mean not allowing people from other instances to interact with the community. Or do you mean just not allowing comments?


Lemmy and Piefed both support disabling federation for specific communities, if you mean not allowing people from other instances to interact with the community. Or do you mean just not allowing comments?


Why loops? Long videos aren’t what loops is for.


peertube


Are you using postgresql 18? I tried upgrading yesterday from 17.6 and got an identical error message.


Welp, the fourth one can’t happen. Posts or comments by users won’t be stored in the database, so you can’t calculate “karma” for users.
The others are left to the community mods’ implementations.


Unfortunately there is also a need for automatic moderation.
Humans can’t catch everything.
By the way, mind telling me what was the most infuriating thing about Reddit’s automod to you?


All of them are possible with my current design plan, which is allowing mods to write the functionality themselves (instead of predefining them like in some other automods) in sandboxed Lua (might change).
I might still predefine some myself for performance.


Of course. Reddit’s automod is very simple.
My current design plan is leaving the implementation to community mods by embedding sandboxed Lua (might change).


For automated ones, sure. But if you just want to schedule some post you made, that functionality is already available in Piefed and will be available in Lemmy in the next 1.0.0 release as well.
There is something called OpenWebAuth that is currently in use by Hubzilla.
There’s even a FEP for it: https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md


You don’t need to calculate the average number of active users. If you do, it will be wasted resources and you probably will miss a few dozen.
Simply request the instance’s NodeInfo.
NodeInfo 2.1 (which Lemmy does implement) and I think 2.0 as well require implementors to provide correct user usage statistics. So you have total users and average active users per month/half year calculated on request.
This also means you can provide this service for other platforms that support NodeInfo.
Making a GET request to /.well-known/nodeinfo will give you the links to the instance’s NodeInfo documents.
In fact, you can recursively begin from some random known instance, get a list of other instances it is federated with, get their NodeInfo and repeat the process. NodeInfo also provides the name of the software (check schema).
You can use that.
FEP: https://codeberg.org/fediverse/fep/src/branch/main/fep/0151/fep-0151.md
Welp, I guess it needs some more development time.
Why not use something like Angelfish instead of Firefox?


I use Aegis on my phone.


I haven’t released the source code yet. The private repo at the moment is very messy in general so I am just waiting until I get a somewhat working pre-alpha done with the design that I am still experimenting with finalized. There’s still a ton of work to be done since I just started 2 weeks ago.


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


The platform should provide some of these out of the box, in my opinion.
I am trying to build a new activitypub powered platform just for user scriptable moderation bots, but I am stuck on the modular federation design.
This is my third attempt now.
They recommend people other american centralized social media as an alternative to Bluesky in response to this, yet again. When are they going to learn?
Yes. Can be done with scripts.