If the source code version control history is to be trusted, I started developing snac (a simple, minimalistic #ActivityPub instance server written in C) exactly one year ago (Sept 19th).
It was not my first experience with ActivityPub: I had built a prototype version in Python some months before (hence the "2" in the snac2 repository name), and back in 2019 I made some partial implementation for an unrelated (and now forgotten) blog project, so the protocol was not totally new to me.
These are my thoughts about one year of development.
Why did I start it? Because I read somewhere about the (still baffling to me) humoungous requirements of a basic #Mastodon installation. I read a lot of people affirming that was the bare minimum: "it CAN'T be done with less resources". But I've always seen it as a glorified short message application and challenged myself to write a feature-complete #Fediverse instance with the following goals: keeping it small, simple, easily deployed, and lacking the bloat software tendencies of modern times.
Did it come out as expected? not totally sure, but probably yes. I even implemented more things that I originally planned (I initially said a big NO to myself regarding adding Mastodon API support, but finally did it and it works mostly well). The program is still somewhat small (a stripped binary of less that 300k probably counts). The no-database, no-cookies, no-javascript absolute rules still apply. I'm fine with the (opinionated) web UI that shows conversations as threaded trees instead of the plain, dull stream of posts that Mastodon or Twitter show. It cooperates pretty well with the always growing ecosystem of ActivityPub applications.
Was the time and effort worth it? On this, I'm not sure. I'm old and depressed and unemployed, so developing snac has kept my brain busy and entertained for a little while. But it has been more work that I expected: the ActivityPub specification is a bit diffuse in some areas, so every implementation does some things a bit different and many corner cases had to be implemented; some parts (specifically, the Mastodon API) have been very tedious to implement and test; and also, helping users debugging remote systems is difficult and very stressing for me. Fortunately, some fellow developers have helped me and I'm immensely thankful to them.
Has it been a success? I'm pretty sure about this: no. I thought that the small footprint, the lack of moving parts and the feature set would be attractive to a large base of users, but this has not been the case. Perhaps I've been unable to reach the neccessary potential users for it to reach some critical mass (a failure of the PR department 😆). Perhaps what I consider interesting features (minimalism, footprint, the web UI concept, Mastodon API compatibility, etc.) are not that valuable for most. Perhaps people disregard it just because it's not Mastodon. Perhaps there are errors and crashes that I'm not aware of. Perhaps snac is rubbish and I'm unable to see it. The reality is that snac is a niche and unknown part of the Fediverse ecosystem and there is no sign that the user base will grow from the current small fistful of deployments out there.
What about the future? I'm also not sure. Apart from some pending bugfixes and wishlist items mentioned in the TODO file, I've implemented all the features I initially expected and then many more, so I consider snac a finished program. New bugs will happen, that's for sure. New ActivityPub applications will show out there and, if experience tells me anything, they will all have slightly different protocol interpretations that will need some code tuning on my part. Development will continue; snac is a maintained program. But big changes will probably not happen anymore.
If you're looking to host your very own single-user/a-few-users #fediverse instance, you cannot go wrong with #snac. It is simple to install on Ubuntu and works very well with some really solid clients. It is also written in C, so it is fast, with few dependencies. Great work @grunfink, you've got a new monthly supporter on Ko-fi!
I've just released version 2.45 of #snac, the simple, minimalistic #ActivityPub instance server written in C. This one includes fixes to some nasty bugs and some interesting contributions:
Fixed a collision in webfinger caching. This may affect federation with some software, so I recommend an upgrade.
Fixed crashes in some command-line options.
New command-line option state, that dumps some information about the running server and the state of each thread (note: this feature uses shared memory blocks and you may need an argument to the make call in older Linux distributions; please see the README file for details).
Fixed a bug that may leave an inconsistent state for a followed actor in a special case of repeated messages.
Mastodon API: added some fixes for integration with the Mona iOS app (contributed by jamesoff).
Added support for ntfy notifications, both using a self-hosted server or the official ntfy.sh (contributed by Stefano Marinelli).
Never heard of it before, but having a Mastodon-compatible instance packaged in Debian is great. So maybe time for my own instance? 😁 Will at least toy around with it. The question is on which host. But I suspect my Raspberry Pi running Debian Unstable will do. 😎
When someone asks about options for servers or clients I have a habit of tagging recommendations, and when there is not an account for the thing, I have to stop and search for a dev or find a website address to link to etc.
The number of instances based on #snac2 has been on the rise in recent days.
When looking at the statistics, it appears that the (still in testing) instance of BSD Cafe is currently the most populous.
Can I proudly say we're the largest #Fediverse (snac) instance? 😉
Using the Mastodon API (that means: not using the internal web server) makes the snac2 experience much snappier. That's expected: rendering and transmitting the html requires more time, no js involved at all.
I'm glad to announce the release of version 2.35 of #snac, the simple, minimalistic #ActivityPub instance server written in C. This time is nothing fancy, mostly bugfixes:
Fixed broken URL links with the # symbol on them.
Fixed people-being-followed data loss after not logging in for a long time (actor objects were purged too soon).
Fixed bug that made impossible to vote on polls that were replied to.
Don't show 'ghost' no-longer-followers in the people list.
When sanitizing HTML input, unsupported tags are deleted instead of escaped.
Fixed crash on missing headers while checking signatures.
Mastodon API: several bug fixes (contributed by Poesty), improved account object (contributed by Haijo7).
There is new a user configuration setup checkbox to mark an account as a bot.
Call me crazy, but I've started implementing the #MastodonAPI into #snac, the simple, minimalistic #ActivityPub instance server written in ANSI C that everybody loves. When it's ready, you will be able to operate your snac account from a Mastodon-compatible app like #Tusky and the like.
I hope to have it working read-only in a couple of days, but who knows.
Tonight, the snac.bsd.cafe instance will run from here. The Raspberry PI 4's internal SD is in read only, while the disk is ZFS, with #BastilleBSD managing the snac jail.
I'm happy to announce version 2.21 of #snac, the simple, minimalistic #ActivityPub instance server written in ANSI C. This time there are a bunch of things:
Users can now specify an expire time for the entries in their timelines (both their own and others').
Added support for sending notifications (replies, follows, likes, etc.) via Telegram.
Followers can now be deleted (from the people page in the web interface). Yes, to stop sending in vain your valuable and acute posts to those accounts that disappeared long ago and flood the log with connection errors.
The internal way of processing connections have been rewritten to be more efficient or, as technical people say, "scalable". This way, snac is much faster in processing outgoing connections and less prone to choke on an avalanche of incoming messages. This is a big step towards the secret and real purpose of the creation of this software: being able to host the account of #StephenKing when he finally leaves that other site.
The note action from the command-line tool can also accept the post content from the standard input.
Usage tips: never reply to toxic people (apply the MUTE button to them). Enjoy a coffee. Smell the sea. Listen to Mahler. Spend a bit less time in social media and a bit more with your loved ones.
I'm glad to announce the release of version 2.38 of #snac, the simple, minimalistic #ActivityPub instance server written in C. This release also includes some security fixes, so I recommend all users to upgrade soon:
More vulnerability fixes (contributed by yonle).
Added support for ActivityPub Group and Page objects. This allows subscribing to Lemmy channels and interacting with them.
Confirmation messages to follow requests are sent as soon as possible (i.e. bypassing the usual output queue).
Fixed crash when accessing some static or history objects.
I've just released version 2.28 of #snac, the simple, minimalistic #ActivityPub instance server written in ANSI C, including the following:
Added a new notification area to the web interface, accessible from a link at the top, that also shows the number of unseen events. This area lists all notifications in reverse chronological order and provides a button to clear all.
More work in the Mastodon API. The new supported features are: notifications, post of new and reply messages (including attached images). Some API v2 entry points had to be implemented, so you'll need to update your HTTPS proxy configuration again, see snac(8). #Tusky no longer crashes, or so I think. The official app and close relatives like #Megalodon still don't work, though.
If you are not interested in this Mastodon API crap, you can compile it out of your #snac by defining the NO_MASTODON_API preprocessor directive and forget about it.
Fixed an HTML cache bug (it was not refreshed after editing a post).
Far too slow. I had to immediately revert to the "old" jail. It wasn't crashing, but the cpu load was 100% and responding with http error 499. It's been a nice experiment, maybe I'll try with Alpine Linux or different, a bit better (armv7) hardware. I think it can be working.
I find these "popularity contests" pointless, ridiculous and inherently toxic, and a signature of private social networks where the goal is not to help people communicate between each other.
This is the reason why #snac does not propagate how many followers nor likes a person have.