Note that unless you’re a Lemmy instance admin, this doesn’t have much use to you.
Until this package came along, if you wanted a bot that responds to events, you had to manually traverse all comments/posts/whatever at a fixed interval. With this package you can actually react to events directly from the database. It’s implemented in a very efficient way by connecting the package directly to the Lemmy database and using native Postgres features to get the events (LISTEN/NOTIFY if you want to get technical).
The webhooks themselves are inserted into a separate SQLite database (API is coming) and allow for both simple and complex filtering of the incoming data. The system is already in use by two of my bots, @[email protected] and @[email protected] who now both receive the information about being tagged in a comment in seconds (the actual reply takes a little longer, but that’s because of the nature of the bot).
Currently you can be notified about a post or a comment, other types are trivial to include as well.
Let me know what you think!
yeah, but im seeing a reference to the doubling of my standing-processing as now i have an insert-after-event that didnt exist before… is that right?
i mean i get that youre pushing the processing to a different, functional mechanism, but its still additive processing on the server that needs accounting… and seems expanded.
Yeah, everything you do takes processing power. This is done in a way that minimises the impact. There’s no insert-after-event that I’m aware of. Also I’m not sure what you mean by expanded.
right, i was just curious how much processing this is. it gets expensive quick on a large instance, efficiency matters. might be negligible, but i watch my services like a hawk.
This feels like a moot point. I promise you this is much more efficient than the rest of Lemmy is.