I'm glad to announce the release of version 2.53 of #snac, the simple, minimalistic #ActivityPub instance server written in C. It includes the following changes:
New user feature to search by post content (using regular expressions) or tag.
Added some (partial) support for Event object types.
Minor fixes: Allow unboosting your own posts (contributed by khm), CSS fixes for the Dillo browser (contributed by kvibber).
If you find #snac useful, please consider buying grunfink a coffee: https://ko-fi.com/grunfink
Shamar
in reply to The Real Grunfink • • •Snac run as a daemon.
I wonder how hard it would be to turn it into a cgi: it should start, read the config, execute the task requested via HTTP (read from stdin) and close.
Maybe lock when appropriate.
Also (despite not being an issue for such service) I wonder how much the performance would suffer.
The Real Grunfink
in reply to Shamar • • •Hello. I don't think it would be impossible, but I think the experience will be severely lacking. The start and stop times of #snac are fast, but from the top of my head, these things could prove problematic:
- The maximum number of simultaneous processes would be harder to control (it should be done on the frontend http server, and that would require specific configuration for every server implementation).
... show more- Every activity (likes, boosts, posts) generates a very big bunch of connections. After a new one, the process should manage the full queue and not exit until it's done. If there are a bunch of these operations still running, the http server would not open on new queries, or at least it will require some configuration tuning. As it's now, it's trivial to reserve resources and give top priority to incoming requests.
- And most important, the problem of retries. The fediverse is a jungle of overloaded, fallen, slow servers. Activity messages should be stored somewhere to be retried later, probably after a t
Hello. I don't think it would be impossible, but I think the experience will be severely lacking. The start and stop times of #snac are fast, but from the top of my head, these things could prove problematic:
- The maximum number of simultaneous processes would be harder to control (it should be done on the frontend http server, and that would require specific configuration for every server implementation).
- Every activity (likes, boosts, posts) generates a very big bunch of connections. After a new one, the process should manage the full queue and not exit until it's done. If there are a bunch of these operations still running, the http server would not open on new queries, or at least it will require some configuration tuning. As it's now, it's trivial to reserve resources and give top priority to incoming requests.
- And most important, the problem of retries. The fediverse is a jungle of overloaded, fallen, slow servers. Activity messages should be stored somewhere to be retried later, probably after a timer. This is much harder to manage from a CGI, that only runs on demand.
As I say, it's not impossible, but a project with this approach should be carefully developed taking this thinks into account.
Shamar
in reply to The Real Grunfink • • •