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
Minor fixes: Allow unboosting your own posts (contributed by khm), CSS fixes for the Dillo browser (contributed by kvibber).
https://comam.es/what-is-snac
If you find #snac useful, please consider buying grunfink a coffee: https://ko-fi.com/grunfink
#snacAnnounces
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).
https://comam.es/what-is-snac
If you find #snac useful, please consider buying grunfink a coffee: https://ko-fi.com/grunfink
#snacAnnounces
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.
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.
- 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.
