grunfink

jamesoff, 5 months ago to random

@grunfink seem to be encountering a crash, spotted because Mona complains it can’t load notifications. Not happening every time, though. I have a core if it’s any use; I don’t know what I’m doing with one beyond this (image) tbh.

The request which fails is: GET /api/v1/notifications?types%5B%5D=mention&types%5B%5D=reblog&types%5B%5D=favourite&types%5
B%5D=follow&types%5B%5D=poll&types%5B%5D=status&types%5B%5D=update&limit=40

Is this something corrupted from the webfinger cache stuff?

grunfink, 5 months ago to random

Hello, #snacizens. I've just added a somewhat cool experimental feature to #snac: a new command-line to query the state of a running server, like

$ snac state /var/lib/snac<br></br><br></br>server: comam.es (snac/2.45-dev)<br></br>uptime: 0:03:09:52<br></br>job fifo size (cur): 45<br></br>job fifo size (peak): 1532<br></br>thread <a class="mention hashtag" href="https://comam.es/snac?t=0" rel="tag">#0</a> state: input<br></br>thread <a class="mention hashtag" href="https://comam.es/snac?t=1" rel="tag">#1</a> state: input<br></br>thread <a class="mention hashtag" href="https://comam.es/snac?t=2" rel="tag">#2</a> state: waiting<br></br>thread <a class="mention hashtag" href="https://comam.es/snac?t=3" rel="tag">#3</a> state: waiting<br></br>thread <a class="mention hashtag" href="https://comam.es/snac?t=4" rel="tag">#4</a> state: output<br></br>thread <a class="mention hashtag" href="https://comam.es/snac?t=5" rel="tag">#5</a> state: output<br></br>thread <a class="mention hashtag" href="https://comam.es/snac?t=6" rel="tag">#6</a> state: output<br></br>thread <a class="mention hashtag" href="https://comam.es/snac?t=7" rel="tag">#7</a> state: waiting<br></br>

It does this using a shared memory area, so some system restrictions may apply. I've tested on Linux and OpenBSD and it seems to work OK. You can call this command as an argument to watch or in a while true shell loop to have something like a poor-man's top utility.

This will be part of the 2.45 release. It's already in the public git repository, if any of you want to test it.

grunfink, 5 months ago to fediverse

I'm glad to announce the release of version 2.44 of #snac, the simple, minimalistic #ActivityPub instance server written in C. It includes the following changes:

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).

https://comam.es/what-is-snac

If you find #snac useful, please consider buying grunfink a coffee: https://ko-fi.com/grunfink

This release has been inspired by the album Until the Horses Come Home by #Undyed.

stesnac, 5 months ago to random

@grunfink I've noticed this: on this user's profile description, I mention I'm also @stefano - when posting something, I see a flood of webfinger requests for that user sent to the Mastodon BSD Cafe server from the snac instance, which I guess slows down (and raises the connections) when processing the queue.

n, 5 months ago to random

test server up and running!

n, 5 months ago to random

disable_inbox_collection true

#snac threads 16, 4 cores... lets see if I still hang.
#snac2

stesnac, 5 months ago to random

Nope. After boosting a couple of posts and posting a new one, it just hang. Snac2 continues to run, but just sits and wait, with cpu load at 0%
Back to the "old" VM

#snac2

stesnac, 5 months ago to random

Installing FreeBSD 14.0 on the Banana Pro - new #snac2 tests are coming 🙂

n, 5 months ago to random

Hi @grunfink I saw Mastodon API: fix whatever the fuck is making the official app and Megalodon to crash. in TODO and wondered if the issue I am having with elk.zone web frontend, and Moshidon (Megalodon fork I believe) are related. I do get an error from the Moshidon Android app, in case it is useful.

also: editing a post with an image removes the image 😆

For additional context I did initially build snac without mastodon api support (because I am a cabbage that can not read... I did not intend that) and have just rebuilt and reinstalled. I now get the Oauth page, but it gives that error when I enter credentials.

phanpy.social will let me log in just fine however.

Thank you for your time, I hope this is useful.

aa, 5 months ago to random

hello fedi

n, 5 months ago to diy

Okay so I'm really liking #snac so far.

I split off a personal account to keep my photography separate, and this one for my rambling thoughts etc.

Probably be some stuff on #HomeRenovation and #DIY, maybe some #mtb and whatever nerdery I doing with a website or home networking or whatever.

One day I'll do a proper #introduction post and pin it. Maybe.

tochu_cha, 5 months ago to random Japanese

@grunfink Hello.
I have re-compiled and re-installed "snac2" in a while, I could set avater and more !
Mr. (Miss ?) Grunfink, you have done and you are doing "very good job" ! Thank you.

stesnac, 5 months ago to tech

The first day of using #snac2 is coming to an end. Here are my observations:

1. It benefits greatly from ZFS and its compression. Performance is much better compared to an equivalent VM with OpenBSD.

2. Enafore and Phanpy work well. I appreciate Enafore's ability to hide replies and boosts (which Mastodon allows natively and also reflects in the API results). As for Phanpy, I like its interface. Of course, not everything works since the Mastodon API is only partially implemented, but the essentials are there. I especially like its integrated interface for threaded replies and notification display.

3. The "everything is a file" approach is very interesting. Even queues are treated as files, making it easy to monitor what's happening.

4. There are no character limits, and Markdown is natively supported - which is rendered correctly by Mastodon as well.

5. I believe that with larger numbers, Mastodon can show significantly better performance, mainly due to the separation of queue management and the web interface, as well as caching with Redis. I'm not sure how it would behave with 100 users connected simultaneously, reading everything from files and directories (perhaps better than I imagine), but this project isn't designed for large numbers. It doesn't aim to compete with Mastodon but to demonstrate that, without dependencies and high hardware requirements, one can successfully manage a node in the Fediverse.

In short, a decidedly positive experience that I will continue to delve into in the coming days.

Congratulations for the very good result, @grunfink !

Stay tuned!

#Tech #Fediverse #OpenSource #Performance #Observations #snac #Mastodon

stefano, 5 months ago to random

Hello, world - from a "future" BSD Cafe new service, powered by OpenBSD 🙂

This is a test. Can you read me?

grunfink, 8 months ago to fediverse

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