Mastodon and/or Mastodon-compatibles really do need a "suppress this thread from my timeline" feature, like the "mute thread notifications" but for when you don't want to see it at all.
useful for when one of your mutuals whom you usually love and support goes on a special interest bender that you don't super care about, but when they aren't good about tagging/consistent keywords, or a keyword mute would catch too many other threads.
Mastodon and/or Mastodon-compatibles really do need a "suppress this thread from my timeline" feature, like the "mute thread notifications" but for when you don't want to see it at all.
The fediverse server I develop, #snac ¹, has this feature with a Hide button. You can suppress full conversations or just a subtree of one. Further replies to hidden threads are also immediately dropped.
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).
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.
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 am just so amazed at how well the @phanpy web client works with #snac. I started self-hosting phanpy last night (it is a pure static web app) and it works seamlessly. Makes me very happy when things go like they're expected. Thank you for this @cheeaun!
Finally installed #snac2@grunfink! Straightforward process, no major issues. It works very well with @Tusky Only issue I've had has been adding attachments. Is that supported or is there a file limit size? In any case, great job. Big fan so far.
Attachments are totally supported, being them images, video, audio, whatever. But, if you are experimenting "file too big" errors, they do not come from #snac itself (there is no enforced limit), but from your nginx / Apache / whatever web server; try reconfiguring it to allow larger POST uploads.
Look at how @mikedev designed events in @streams! I would love to see this implemented in other software. @julian have you thought about how @nodebb would display an #ActivityPub event yet? Does @silverpill's @mitra have any support? What about @grunfink's SNAC?
#snac doesn't support this Event activity type yet, but it doesn't seem too hard to add some support for it (it's the first time I find one in the wild, to be honest).
I've just added some very basic support for this type (basically, not dropping them and showing them as if they were regular posts, with a mark to note that they are events). I understand that what make this type interesting is adding the possibility to add actions like intention to attend and such, but I will also wait for standardization.
I'm glad to announce the release of version 2.52 of #snac, the simple, minimalistic #ActivityPub instance server written in C. It includes the following changes:
Posts that were liked or boosted can now be unliked and unboosted.
Outgoing message timeouts are no longer hardcoded and can be configured (see snac(8) for more information).
Fixed a bug that caused some incorrect unfollows under special conditions (with shared inboxes enabled and users from the same instance that follow each other, the internal message distributor was confused).
Mastodon API: Added support for lists.
Added a header to avoid over-zealous caching in some browsers (contributed by louis77).
Added support for running and federating inside hidden networks like Tor, I2P or Loki (contributed by iwojima).
Fixed an error processing polls coming from Pleroma instances.
Yes, it does; at least, for the limited, perverse meaning of "federation" that Threads allow. I mean: you can follow Threads accounts with no problem and receive their posts and/or boosts, but you cannot reply nor interact with them in any way because Threads ignores interactions from the "real" Fediverse.
I notice that when viewing a snac profile from another instance all instances show zero followers and zero followees. What do I need to configure for the snac server to report the correct numbers?