Curiously, these messages mark the replied post differently (i.e. not using an inReplyTo field, but a quoteUrl one). I don't know if this is an ActivityPub standard or a private extension.
Anyway, I'll write it in the TODO file to take a look at it in the near future.
Mastodon API: Tweaks to support the Subway Tooter app (contributed by pswilde), added support for editing posts, fixed an error related to the edit date of a post, fixed some crashes.
Added a handshake emoji next to a user name if it's a mutual relation (follower and followed), because friendship is bliss.
Tweaked some retry timeout values for better behaviour in larger instances (thanks to me@mysmallinstance.homelinux.org for their help).
Fixed a nasty bug that caused the in-memory output queue to be corrupted under heavy traffic loads. This is a good reason to upgrade (thanks to Víctor Moral and Stefano Marinelli for helping me in fixing this).
Shared inboxes are now supported. This is not a user visible feature (hopefully, they will not feel any change), but it will significantly improve traffic for snac instances with many users and will open room for new features that are only feasible with these kind of input channels (this is not enabled by default; see snac(8)).
I've refactored all HTML code because it was somewhat of a mess; now it's much more maintainable (at least for me). I think I haven't broken anything.
Fixed crash in a special case of malformed query.
Mastodon API: some tweaks for better integration with more clients, and fixed a crash when processing boosts from kbin.
Fixed crash in the FastCGI code (thanks to Yonle for helping me debug this).
Added apache2 configuration information (contributed by Víctor Moral).
Added FreeBSD and NetBSD setup information and examples (contributed by draga79).
Accounts can be marked as 'private', so that they are not accesible from any non-authorized web UI (i.e. only through the Fediverse).
Outgoing connections that fail with a timeout are retried with a higher timeout limit. But, if the instance keeps timing out, it's penalized by skipping one retry.
If a post comes from a group or community (i.e. it has an audience field set), the buttons Follow Group or Unfollow Group are shown.
Pinned posts are never (incorrectly) purged.
Some RSS validation fixes.
Mastodon API: some tweaks to better match Mastodon behaviour in timeline entries and boosted posts are correctly returned, and some fixes for crashes.
Don't allow creating users which user name strings only differ in case. This was creating some problems (e.g. the webfinger interface doesn't allow case sensitivity).
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.
Show the 'audience' field (channel URL) if a post has one (like pages from lemmy channels and other forums).
Some web UI tweaks: the new post field is hidden by default (wasting less screen space), added a 'back to top' link at the bottom of the page and other minor tuning to the HTML and default CSS (contributed by yonle).
Fixed RSS (contributed by yonle).
Fixed interactive text processes (like instance or user creating) by calling fflush() after printing text prompts (it was broken on systems that use musl like Alpine Linux).
If you are worried about #snac eating up your drive space, you can set very restrictive data retention counters, like purging old data after 7 days or so. I've put special care into this (there are still some places where there is room for improvement, that will happen eventually).
You cannot migrate followers; the only thing you can do is to say what your new user is, and hope that they will follow the new user.
As well, you cannot migrate your own posts; they have an identifier that is an URL that contains the host name of your current instance.
What you can migrate is the people you follow; there is an export function in Mastodon that allows you to download them as a .csv file. You can import them from the command line; the process is documented in the administrator manual, snac(8). You can read these documentation online from https://comam.es/snac-doc .
Anyway, I recommend to just try it first and see if it meets your needs, and then worry about migration.
Does this thing really support ActivityPub? It doesn't even seem to respond to webfinger queries correctly (it returns a bunch of HTML and JS and gives a 403 status. Does it want webfinger queries to be HTTP signed?).
New user configuration switch to drop direct messages from people you don't follow, in order to mitigate spam from Mastodon open registration instances.
When updating user information (e.g. the display name or the bio), the changes are also sent to the people being followed (so they have an updated description about who the user is).
Mastodon API: account search has been implemented, so mention completion works from apps; new support for blocking users (this operation is called MUTE here).
They/their. Author of the snac ActivityPub instance server and other pieces of singular software. Not a real Grünfink.Git repositories at https://codeberg.org/grunfink