triptico.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
Added a new admirations entry point to the web UI, containing a timeline of liked, boosted and reacted posts. Please take note that, after installing the new version, it will start empty, and be filled with subsequent reactions (contributed by violette).
It's now possible to disable showing posts in a given set of languages.
Nested quoted posts are limited up to 3 levels.
New configuration knob: by setting keep_replies_posts to true in server.json, remote posts that a local user has replied to are retained in the public timeline, preventing them from being purged (contributed by hanchan).
New configuration knob: by setting keep_replied_me to true in server.json, remote replies to local posts are retained in the public timeline, preventing them from being purged (contributed by hanchan).
Ensure actors' public key PEM never includes anything after the end marker.
Fixed some memory leaks (contributed by inz).
Several additional keyId checks (many thanks to lainsoykaf for bringing this to my attention).
Fixed crash in the JSON parser (many thanks to nullenvk for bringing this to my attention).
Mastodon API: fixed lost custom emojis after edition (contributed by e0w0e).
Updated French, Brazilian Portuguese, German, Spanish translations (contributed by dragondaddy, daltux, zen).
If you find #snac useful, please consider buying grunfink a coffee or contributing via LiberaPay.
Toot, the Mastodon CLI client, works fine with Snac. Of course :)
RE: https://poliversity.it/@devconf/116792507141709633
A tutti gli amici che parteciperanno alla DevConf Italia: potrete seguire le previsioni meteo di Pavia direttamente dal Fediverso e da Delta Chat, nonché da sito web o feed RSS, da FediMeteo.
Sito: https://it.fedimeteo.com/pavia
Account Fediverse: @pavia
Canale Delta Chat: https://i.delta.chat/#39D39283B059D042F8991D73E3BA5DA4B5C5143B&v=3&x=EkZVVGPtEQe7P29NGC0Cj5Dd&j=RHh2965YcHFa4mVgfzS_rjxk&s=yR1k6-A0Swj-ZBL3VR9REow4&a=qpe4x4nnk%40chatmail.bsd.cafe&n=FediMeteo+Italy&b=FediMeteo+·+Pavia
Vi ricordo inoltre che il 7 Luglio alle ore 16:25 presenterò "FediMeteo, i BSD e il Fediverso: sotto il sole, senza nuvole, liberi e connessi" - proprio su FediMeteo e sugli strumenti di comunicazione liberi e decentralizzati.
Non mancate!
#DevConf #DevConfItalia #FediMeteo #DeltaChat #snac #snac2 #Fediverso #Fediverse #OwnYourData
📢 Siete pronti per il DevConf Italia?
🚩 A Pavia, il 7 e 8 Luglio del 2026, presso il Learning Space Cravino in Via Agostino Bassi 2 si terrà il primo convegno nazionale, a cadenza biennale, denominato Dev. Conference Italia.
Verranno affrontati numerosi temi quali: sicurezza, sviluppo applicazioni, didattica, fediverso, libertà e sovranità digitali che potete trovare sul programma.Venite a scoprire di cosa parleremo, vi aspettiamo numerosi!
I think it was snac, on microcontroller boards that take a fraction of a watt!Ohh... that sounds fun! I'd love to read up on that. Do you have a source?
#runsnac #snac2 #fediverse #alternatives #opensource
CC: @VasiliWz@hachyderm.io
Nooiiceeee!!! Native push notifications for #snac2 on iPhone seems to work
@gyptazy made this in https://gyptazy.com/blog/snac2-native-push-notification-support/
Run #snac!
Two things you can see here... It's pretty hot! That's why I stayed home and implemented a missing feature into snac. That's what you can also see - it finally sends push notifications to devices! In this case, we can see notifications coming from #MastoBlaster App for iPhone.
What we can also see, it's still a bit faulty and not the expected content, but a first success here at least ;) I'll make some further adjustments when there's time and get in touch with @grunfink@comam.es to check if we can get this upstream. Thanks to @stefano@bsd.cafe for testing with me :)
#fediverse #mastodon #fedi #activitypub #snac2 #c #programming #clang #MastoBlaster
What's your preferred clients for the Unix terminal (must be cross-platform, not Linux-only, for goodness, sake! 😅) and Android?
I've noticed that @tut@fosstodon.org and @pachli@mastodon.social (and other @Tusky@mastodon.social forks) don't quite like snac, and tend to act a wee bit cagey. ;)
Anyone have any other recommendations to try? https://snac.amd.im/amd/p/1781807020.988120
snac is rather awesome software. It's lightweight, exceedingly fast and just works.
Thanks @grunfink@comam.es (and other contributors to the project).
When I wrote about FediMeteo (https://it-notes.dragas.net/2025/02/26/fedimeteo-how-a-tiny-freebsd-vps-became-a-global-weather-service-for-thousands/) for the first time, I told the story from the beginning: the idea born almost by chance while checking the weather for a holiday, the memory of my grandfather, who for years had been my personal meteorologist, the decision to build something small and useful, and then the surprise of seeing people actually use it. What began as a personal experiment quickly became a small global service, still running with the same philosophy: FreeBSD, jails, simple scripts, snac, text, emoji, and a lot of small pieces doing their work quietly.
That article was mostly about the birth and growth of the project. This one is about one of the less romantic parts of the same story, although I have to admit that I find a certain beauty in it too: keeping the service light as it grows.
FediMeteo (https://fedimeteo.com) is still intentionally simple from the outside. A homepage, some numbers, a list of countries, and many ActivityPub accounts publishing weather forecasts. The posts are text and emoji. There is no JavaScript requirement to read the pages, no heavy frontend, no unnecessary media attached to every forecast, and no dynamic homepage recalculated at every visit just to show the same numbers. This is not accidental. It is the way I wanted the service to behave from the beginning.
But the more the service is used, the more the small details matter. A request that looks harmless when there are ten followers may become a repeated request when there are thousands of followers, remote instances, crawlers, previews, and other servers fetching the same public objects. In the Fediverse, the same small thing can be asked many times by many different places, each one with a perfectly legitimate reason. The backend doesn't care: it just needs to deal with the requests.
And in FediMeteo, the backend is snac (https://codeberg.org/grunfink/snac2).
I like snac very much precisely because it is small, clear, and efficient. It is not a giant application that tries to be everything. It does a focused job and does it well. But this also means that I want to respect its shape. I do not want to waste its threads on work that the reverse proxy can safely do. A snac thread serving the same public avatar again and again is not a tragedy, but it is still a waste. A snac thread answering the same public ActivityPub object several times in the same minute is doing real work, but often not necessary work.
This is the reason behind the HAProxy (https://www.haproxy.org) tuning I am currently using in front of FediMeteo.
It is not about making the configuration look clever. It is about keeping snac quiet.
This is especially important because snac uses a limited number of threads. I like that. Limits are healthy. They force us to understand what the service is doing, and they prevent a small program from pretending to be an infinite resource. But limits also make waste visible. If a few threads are busy serving files that could have been served from cache, those threads are not available for something more useful.
With FediMeteo the implementation is different because the reverse proxy is HAProxy, but the reasoning is the same. I have many small snac instances, each one in its own FreeBSD (Bastille (https://github.com/BastilleBSD/bastille)) jail, and one public entry point that has to route, terminate TLS, compress, cache, and generally remove as much repetitive work as possible from the backends.
This is, in a way, the natural continuation of the original FediMeteo design. In the first article I wrote that I wanted to manage everything according to the Unix philosophy: small pieces working together. This is another piece of that same puzzle. HAProxy does the edge work. snac does the ActivityPub work. Scripts generate forecasts. cron launches updates. ZFS gives me snapshots. FreeBSD jails keep countries separated. Nothing is particularly heroic by itself, but the whole system becomes pleasant because each part has a clear responsibility.
FediMeteo does not use media in its forecasts.
No images attached to the posts, no generated weather cards, no maps for each city, no decorative banners. The forecasts are text and emoji. This was a deliberate decision. Weather information does not become more useful just because it is put inside an image, and every media file used by the service would become something to store, serve, cache, federate, expire, back up, and occasionally debug.
Text and emoji are enough. They are accessible, light, readable in text browsers, friendly to timelines, and understandable even when someone does not know the local language perfectly. This was one of the original design principles of FediMeteo, and it also helps the infrastructure. Less media means less work, fewer cache entries, fewer repeated fetches, fewer surprises.
There is one exception: the avatar.
All FediMeteo accounts use the same avatar, and this is also intentional. I could have used a different avatar for each country, or for each city, or created something visually richer. It would have been nicer in some screenshots, perhaps. It would also have been operationally worse.
With one shared avatar, the reverse proxy has one very useful object to cache. It is public, identical for everyone, small, requested often, and therefore almost always hot in cache. HAProxy can serve it directly instead of asking each snac instance to return the same file. Since avatars are requested by remote instances, browsers, profile previews, and all sorts of federation-related fetches, this single decision removes a surprising amount of pointless backend traffic.
So the avatar is not only a visual identity. It is part of the architecture.
This is the kind of optimization I like most, because it starts before the software. It starts with deciding not to create a problem.
It is a static HTML page generated from a template. Once per hour, a cron script updates the numbers and statistics. It counts the data I want to show, regenerates the page, and then the page remains static until the next run.
This is not because I cannot make a dynamic page. It is because I do not need one. Boring is good.
The homepage does not need to query all the country instances on every visit. It does not need a database request for each user who opens it. It does not need to ask snac anything in real time. The numbers are useful, but they do not need to be updated every second. Once per hour is enough, and it also fits the spirit of the whole project: do the work when it is needed, then serve the result cheaply.
I have seen too many small services become heavy because the first implementation was convenient rather than appropriate. A cron job and a template are not fashionable, but they are often exactly what a page like this needs.
fedimeteo.comAnd many more.
www.fedimeteo.com
it.fedimeteo.com
uk.fedimeteo.com
jp.fedimeteo.com
us.fedimeteo.com
usa.fedimeteo.com
can.fedimeteo.com
canada.fedimeteo.com
At the beginning, it is always tempting to write one ACL after another in the HAProxy frontend. It is quick, it is explicit, and for five hostnames it is perfectly fine. But FediMeteo did not remain at five hostnames. As countries and aliases grew, a long chain of ACLs would have turned the frontend into a list of names instead of a description of how the proxy behaves.
So I moved the hostname to backend mapping into a map file:
fedimeteo.com backend_fedimeteoThe frontend then needs only one rule:
www.fedimeteo.com backend_fedimeteo
it.fedimeteo.com backend_it
uk.fedimeteo.com backend_uk
jp.fedimeteo.com backend_jp
us.fedimeteo.com backend_us
usa.fedimeteo.com backend_us
can.fedimeteo.com backend_ca
canada.fedimeteo.com backend_ca
use_backend %[req.hdr(host),field(1,:),lower,map(/usr/local/etc/fedimeteo.map,backend_fedimeteo)]This reads the
Host header, removes the port if present, lowercases the result, and looks it up in /usr/local/etc/fedimeteo.map. If nothing matches, it falls back to the main FediMeteo backend.I like this because it keeps the configuration honest. The frontend contains the policy. The map contains the data. Adding a country means adding an entry to the map and defining a backend. I do not need to make the frontend more complicated every time the service grows.
backend backend_itOne backend, one jail, one snac instance. This is exactly the same organizational principle as the rest of the project. If I need to reason about Italy, I look at the Italian jail. If I need to reason about the United Kingdom, I look at the UK jail. If one day I need to move a country elsewhere, the separation is already there.
mode http
http-reuse safe
server srv1 10.0.0.2:8001 maxconn 30backend backend_uk
mode http
http-reuse safe
server srv1 10.0.0.7:8001 maxconn 30backend backend_jp
mode http
http-reuse safe
server srv1 10.0.0.32:8001 maxconn 30
The maxconn 30 value is not a magic number. It is a ceiling. I want each small backend to have a visible limit in front of it. If something starts hammering a country instance, I prefer the pressure to appear at the HAProxy layer instead of becoming unlimited concurrent work inside snac.
http-reuse safe lets HAProxy reuse backend connections where appropriate. This is another small reduction in unnecessary work. Opening connections repeatedly is not the biggest problem in the world, but avoiding it is still better, especially when many small services sit behind the same proxy.
frontend https_inTLS defaults are set globally:
bind :::443 v4v6 ssl crt /usr/local/etc/certs/ alpn h2,http/1.1
mode http
option http-keep-alive
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256Port 80 only redirects to HTTPS, except for Let's Encrypt challenges:
ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
acl letsencrypt-acl path_beg /.well-known/acme-challenge/In the HTTPS frontend I also set the usual forwarding headers:
http-request redirect scheme https code 301 unless letsencrypt-acl
use_backend letsencrypt-backend if letsencrypt-acl
http-request set-header X-Real-IP %[src]And I add HSTS:
http-request set-header X-Forwarded-Proto https
http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"None of this is unusual, and that is fine. The interesting parts of an infrastructure are not always the parts that should be unusual.
cache mediacacheI keep media and ActivityPub JSON separate because they are not the same kind of traffic.
total-max-size 128
max-object-size 10000000
max-age 3600
process-vary on
max-secondary-entries 12cache jsoncache
total-max-size 16
max-object-size 1000000
max-age 60
process-vary on
max-secondary-entries 12
The media cache is larger and has a longer maximum age. In FediMeteo, this mostly means the shared avatar and a few static-looking objects. Since there is intentionally almost no media, the important cached object is requested very often and remains warm.
The JSON cache is smaller and short-lived. It is there for public ActivityPub GET requests, not to store federation state forever. A 60 second cache is enough to collapse many repeated requests that arrive close together in time, without pretending that ActivityPub responses should be treated like immutable files.
This distinction is important. Caching is not one decision. It is a set of small decisions about what a response means, who can see it, how often it changes, and what happens if it is served again.
acl is_media path_end -i .jpg .jpeg .png .gif .webp .svg .ico .mp4 .webm .mp3 .ogg .wav .flac .mov .avi .mkv .m4vThen I store the result in a transaction variable:
http-request set-var(txn.is_media) bool(true) if is_mediaThe cache lookup is straightforward:
http-request cache-use mediacache if { var(txn.is_media) -m bool true }
And on the response side:http-response set-header Cache-Control "max-age=3600, public" if { var(txn.is_media) -m bool true }
http-response del-header Set-Cookie if { var(txn.is_media) -m bool true }
http-response del-header Vary if { var(txn.is_media) -m bool true }
http-response cache-store mediacache if { var(txn.is_media) -m bool true }
The Cache-Control header makes the intent explicit. Set-Cookie is removed because a public media object should not carry session information. Vary is removed because I do not want the same avatar to fragment into many cache entries because of harmless header differences.This is aggressive only if removed from its context. In this service, with this media policy, it is a reasonable choice. FediMeteo is not serving private media under these paths. It is mostly serving the same public avatar over and over.
For the same reason, I clean the request before it reaches the backend:
http-request del-header Authorization if { var(txn.is_media) -m bool true }
http-request del-header Cookie if { var(txn.is_media) -m bool true }
I would not do this globally. I do it after deciding that the request is media. Scope is what makes these rules safe.The result is exactly what I want: the shared avatar becomes an almost perfect cache object. Small, public, repeatedly requested, and served by HAProxy instead of snac.
Accept header:acl is_ap_json req.hdr(Accept),lower -m sub application/activity+jsonThis part matters because ActivityPub uses content negotiation. The same path may return HTML to a browser and JSON to a remote instance. If the proxy pretends that a URL is always one thing, it will eventually cache the wrong representation.
acl is_ap_ldjson req.hdr(Accept),lower -m sub application/ld+json
acl is_outbox path_end /outbox
acl is_get method GET
acl has_auth req.hdr(Authorization) -m found
acl has_cookie req.hdr(Cookie) -m found
So I only mark public ActivityPub GET requests as cacheable:
http-request set-var(txn.is_activitypub) bool(true) if is_get !is_outbox is_ap_json !has_auth !has_cookieThere are several decisions here, all important.
http-request set-var(txn.is_activitypub) bool(true) if is_get !is_outbox is_ap_ldjson !has_auth !has_cookie
It must be a GET, because I am not caching deliveries or anything that changes state. It must not be /outbox, because outbox collections are not the traffic I want to cache here. It must not have Authorization, and it must not have cookies, because authenticated or user-specific requests do not belong in a shared public cache.
Then the cache can be used and populated:
http-request cache-use jsoncache if { var(txn.is_activitypub) -m bool true }http-response set-header Cache-Control "max-age=60, public" if { var(txn.is_activitypub) -m bool true }
http-response cache-store jsoncache if { var(txn.is_activitypub) -m bool true }
Sixty seconds is short, but useful. Federation often creates small clusters of identical requests. A remote server fetches an actor, another fetches the same actor, something asks for the same object, something retries. I do not need to cache these responses for hours. I only need HAProxy to answer the second and third identical request during the same small burst.This is microcaching in the most practical sense. It reduces repeated work without changing the nature of the service.
acl is_short_path path_reg ^/[^/]+/s/This comes from the same observation that led me to cache snac media with nginx. snac uses static media paths, and those paths often represent the kind of public, repeatable traffic that should not consume backend threads if the proxy can serve it. I call them "short", not because they are, but because the first time I saw them, I thought the 's' stood for "short", not "static". The name just stuck.
http-request cache-use mediacache if is_short_path
In FediMeteo this is less central than on a normal social instance, because I deliberately do not use media except for the avatar and basic static objects. Still, the rule fits the general policy: let HAProxy handle repeatable edge work, and let snac spend its threads where they are actually needed.
Vary, but not without limitsprocess-vary onI want HAProxy to process
max-secondary-entries 12
Vary, because content negotiation is real, especially when ActivityPub is involved. But I also want variation to be bounded. If every slightly different header creates another cache entry, the cache becomes a complicated way to miss.For media, I remove Vary before storing the response. A shared avatar does not need to vary by Accept. For ActivityPub JSON, I am more careful because the representation matters.
Again, the important thing is not the number itself. It is the decision to make variation explicit and limited.
http-response set-header X-Cache-Status HIT if !{ srv_id -m found }
http-response set-header X-Cache-Status MISS if { srv_id -m found }
This is intentionally simple. If HAProxy selected a backend server, I call it a miss. If no backend server was selected, the response came from cache, so I call it a hit. It is not a complete observability system, but it is enough to answer the first question I usually have after changing a cache rule.Did this request reach snac?
A test can be as simple as:
curl -I https://it.fedimeteo.com/path/to/avatar.pngThe second request should be a hit.
curl -I https://it.fedimeteo.com/path/to/avatar.png
For ActivityPub JSON, the test must use the right Accept header:
curl -I \And I also want to verify that cookies and authorization prevent public caching:
-H 'Accept: application/activity+json' \
https://it.fedimeteo.com/some/activitypub/object
curl -I \A cache that works should be visible. A cache that is invisible can be correct, but it can also be silently wrong. I prefer to know.
-H 'Cookie: test=value' \
-H 'Accept: application/activity+json' \
https://it.fedimeteo.com/some/activitypub/objectcurl -I \
-H 'Authorization: Bearer fake' \
-H 'Accept: application/activity+json' \
https://it.fedimeteo.com/some/activitypub/object
filter compressionThis keeps another common responsibility at the edge. The country instances can stay focused on snac and the forecast data, while HAProxy deals with client-facing compression for HTML, JSON, and ActivityPub responses.
compression algo gzip
compression type text/css text/html text/javascript application/javascript text/plain text/xml application/json application/activity+json
There is also a local Prometheus exporter:
frontend prometheusAnd I keep internal operational paths, such as statistics and Grafana, handled before the hostname map. These are small details, but ordering matters. Special paths should be explicit and early. The hostname map is for FediMeteo routing, not for every internal tool I happen to expose behind the same proxy.
bind 127.0.0.1:8405
mode http
http-request use-service prometheus-exporter
no log
The map keeps hostname routing manageable. The backend definitions keep each country isolated and limited. The static homepage avoids dynamic work for something that changes once per hour. The shared avatar gives HAProxy one very hot media object to serve directly. The media cache keeps public files away from snac. The JSON microcache absorbs short ActivityPub bursts. Header cleanup prevents useless variation. Connection reuse avoids unnecessary backend connection churn.
But all of this is only a longer way of saying one thing:
fewer requests reach snac.
That is the metric I care about here.
Not because snac is slow. If anything, FediMeteo exists in its current form because snac is efficient enough to make this kind of project possible on a very small VPS. But precisely because the whole architecture is small and pleasant, I do not want to waste resources where there is no need.
This is also consistent with the rest of the project. Forecasts are serialized by scripts. Updates happen every six hours. The homepage is regenerated hourly. Countries live in separate jails. Snapshots and backups are handled outside the application. No single component tries to be the entire system.
HAProxy is just another small piece, but it sits in the right place to remove a lot of repeated work.
It matches FediMeteo as it is now: almost no media, one shared avatar, static homepage, public forecasts, many small snac instances, and ActivityPub traffic that can benefit from a short public cache when there are no cookies or authorization headers.
If I decide one day to use media in forecasts, the media cache rules will need to be reviewed. If I use different avatars for each city or country, the cache will still work, but I will lose the very nice property of one shared, always-hot avatar. If ActivityPub responses become actor-dependent, public JSON caching must be reconsidered. If one country grows a very different traffic pattern from the others, it may deserve a different limit or policy.
This is why I do not like presenting configurations as magic. A good configuration is a written form of the assumptions behind a service. When the assumptions change, the configuration must change too.
The HAProxy layer follows this idea. It terminates TLS, routes hostnames through a map, reuses backend connections, serves the shared avatar from cache, microcaches public ActivityPub JSON, avoids authenticated and cookie-based traffic, and gives me a small diagnostic header to see what is happening.
There is no single brilliant directive here. There is only the usual work of matching infrastructure to reality.
FediMeteo publishes weather forecasts as text and emoji. The homepage is static HTML updated every hour. The accounts share the same avatar because it is enough, and because it is better for the cache. Each country has its own snac instance in its own FreeBSD jail. HAProxy stands in front of them and tries, quietly, not to bother them unless it has to.
I like this kind of infrastructure.
Not because it is invisible, but because when it works well, it leaves very little to say.
https://it-notes.dragas.net/2026/05/18/fedimeteo-haproxy-and-the-art-of-not-wasting-snac-threads/
#ITNotes #NoteHUB #fediverse #freebsd #haproxy #hosting #jail #networking #ownyourdata #server #snac #snac2 #social #web
Great news, you can now post a picture to https://subversive.pics interactively from your favorite internet browser!
You can achieve this by making a picture post inside the fediverse and tagging @subversive_pics (this works with snac, lemmy, mastodon, but not all of its forks, your mileage may vary)
If your picture makes it past the horp censors, your picture will appear on the subversive.pics website and the rss feed!
Incredible.
---
if you post something that you think should've passed the vibe and it doesn't get through within a reasonable time period, let me know. So i can update this list...
what it definitely works with:
- snac
- lemmy
- (some) mastodon
- akkoma
- gotosocial
- misskey (some?)
what it doesn't work with
:
- hometown
- glitch
I also took the chance to update #snac and, again, no surprises. Great piece of software.
"If you want to be in the Fediverse without relying on big intances, or if you just want to own your #data & #identity on the network, running your own instance is the way to go.
That is where Mastodon alternatives such as GoToSocial & #snac comes in.
snac (Social Networks Are Crap) is a minimalistic, lightweight #ActivityPub instance…perfect for single user instances or small communities, and it's so light that even a #RaspberryPi can handle it without breaking a sweat."
https://rochacbruno.com/deploy-your-own-fediverse-instance-with-snac.html
PRs must not incorporate any material generated by or with the assistance of any so-called "generative AI" tool or LLM.
#snac por otra parte fue más simple y rápido, no tiene una gran estética pero siempre me ha funcionado bien
Next up in a new #FediMerch store is #snac merchandise! I had to grab my own set of stickers for this one, the artwork is so cool!
You've got Susie, snac's default icon embedded in a QR code. And then this ridiculously amazing artwork from @prahou that is just a must have for your sticker collection - or on a shirt - or mug. Just get it!
The time is probably right.
Back in 2022, when I was still using iOS, I wasn’t completely happy with the Fediverse apps that were available. I was mostly using Akkoma, and the interface I liked the most was actually its web UI, even on mobile. So I started playing with Xcode and put together the foundations of an app tailored to my needs.
A lot has changed since then and today we have great alternatives like IceCubes, Mona, Ivory, etc. Each one has strengths and weaknesses though, so I picked up my old project again and kept pushing it forward.
So I’m happy to announce that my app will finally see the light: I’ve been using it for the past few days and, in my spare time, I’m fixing bugs and adding missing features. I’m building it around my own needs, so it doesn’t have to “appeal to everyone”. I wouldn’t call it opinionated, but it’s definitely targeted.
The app will have one key trait: #snac2 support will be a first-class feature, not an incidental one. Many apps, especially on iOS, support snac as a side effect, but the experience is often not optimal. In this case, the choice is deliberate and it strictly follows the Mastodon API support implemented by snac. So snac will work properly (within the limits of the platform, of course).
Among the features already implemented: the app is minimal and lightweight (under 10 MB, including debug code), easy on RAM, and privacy-first (for example it strips EXIF data from media before posting, so the server will never see it). On snac it also cleans up the "Boosted by Aoderelay" messages that appear when using a relay, removes the character limit, and supports posting in Markdown.
I also added support for Apple Intelligence to generate alt text, both for the media I post and for media posted by others that is missing alt text.
Everything is processed locally through Apple APIs and only on supported devices. The results aren't amazing, Apple Intelligence is extremely limited, but in my opinion it's the only privacy-friendly and ethical way to approach it. And of course, you can disable it.
On Mastodon it supports all the main features: lists, quote posts, granular notifications (you can choose what you want for each category), notification grouping, multi-account support, and it works.
It's still missing a few things (block, etc.) and has some bugs, which I’m spotting as I keep using it.
As soon as it's stable enough, I'll invite a few people to test it. I still haven't fully decided how I'll distribute it: an Apple Developer account has a yearly cost, and I hope to reuse it for other projects too. So this app might be paid, with a trial period, but if possible (I still need to check what’s feasible) I'd like it to be free if you connect to one of the BSD Cafe instances, illumos Cafe, or any snac instance, including your own.
I don't know how long it will take before it's ready... but I can already tell you what it will be called.
It already has a name, and it's... MastoBlaster.
This name was chosen for personal reasons, and also because of its similarity to Master Blaster by Stevie Wonder, which even today feels relevant and fitting for the Fediverse.
Stay tuned!
#MastoBlaster #Fediverse #Mastodon #iOS #FediverseApp #Announcement #Apple #snac #snac2 #BSDCafe #illumosCafe
My friends, I'm so excited and happy to introduce a new project: the illumos Cafe!
The positive and constructive spirit of the BSD Cafe, created and maintained by all the friends who participated from day one in building a strong and friendly community, deserves to spread to other operating systems. Because there are other OSes that deserve attention, certainly more than they're getting right now.
Operating systems based on illumos (like SmartOS, OmniOS, Tribblix, OpenIndiana, etc.) are mature, stable, secure, and perfectly usable for a wide range of tasks. ZFS is native, zones are an excellent method for containerization, and bhyve and kvm coexist beautifully - and so much more, too much to list in a single post.
So from today, the illumos Cafe will stand alongside the BSD Cafe in creating a positive, respectful, and growth-oriented (but also relaxing!) environment, starting right here in the Fediverse with a Mastodon instance and a snac one.
I've written an introductory article about the project, including some technical details. I invite everyone interested to read it: https://it-notes.dragas.net/2025/08/18/introducing-the-illumos-cafe/
Choose your table, take a seat and enjoy your time at the illumos Cafe!
#SysAdmin #IT #BSDCafe #illumosCafe #Community #OpenSource #OSS #illumos #SmartOS #OpenIndiana #ZFS #bhyve #kvm #Fediverse #Mastodon #snac #ITNotes
Con el software de ActivityPub que uso (#snac) es muy fácil montar cosas de estas.
It gives a daily report of those asteroids with a reasonable probability of crashing into Earth, in case you are not already afraid enough of the future. Of course, using #snac, what else.
It takes its data from a very cool NASA site, so (again) in these days of uncertanty, I'm not sure how long will it work.
Everyone, take care, and have a great week.
https://it-notes.dragas.net/2025/02/08/caching-snac-proxied-media-with-nginx/
#Data #Fediverse #Hosting #ITNotes #Networking #Nginx #NoteHUB #Ownyourdata #Server #Snac #Snac2 #Social #Tipsandtricks #Tutorial #Web
Some technical details for those interested:
The entire FediMeteo setup runs on a FreeBSD VM costing around 4 euros per month. It supports almost all major EU countries (plus the UK), with just a few left to complete. Currently, there are 25 separate jails, each running its own instance of snac, totaling 25 instances. The VM load typically stays around 10%, which increases to 30% when updates are published for countries with larger numbers of cities (currently Germany and Italy). The only time the load spikes is when new countries are announced; during that time, all remote instances connect to all cities to download their details.
As for RAM usage, excluding the ZFS cache, it's currently a total of 213 MB. Yes, MB.
Added support for subscribing to LitePub (Pleroma-style) Fediverse Relays like e.g. https://fedi-relay.gyptazy.com to improve federation. See snac(8) (the Administrator Manual) for more information on how to use this feature.
Added support for following hashtags. This is only useful if your instance is subscribed to relays (see above).
Added support for a Mastodon-like /authorize_interaction webpoint entry, that allows following, liking and boosting from another account's Mastodon public web interface. To be able to use it, you must reconfigure your https proxy to redirect /authorize_interaction to snac (see snac(8)).
Some fixes to accept Event objects properly (like those coming from implementations like https://gancio.org/ or https://mobilizon.fr).
Added some caching for local Actor objects.
Hashtags that are not explicitly linked in a post's content are shown below it.
Fixed broken NetBSD build (missing dependency in Makefile.NetBSD).
The user profile can now include longitude and latitude data for your current location.
Mastodon API: implemented limit= on notification fetches (contributed by nowster), implemented faster min_id handling (contributed by nowster), obey the quiet public visibility set for posts, other timeline improvements (contributed by nowster).
Reduced RSA key size for new users from 4096 to 2048. This will be friendlier to smaller machines, and everybody else out there is using 2048.
If the SNAC_BASEDIR environment variable is defined and set to the base directory of your installation, you don't have to include the base directory in the command line.
Fixed a bug in the generation of the top page (contributed by an-im-dugud).
Added support for Markdown headers and underlining (contributed by an-im-dugud).
If you find #snac useful, please consider contributing via LiberaPay: https://liberapay.com/grunfink/
This release has been inspired by the song Nine Hundred Miles by #BarbaraDane.
Announcing FediMeteo – Weather in the Fediverse!
UPDATE: I have created an account for updates and other information on FediMeteo - follow the account @admin to stay updated!
UPDATE: Ireland, Poland, Portugal and Switzerland have just been added
Weather has always influenced our lives: from agriculture to outdoor activities, to extreme events that, thanks to modern technology, can now be predicted with greater reliability. Personally, weather plays a significant role in my daily decisions, which is why I decided to create a service tailored for the Fediverse.
FediMeteo uses Open-Meteo data to publish updates every 6 hours, including current weather conditions, forecasts for the next 12 hours, and predictions for the upcoming days. Each country is served by its own dedicated instance (e.g., it.fedimeteo.com for Italy), managed through snac to ensure simplicity and efficiency in publishing.
You can follow FediMeteo directly in the Fediverse (on Mastodon and compatible platforms), via RSS, or by visiting the dedicated page for your city (e.g., fr.fedimeteo.com/paris).
Currently supported countries include:
Austria, Germany, France, Ireland, Italy, Netherlands, Poland, Portugal, Spain, Switzerland and the United Kingdom, – with many more regions coming soon!
FediMeteo is hosted on a FreeBSD-based VPS, with each country isolated in its own jail to ensure security and scalability.
Visit the main site to explore the national instances and start following your local weather updates today:
https://fedimeteo.com
Happy weather monitoring to all! 🌦️
FediMeteo is dedicated to my grandfather, who every evening would give me the weather forecast based on TV, radio, and his personal experience. He would convince me that the weather would be bad, so he had an excuse to accompany me to school instead of me going alone.
#FediMeteo #Announcements #FreeBSD #FediMeteo #WeatherForecasts #Weather #Meteo #snac #Fediverse #Mastodon
Más tarde me he dado cuenta de que empleando el correo electrónico las discusiones no tienen sentido y que más allá del duelo al amanecer no merece la pena discutir con gente que se ha construido un personaje público y saca sus garbanzos de ahí. Entre eso y los palmeros, a los que el tuitstar SÍ responde por que necesita tenerles en cuenta, es difícil estar a gusto; de hecho el término "pocosfollower" es el indicativo de una época.
Pero sí que he pasado mucho tiempo allí obteniendo enlaces y enterándome de polémicas para pasar el rato y olvidar cómo estoy y quién soy así que tampoco es que lo haya dejado hasta el sábado. Una vez que tengo mi servidor en el fediverso (con #snac) tengo siempre un lugar que considero mío. Por esa parte estoy cubierto.
Ahora estoy intentando ver qué aparece en BlueSky y de momento están todos con una limpia tremenda de nazis y demás chusma que está funcionando al parecer. También cuentas estupendas que estaban permanentemente candadas en twitter ahora actúan en abierto y son una delicia de seguir. Pero el lugar sigue siendo extraño, como un barrio bajo asedio, y quiero ver dónde terminará cuando los dueños empiecen a monetizar.
Right so my personal #snac instance seems to be working ok and I have managed to import all of the accounts I follow here on bsd.cafe . I'll still be using this account but will try and see how I get on with snac. You may notice that it always shows that I have no followers and that I'm not following anyone. This is intentional by the author of #snac as they feel numbers should not matter which is quite true. Feel free to follow me over there if you haven't already and hello to any new followers.
@justine@snac.smithies.me.uk
All of this is hosted in my #HomeLab on a #FreeBSd server jail running over my home FTTP connection. I'm impressed I've gotten this far. Next I'll be doing some html and css customisation's to theme it a little.
After getting to try the #Snac activity pub server developed by @grunfink on bsd.cafe thanks @stefano , I'm kind of tempted to spin up my own instance. Anyone here other than Stefano that runs their own instance ? Please share you pro's and con's plus any workarounds you have come up with.
Also how are you viewing / posting on mobile ? Are you just sticking with web or using the likes of #Tusky ?
#Fediverse #ActivityPub
https://mastodon.bsd.cafe/users/release_candidate/statuses/112140845317198247
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.