One year of #snac
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.
https://comam.es/what-is-snac
If you find snac useful, please consider buying grunfink a coffee: https://ko-fi.com/grunfink
The Real Grunfink /
npub1p7…q0jxq
2023-09-19 10:07:02
Author Public Key
npub1p77whr3cyukyulgej4qxyeee6gjxexumj4lsh9a40x0q4g5t72sqzq0jxqPublished at
2023-09-19 10:07:02Event JSON
{
"id": "59be1fd68d51794a536857fa89cdd80081004e096a8884bccdc68fd3df000ef3",
"pubkey": "0fbceb8e38272c4e7d199540626739d2246c9b9b957f0b97b5799e0aa28bf2a0",
"created_at": 1695118022,
"kind": 1,
"tags": [
[
"t",
"snac"
],
[
"t",
"activitypub"
],
[
"t",
"mastodon"
],
[
"t",
"fediverse"
],
[
"proxy",
"https://comam.es/snac/grunfink/p/1695118022.899300",
"activitypub"
]
],
"content": "One year of #snac\n\nIf 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).\n\nIt 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.\n\nThese are my thoughts about one year of development.\n\nWhy 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.\n\nDid 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.\n\nWas 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.\n\nHas 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.\n\nWhat 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.\n\nhttps://comam.es/what-is-snac\n\nIf you find snac useful, please consider buying grunfink a coffee: https://ko-fi.com/grunfink\n\n",
"sig": "af90cd755b1a1c6761acdaf4ee3be8383bbc667150e87e13b452f9c278241a551387d3c6c9d4a7fa22419121547cd9f25d961554f9a1340ba9679388e61e338d"
}