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.
More and more people are joining Vivaldi and there are many different reasons why. Which of these are important to you?
I am allowing multiple choices as I know for many of you it is not about one thing. Some of this is thing that we do, but I know for may it is also about things we do not do, such as including AI or Crypto currencies.
#Vivaldi #Browser #EU #Europa #Technology #AI #Politics #Windows #Macos #Linux #Mastodon #Fediverse
| The rich feature set: | 55 |
| The flexibilty and customization: | 54 |
| The built in ad and tracker blocker: | 96 |
| Vivaldi is made in Europe: | 111 |
| Vivaldi does not include Crypto currencies: | 112 |
| Vivaldi does not build a profile on me: | 110 |
| Vivaldi does not have built in AI: | 130 |
| Vivaldi supports the Fediverse: | 92 |
Closes in 2:11:05:02
I would like to share my experience of building #FediHood.
While I still think that building timelines around you is an interesting enhancement for the #Fediverse, I think I was wrong about the way I did it.
Many people are interested, but not enough to create another account just for that feature. They want it with their current account.
I am happy to see #Pixelfed implementing it, and that is the way it should be done.
Week in Fediverse 2026-09-11
Servers
- Hubzilla v11.4.1
- Bookwyrm v0.9.3
- Cookifed v0.1.0
- Ktistec v3.12.1
- Misskey v2026.9.0
- gathio v1.6.7
- NeoDB v0.18.2
- Appy v0.7.0
- PieFed v1.7.15
- Wafrn v2026.09.01
Clients
- Voyager v2.49.0
- Miria v4.0.1
- Aria v1.5.13
Tools and Plugins
- Enable Mastodon Apps v1.6.4 (WordPress plugin)
Articles
- Static ActivityPub Publishing
-----
#WeekInFediverse #Fediverse #ActivityPub
Previous edition: https://mitra.social/objects/01a06eb0-8683-70d3-bb1d-19ef2967e02b
My experience of the #fediverse :
Year 1 (2023):
It feels a little lonely as 99% of my friends stayed on Big Tech platforms.
Year 2 (2024):
I start a blog - #TheFutureIsFederated - to explain the fediverse to "normies"... and I make a lot of new (techie) friends.
Year 3 (2025):
My techie friends encourage me to start self-hosting with #YunoHost... and I do! (GoToSocial, PeerTube, NextCloud...) I LOVE it.
Year 4 (2026):
I'm experimenting with #LoRa off-grid #mesh communication 💁♀️
why can't i boost a lemmy.world post form mastodon? if i copy-paste the URL in the search bar as i usually do here, it says "no results"? where is my #federation ?? #dearlazyweb #fediverse
RE: https://littleone.littlefedi.social/@stefano/01a07c8a-904d-7503-af16-b9bbe8f11f08
This makes me particularly happy. 😄
littleFedi will get its first public showing at Berlin FediDay, running on a Raspberry Pi Zero 2 W.
Meanwhile, I will be at EuroBSDCon.
Two events, two communities I care deeply about, and one very interesting weekend ahead.
#littleFedi #Fediverse #OwnYourData
For the first time, littleFedi will be shown publicly
And I have to say, this makes me very happy. :)
A pre-release build will be running on a Raspberry Pi Zero 2 W at Berlin FediDay, where people will be able to see it, try it, play with it, and probably abuse it a little too.
Unfortunately I won't be there in person, because I'll be at EuroBSDCon that same weekend.
But really, what better place than FediDay for the first public appearance of littleFedi?
A huge thanks to @vortex@tldr.nettime.org - Adam - for taking this on, building the demo, testing it independently, and agreeing to respect the temporary source embargo while we complete the last checks before the public release.
I'm especially curious to see how littleFedi behaves once it's in the hands of people who didn't build it.
This is exactly the kind of test I was hoping for.
More details about the presentation:
https://ctalx.c-base.org/fediday-2026/talk/review/AJNLVMPYRSVX3JDHDHYSEZZNSP9KQSYH
For the first time, littleFedi will be shown publicly
And I have to say, this makes me very happy. :)
A pre-release build will be running on a Raspberry Pi Zero 2 W at Berlin FediDay, where people will be able to see it, try it, play with it, and probably abuse it a little too.
Unfortunately I won't be there in person, because I'll be at EuroBSDCon that same weekend.
But really, what better place than FediDay for the first public appearance of littleFedi?
A huge thanks to @vortex@tldr.nettime.org - Adam - for taking this on, building the demo, testing it independently, and agreeing to respect the temporary source embargo while we complete the last checks before the public release.
I'm especially curious to see how littleFedi behaves once it's in the hands of people who didn't build it.
This is exactly the kind of test I was hoping for.
More details about the presentation:
https://ctalx.c-base.org/fediday-2026/talk/review/AJNLVMPYRSVX3JDHDHYSEZZNSP9KQSYH
This affects the Fediverse.
This affects the Internet.
This is the equivalent of the "rubber hose method" of decryption.
All technical solutions (read: all technology) is subject to politics. To political power. To political interactions.
You cannot rely on purely technical approaches. You have to have social approaches, too. Like. Actual policy and procedure geared around social and political group dynamics.
Like. How will we react when the US Govt requires that @jerry to shut off infosec.exchange servers.
Or how we'll react when a specific Mastodon server is declared part of a terrorist infrastructure. Will federating with it mean any other Mastodon server is now part of the officially designated terrorist network (what then of people that federate with a server that federates with a server that is classified as part of a terrorist network. And so on)
You cannot carry the conceit that tech alone or a purely technical approach will save you.
p » 🌐
@p@hj.9fs.net
If you have a snac follower, and they like your posts, take a moment to appreciate them.
When _YOU_ look at _YOUR_ profile picture on the screen, it [FACES] (looks)...
EDIT: you guys are going to give me a stroke - if there is a face in your profile picture, is it facing right or left.. dont think too much about it. dont worry about the eyes. just generally... my profile picture looks to the right, for example. OK COOL
EDIT7: OK, how about this - where does the NOSE / BEAK / SNOUT / ? point to.
EDIT8: I wish I never made this poll.
EDIT9: If you have an ANIMATED avatar, then judge it on the 1st frame.
EDIT10: If there are both a MIRROR REFLECTION as well as a FACE, decide on the direction the FACE is facing, not the reflection.
EDIT11/12: By STRAIGHT AHEAD I mean looking DIRECTLY at you!
EDIT13: im going to sleep now... please consult the comment section if youre unsure what to click. maybe dont click anything? that is allowed.
EDIT14: if your avatar is looking directly AWAY from the camera, that's also straight away.
EDIT15: If there is NO face in your profile picture, then don't click ANYTHING. this applies to hands, flowers, buildings, bikes, feet. If there is, for example, A FACE drawn on a wall, then judge it by the direction that picture of a face is facing.
(stop boosting this, i beg you - i want this to be over.)
#poll #unix_surrealism #fediverse
| to the right: | 597 |
| to the left: | 470 |
| straight ahead: | 719 |
Closed
Week in Fediverse 2026-09-04
Servers
- Ktistec v3.12.0
- Mastodon v4.7.1
- Vernissage v1.43.0
- snac v2.95
- ActivityPub for WordPress v9.3.0
- Owncast v0.3.0
- gathio v1.6.6
- NodeBB v4.15.2
- tootik v0.25.2
- NeoDB v0.18.0
- Bonfire v1.0.7
Clients
- PleromaFE v2.11.4
- Fedilab v3.43.3
- Tuba v0.11.1
- Pixelix v5.2.0
- Summit v1.85.0
- Shoot Web App v1.3.0
Tools and Plugins
- FediFetcher v8.2.0
- Poduptime v6.3.2
- Enable Mastodon Apps v1.6.3 (WordPress plugin)
For developers
- APx v0.27.0
- Library progress report - September 2026 (GoActivityPub)
Articles
- A reasonably practical guide to validating RFC 9421 HTTP Signatures for ActivityPub in PHP
-----
#WeekInFediverse #Fediverse #ActivityPub
Previous edition: https://mitra.social/objects/01a04a26-eede-72b0-a5e9-f244c3ff2142
p » 🌐
@p@hj.9fs.net
just append the url with ?terse=true
behold and compare the results!
https://hj.9fs.net/p/p/1788520021.138703
https://hj.9fs.net/p/p/1788520021.138703?terse=true
RE: https://berlin.social/@berlinfediday/117200439673886108
Awww Berlin #FediDay is almost here. I'm super super honored and excited to speak there next Saturday.
Currently fine-tuning my presentation, which will be a love letter to the people who contribute to the #Fediverse and give me so much hope for the future ❤️
Today’s littleFedi updates:
Friendly periodic reminder that snac is a great, great piece of software.
I've upgraded #FediMeteo in minutes, recompiling snac *inside each jail*.
The Fediverse, as the Fediverse should be.
p » 🌐
@p@hj.9fs.net
Boost if you agree. Let them know we know they don't really care about us!
#eu #europe #evropa #sad #fediverse #fediart #mastoart #comic
EDIT: I want to make one thing absolutely clear. I am a committed antifascist, because of my personal history, my family history, and my country's history. Nazis and fascists are not welcome here, and they never have been.
Being accused of fascism or Nazism, or of defending either of them, hurts me personally. Part of the point of this post was precisely this: if we disagree, let's not immediately start shouting "fascism". Let's talk, look at what was actually said and done, and try to understand the situation. Sometimes there is more to it than it first appears.
After 30 years of commitment to open source, openness and collaboration, I honestly don't know how else to make my position clearer. I am deeply saddened by how this whole situation has unfolded.
Periodic official communication, just to clarify a few things.
The BSD Cafe is an open, inclusive and friendly community. A community of people who try to be *“pro, not against”* and *“supporters, not haters”*: enthusiasts, friends, people who come here to share, to learn, to discuss. Not to hate each other.
This does not mean that we all have to think in the same way. Quite the opposite: it means that we can have different opinions, discuss them, defend them strongly, and question each other’s ideas.
What it does not mean is that it is acceptable to insult, threaten, attack people, or pretend that there can only be one morally acceptable position on every possible subject.
Calling the BSD Cafe a "Nazi Bar" from the outside simply because we do not automatically censor people who have an opinion different from yours is offensive towards the hundreds of people who are part of this community. Unless you're a Nazi or a fascist. In that case, you're not welcome here.
People are, of course, free to criticise what happens here. But expecting us to attack, ban or silence someone because you believe they deserve it, and then accusing the whole Cafe because we do not, is something different.
And I have seen something even worse lately: actual calls for hate. The equivalent of *“hey, everyone, go and attack this person”*, simply because that person does not share your position.
No. This is not acceptable.
And, dear friends, declaring yourself anti-Nazi while organising a crowd against somebody, intimidating them and treating them as an enemy who deserves to be attacked means using exactly the kind of methods you claim to oppose.
I do not say this lightly. I come from a family, and from a country, with a very real history of fascism and of the antifascism that immediately followed it. These are not just abstract words to me.
Hate is not tolerated, at any level, inside or outside the Cafe. The same is true for threats, intimidation and aggression. Believing that our cause is right does not make those behaviours more acceptable.
You disagree with someone? Say it. Explain why. Argue against their ideas. Support yours with all the conviction you want. But do not aggressively attack. This is not tolerated.
And expecting everyone else to attack that person too, or considering them somehow complicit because they do not, is something different. And it is not what I want for this community.
On any subject.
Even pineapple on pizza (!!!).
The Fediverse is a non-place, but it is made of real people. Wonderful people, very often. Let’s not turn it into version 2.0 of traditional social media, where every discussion becomes a war and anyone who does not think exactly like us automatically becomes the enemy.
In the last few weeks I have seen people stepping away exactly because of this. On different subjects, people accused of the worst things not because of something they had done, but because they had not said what someone expected them to say. Some of them, for their own wellbeing, simply decided to take a step back.
We all lost something because of that. Nobody gained anything.
So let’s keep supporting what we believe in. Let’s do it with conviction, and with firmness when needed. But let’s discuss ideas without turning people into targets.
From experience, I have learnt that real change also requires discussion, organisation, patience and concrete actions. We can disagree deeply without stopping considering each other as people.
This is the kind of place I want the BSD Cafe to continue to be.
https://journal.bsd.cafe/2026/03/31/im-just-the-barista/
#BSDCafe #Fediverse #SupportersNotHaters
I’m Just the Barista
The spirit of the BSD Cafe is to try to create a serene, open, friendly, positive, and welcoming environment for all who want to be a part of it. I am just the Barista. I can't solve the world's problems, but I can try to keep the counter clean, keep the machines running, serve a good BSD coffee, and ensure that, at least here, friends can find a moment of peace and constructive sharing. We need more bars and fewer shopping malls. [SENSITIVE CONTENT]
This is the text I wrote for my part of the talk “Liberating the Social Web Using *BSD“, presented together with the great Jeroen (@h3artbl33d) at EuroBSDCon 2025 in Zagreb. It’s not a transcript – it’s the base I worked from, the thoughts I organized before stepping on stage. What I actually said may have been slightly different in places, as it always is when you speak from the heart rather than read from a page. But these are the words, and the spirit is exactly the same.
Today, I’m not just here to talk about technology, but about how the principles of BSD systems can help us build healthier and more resilient online communities. And I’ll do this by telling you the story of the bar I founded, the BSD Cafe.
The idea for the BSD Cafe was born long before its launch but, as I often do, I thought carefully about whether to proceed. On 27 December 2022, I decided to register the domain. The name came from careful reflection with my wife. The idea was to create a virtual space that resembled not so much the cafes scattered around the world, but the Italian “Cafe” (which are called “Bar”).
For many years (and in many contexts, still today), Italian bars have been at the center of people’s recreational social lives. The Barista, the manager of the establishment, is not just a keeper but a point of reference: they don’t just serve coffee, but they listen and, if asked, offer advice with the wisdom of someone who sees many people and many things, even just out of the corner of their eye, and hears many stories. It used to be said that the best advisors were priests and bartenders, but that the latter certainly gave more entertaining advice.
And the bar is precisely the place where people go to relax. There are often televisions, tables for playing cards, and recreational rooms. The bartender ensures that everything runs smoothly, but also that everyone feels comfortable: that the person passing through gets directions to their destination, that the person who just walked in gets their coffee at their preferred temperature, and that the person who entered a little earlier, who needs some rest today, has a table in a more private area.
The spirit of the BSD Cafe is the same: to try to create a serene, open, friendly, positive, and welcoming environment for all who want to be a part of it. Those who just want to read can do so. Those who post a lot are welcome. Everyone should have the experience that makes them most comfortable and at ease. No one should ever feel forced to do something they don’t want to do; no one should ever feel uncomfortable. Therefore, everyone can choose a noisy and active table, or a more reserved and quiet one.
We can therefore assume that the BSD Cafe has an infinite number of available tables. We can thus call it a Turing cafe. 🙂
In Italian bars, people used to go (and in some areas, still do) to find their “bar friends”. These are people you meet at the bar without an appointment. You go to the bar freely, when you have the time and inclination, and you find the people who regularly frequent that place. And the choice of the bar often aligns with the theme of the bar itself. For example, in Italy, there are many “Bar Sports” where people meet to catch up, watch games together, and read and comment on sports news. The idea of the BSD Cafe is the same – a bar where enthusiasts of BSD systems, Open Source, and technology can be found. And for me, although I might occasionally talk about users (out of technical habit), at the BSD Cafe, there are only “bar friends”.
The BSD Cafe is a place where we are “for”, not “against”. Supporters, not haters. Bar friends, not opponents. This doesn’t mean that opinions on other software can’t be expressed, even extremely negative ones (I do it myself from time to time), but the general spirit is that of open source: to build, to discuss, to understand. Wars against other solutions, especially if they are open source, are not part of the atmosphere of the BSD Cafe. We have our preferences – we support our ideas and solutions, but we are not here to “destroy” others. Among our users, there are people who develop Linux distributions – and for me, that is extremely positive!
When people are at ease and in a serene environment, they are often encouraged to be serene themselves. Some are negative and aggressive because they absorb it from their environment. Some users of the BSD Cafe have told me exactly this: the civil, friendly, relaxed, positive, and constructive level of the BSD Cafe is good for their mental health. Conversely, there are unfortunately people who find pleasure in causing trouble, in muddying the atmosphere. For these people, unfortunately, there is no solution, but the Cafe is not the place for them.
Political discussions can be part of our lives and daily routines, but the BSD Cafe is not a political group. In recent years, politics has become a topic not of discussion but of conflict. It has always been so to some extent, but commercial social media platforms have understood that hatred and conflict generate engagement, and engagement means selling advertising – a lot of advertising. Therefore, at the BSD Cafe, you might occasionally hear talk of politics or the political repercussions of technical decisions and choices. And that is perfectly okay. But it is not a place from which political conflicts should arise. We are for – supporters, not haters. We are here to build, not to destroy.
The BSD Cafe is therefore a place centered on the BSDs, and all services are, therefore, based on BSD operating systems.
All technologies used must be able to run “from my garage”. I am a professional – so this is not a hobby project – but it must not depend on any proprietary solution or “Cloud” solution. Today, there is a tendency to standardize (too much?) everything related to technical choices. If it’s pro, it’s Kubernetes/cloud/serverless/etc. – if it’s not, it’s “old” or “not pro”. I am, and have always been, a proponent of OwnYourData. And this is a mantra at the BSD Cafe. All services are based on Open Source solutions, outside the dynamics and centralized management of the usual companies. We must be free and maintain our technological autonomy; we cannot create a system where our communications and our data depend exclusively on third-party companies. I have enough experience to understand that, sooner or later, even the most solid companies can fail or change their business model. The BSD Cafe is therefore always in favor of self-hosting. Sometimes this means losing users, but not bar friends. It happens, in fact, that at a certain point, friends decide to try the BSDs and start self-hosting their own services. For me, that is a success: one less number in the statistics, but one more success on a technical and ideological level. And for all intents and purposes, they remain bar friends, even if their “handle” is different from “bsd.cafe” – it is the spirit, not an extension, that unites us.
From time to time, I have migrated the main VM of the BSD Cafe. Sometimes I have given notice, other times not (the downtime is minimal). In some cases, the system has run from my home desk, from the Mini PC I used as a home server and now use daily as a workstation. At the core of the technical choices, in fact, is the decision not to depend (strictly) on any specific technology or hardware. For this reason, the structure of the BSD Cafe is replicable and malleable, as well as described in its Wiki: it is a community of technology enthusiasts, and I want them to judge the choices transparently and autonomously, without hiding anything.
The BSD Cafe was not created to be just a Fediverse instance but, from the beginning, to provide a series of services powered by the BSDs for enthusiasts and friends of the BSDs. To date, the main services are:
- A Mastodon instance – the beating heart of the BSD Cafe in the Fediverse, which currently has about 500 total users (now 600 – of which about half have been active in the last 30 days). This is where we chat, get informed, joke, critique, build, discuss, and get to know each other.
- A snac instance – also for access to the Fediverse. Snac is an example of lightweight software, with no dependencies, that is stable and easy to self-host. It does not use a database but the file system and is the basis of another project of mine, FediMeteo. The snac/ZFS combination is fantastic. The developer is a caring, helpful, and fantastic person. It is my first choice for personal projects and more – it currently has more or less 30 users.
- A Lemmy instance – blendit – which, however, is giving me problems and headaches. I’ve been thinking about it for a while; it might be the first of the BSD Cafe services that I will be forced to retire. More about this later.
- A Matrix server – based on Synapse, it has become the hub for many interesting topics both in the thematic channels (BSD-themed) and in the Lounge, the general channel, where we talk about a bit of everything. The server is federated, so it is also an access point for channels and groups on other servers. We chat, we discuss, we ask – a bit like with the Fediverse, but on Matrix.
- miniflux and freshrss – RSS is not dead – it is alive and well and still a fundamental tool for updates and consultation. Two jails, two services to give our friends a way to read the news. This is our reading corner, the newspapers, the newsletters. Here, you remain autonomous and in silence, you choose what you want to read, and you savor the content. Without advertising, without interruptions.
- wallabag – called “press” – to save your bookmarks, sites, articles. Save the web. Freely. Our post-it notes, but private.
- myip – by connecting to myip, you will get your IP back – both v4 and v6 – via telnet, http, https, ssh, etc. – ideally, it is an echo chamber, to “hear” the reflection of your own voice – that is, your own IP.
- wiki.bsd.cafe – the project’s homepage and a series of articles and content about the BSDs. It is not very rich in content at the moment, but some friends contribute regularly and keep the information in it updated. It contains articles on how the BSD Cafe is structured (for each service, an explanation of the division into jails, etc.). Our recipe book – for the coffee machine, but also for the BSDs!
- brew.bsd.cafe – powered by Forgejo, it has become the home for many projects by friends of the BSD Cafe. I use it daily for my own needs, and it is a way to avoid using centralized tools controlled by the “usual suspects”. And, unlike the main and most famous similar service in the world, it also supports IPv6! It is our creative workshop, the development den. The garage where we have our tools and build, collaborating.
- journal.bsd.cafe – the latest, in chronological order, added to the BSD Cafe. Our journal, what we want to tell the world and leave a trace of. It is a WordPress blog, federated in the Fediverse thanks to the ActivityPub plugin, where authors can create and publish articles, even those not strictly related to the BSDs. So far, various articles have been published, and some of them have had some success on sites like Hacker News or Lobste.rs – because quality is still appreciated, especially in the world of standardized and imprecise content from LLMs (or “AI”, as is fashionable today).
- There are other active services but not publicly usable, such as “tube” – our TV – Peertube. They are currently experimental.
Let’s get into the technical details:
The BSD Cafe is not “cloud ready”. The BSD Cafe was not created to be serverless. We love our servers, and we don’t need the “cloud” to run our services.
The BSD Cafe started with a FreeBSD VM on Hetzner in Finland for €3.29 per month. It is still active and is the primary for the entire infrastructure and is named “bsdcafevm”. It hosts the reverse proxy, in a jail, which routes all incoming connections, and is the “router” for the larger VM. This VM also hosts a “ns2” jail, which is the secondary DNS, and the “backup” instance of Mastodon, which helps with queue management and becomes primary when I shut down the other one during updates. For IPv6, Hetzner assigns a routed /64 block. I have divided it into /72 subnets so that I can route to other VPSs, services, etc., and provide an IPv6 address to any jail.
The main VPS, which hosts the services, called “bc01”, connects to this VM via Wireguard. bc01 has some particular characteristics, including:
- It was originally a VM on Proxmox, as I was using hardware I already owned. It is now on bhyve, on a FreeBSD host under my control (in Germany).
- It does not have a public IP assigned, but connects to the Internet only via NAT on the host. This is a clear choice: this VM should only connect to bsdcafevm. BSDCafeVM will forward connections from the reverse proxy and will handle “NATing” outgoing IPv4 connections from bc01. The Wireguard rules on BSDCafeVM will also ensure that IPv6 connections reach the jails of this VM. The purpose is simple: this VM must be able to be moved anywhere, and the services must be able to resume functioning immediately. And this happens because all it needs is a Wireguard connection to BSDCafeVM, so there are no services exposed directly. This is the reason why this VM has been moved many times without any changes to IPs, addresses, etc. More information on this VM later.
A small VM (for one euro per month) based on FreeBSD that, within a jail, has the ns1 nameserver, which is the primary authoritative one. This VM also serves other purposes from time to time, such as monitoring the rest, etc.
A jail within one of my FreeBSD hosts in Poland, on OVH, contains the media files for the Mastodon instance. This is the most voluminous part of the entire hosting setup because Mastodon downloads and reprocesses all the multimedia content it encounters. This is for two main purposes: to clean it, in order to possibly remove malicious content, and to ensure that users of one’s own instance only have contact with their own media repository, not with that of the original instance – both for performance and privacy reasons. This server has spinning disks. Initially, I used Minio, but over time, performance plummeted. A few months ago, I migrated to SeaweedFS, and I am very satisfied with it. The outgoing bandwidth of this machine is not very wide, and I have other services on it. For this reason, I applied a solution that I described in an article on my blog.
I have used some VMs or physical hosts (spread across Europe and the USA) to act as a CDN. The BSD Cafe’s DNS will return the IP (both v4 and v6) closest to the caller, among those available, and this host will connect directly to the media server, then caching the content. The problem, in fact, does not arise when a user scrolls through their timeline, but as soon as they publish multimedia content: all known instances will connect to download and reprocess that file, generating a spike. This has little impact if it is a normal post, but it is extremely voluminous if it is content of a considerable size, like an image or a video. In this way, the various CDN nodes will download the content only once and serve it to all instances in their area of competence. These CDN nodes also do other things, can be activated or deactivated based on my needs, and are based on FreeBSD, NetBSD, and OpenBSD (one of them is on OpenBSD Amsterdam).
Another FreeBSD VPS (which I use for other things) contains “status.bsd.cafe“, which is the jail with Uptime Kuma that shows the status of the services or any of my communications about them. I do not receive notifications from this host, but from another monitoring system, so it is only to show the status of the situation.
In practice, the BSD Cafe mainly needs the “endpoint” VPS, the VPS with the services, and the jail with the media, which could be condensed into a single system if desired. Everything else is optional and I keep it active as I have resources available on external hardware.
Many of the technical choices have been documented in articles on my blog or in the BSD Cafe Wiki.
But all of this requires backups. And the BSD Cafe has a clear and defined backup procedure.
The main VPSs – namely bsdcafevm and bc01 – are based on FreeBSD and, therefore, ZFS. Both have the same type of backup, defined as follows:
- A local snapshot every 5 minutes, kept for two hours. In this way, in case of problems, it is possible to “clean up the coffee drop” before the tablecloth is indelibly stained—as well as one per hour, kept for 24 hours.
- An external backup, performed at regular intervals, to an external backup host. The frequency varies from 15 minutes to an hour, depending on the available space and the load, which I modify according to my needs. All datasets of the VMs are copied, including system ones, for a possible quick recovery in case of a disaster.
- An external backup to a backup server of mine, one meter away from me. This happens every 24 hours, and I consider it the “extreme disaster recovery” because, in my opinion, the safest data is the data that is physically reachable. The disks of this server (which also contains other backups) are all encrypted with GELI, so in case of theft, they are unusable.
Last but not least, the physical FreeBSD host on which bc01 currently rests is also backed up every 15 minutes to another external backup server, so the entire disk image. An additional layer of redundancy, to help me sleep better at night.
From a technical standpoint, therefore, I have tried to create a simple but secure infrastructure, with the most granular separation possible (for example: the main Mastodon instance has a jail for Mastodon, one for the Redis for the queues, etc., one for the Redis for the timeline caches (only in RAM, does not write to disk), and one for the database (PostgreSQL).
Then there are the common service jails (unbound for DNS resolutions, smtp for sending and receiving emails, etc.).
Being the Barista of the BSD Cafe is a privilege and an honor. The success of the project has exceeded my expectations, and this has filled me with joy. The BSD community is fantastic, mature, intelligent, and positive. The friends who approach the BSDs absorb all of this and transmit it to others, creating a virtuous circle. But it’s not always roses. There are problems, from time to time, that need to be solved. And, to quote my previous talk: “The main challenge is often ideological, not technical“.
Apart from the problems with blendit – Lemmy – which accumulates all the media it sees in a frenzied way and never deletes it, as well as having created serious update problems – all the software is on average stable and reliable.
The most complex part of my role as a barista, in fact, is not technical, but human: moderation. The techniques of scams and disturbances are constantly improving, and it is increasingly difficult to distinguish a new friend of the bar from a troublemaker. But the biggest challenge is maintaining balance.
Our philosophy is clear: to be for, not against. Supporters, not haters. This principle is a conscious choice, in stark contrast to the dominant model of commercial social media. These platforms are often designed around an engagement economy, where algorithms optimized to generate conflict and outrage maximize the time spent on the site and, consequently, advertising profits. The BSD Cafe rejects this model. We are not here to capitalize on anger, but to build a refuge from the toxicity of the internet.
This approach manifests itself in the way we handle controversial topics. Recently, a technical theme with strong political implications has begun to appear in discussions. My line is not to censor the topic itself. I firmly believe in open discussion. I only intervene when the discussion ceases to be a critical analysis and becomes a personal attack. For some, this is not enough: they would like a total ban on certain topics and the immediate exclusion of those who introduce them. My experience, however, has shown me that a more patient approach is often more constructive. I have seen people support controversial software solutions simply because they did not know their background. Thanks to civil and informative discussions, they have understood the context, thanked the community, and made more informed choices. Banning them instantly would have been unfair and would have denied everyone an opportunity for growth.
However, this philosophy of constructive positivity has attracted a specific criticism: that of promoting “Toxic Positivity”. The accusation is that, in our desire to maintain a serene environment, we end up excluding those who are suffering, invalidating their negative experiences because they “clash” with the atmosphere of the bar.
This is a criticism that I take very seriously, because it touches the heart of the project. And my answer is that it is a fundamental misunderstanding of our purpose. The goal is not to deny that pain, injustice, and suffering exist in the world. On the contrary: the BSD Cafe exists precisely because the world is often a difficult place.
Our purpose is not to pretend that those who suffer should stop suffering, but to offer them a place where, for a while, they may not be defined solely by their suffering. A place where they can be, first and foremost, a technology enthusiast, a FreeBSD expert, a curious OpenBSD user. A friend of the bar. We are always ready to support, console, and help those who need it, but we want to protect that mental space where shared passions unite us and give us relief.
Fortunately, this vision is confirmed by the very people we are trying to help. The number of private messages of appreciation I receive from people going through terrible times far exceeds the criticism. They write to me that “the civil, friendly, and constructive level of the BSD Cafe is good for their mental health”, because it allows them to disconnect from daily dramas that would otherwise be unbearable.
I am just the Barista. I can’t solve the world’s problems, but I can try to keep the counter clean, keep the machines running, serve a good (BSD) coffee, distribute (many) stickers, and ensure that, at least here, friends can find a moment of peace and constructive sharing. But a bar is nothing without its regulars. And the success of the BSD Cafe is not mine, but that of the BSD Community and the friends who are part of it. The richness of this place is not only the quality of the Coffee (which, being BSD, is very high), but mainly the human richness of the friends who are part of it. And to them, to all of you, I say thank you. From the bottom of my heart.
We need more bars and fewer shopping malls, and that is why I recently also founded the illumos Cafe. We want people who sit down, who socialize, or who simply enjoy the atmosphere of an environment that is familiar, friendly, and positive to them. Like this conference and all the BSD Conferences, because the environment is the same. Enough of shiny shop windows; a good hot drink, in the company of friends, can help you live better. “From the people, for the people“.
p » 🌐
@p@hj.9fs.net
ft. big update - over 100 new achievements!
RE: https://beige.party/@TheBreadmonkey/117191442560318887
When people say "we need more mainstream people, celebs, brands on Mastodon for anyone to take it seriously," this is what comes to mind.
There are days when the main goal is just to make it to the evening without falling apart... today is one of those days 😄
Have a great day, #BSDCafe!
Have a great day, #illumosCafe!
Have a great day, #Fediverse!
Good night, Fediverse.
May the glow of this moon and the peace of this sea soothe and illuminate your life, even when the light is dim and the path ahead of you seems dark.
THEODORE ROOSEVELT SHOT BY CRANK IN MILWAUKEE STREET
#content_review #unix_surrealism #fediverse #loops #mastodon #lemmy #art #mastoart #javascript #cats #snac
Good morning, #BSDCafe
Good morning, #illumosCafe
Good morning, #Fediverse
Have a great #SeaWednesday !
It’s not Tuesday yet, but it will be soon.
And I want to thank @grunfink for creating and maintaining snac. Tomorrow I’ll talk about FediMeteo at DevConf, and it would never have come to be if it weren’t for snac and for the help the author gave me in fixing some things to optimize its use.
True Open Source, made with passion, by people who do things for the love of the things themselves.
lia, a bun type creature
[she/they · sie/ihr oder es/deren/denen] » 🌐
@lianna@micro.webgarden.click
After Bluesky, Threads, and so on, the whole #WSocial thing is another reminder that it was never about the #Fediverse being "too complicated" or "just for nerds".
A bafflingly large amount of people genuinely only act on a gut feeling telling them that only commercial products with fancy marketing owned by a for-profit corporation can be trustworthy, 'official' and 'legal', for the lack of a better word.
If something is a commercial offering by a competent-looking, rich family man in a suit, it's clearly an official, legal, trustworthy product. You can be proud of using such a fancy-looking service.
When they see a community-run open-source project or a grassroots initiative, their first instinct is that it must be shady, illegal, complicated, broken or predatory in some way. It's probably some aftermarket grey area bootleg made by weird tech nerds, political groups with an ulterior motive, conspiracy theorists or some naive teenage hackers. They'd also be embarrassed for using it in front of their peers and neighbours; who uses some free back-alley software, are you poor or something?
The same people are the reason why Google is using the word 'sideloading', why scammers love wearing fancy suits, why people suddenly act childishly helpless in front of LibreOffice, or why DIY HRT is so demonised.
They trust any kind of 'official approval' over their own senses. If someone does something that isn't 'approved', they're a bad person or clearly endangering themselves and others. No idea why exactly, but psh, it must be wrong somehow, or everyone would do it, right?
If people on the Fediverse understood that the whole "it's all so complicated and clunky" thing is just a thinly veiled excuse for a general disdain for non-commercial software, we could finally stop making all our software imitate their corporate equivalents in a futile attempt to appease people who never gave us a chance in the first place.
You'll never convince them to treat it in good faith no matter how much effort or money you put into UX or 'ease of use'. All you're doing is making the software worse, e. g. through things like dot-social, verified accounts or begging brands, corporations and politicians to join and give your product some kind of 'official' validation.
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
Your reader, your couch, your rules.
Starting today, both my-notes.dragas.net and it-notes.dragas.net are changing the way they distribute content - on RSS and on the Fediverse alike.
No more excerpts. No more "read more" links. Full posts, delivered directly to you, wherever you choose to read them.
Here's why:
I don't run ads. I don't have paywalls. I don't sell attention, or measure success in page views. I never have, and I have no intention of starting. My blogs exist because I enjoy writing, and because
some of what I write might be useful - or simply enjoyable - to someone else.
That's the whole business model. There isn't one.
When that's the case, there's no reason to keep content behind a click.
Sending you a teaser and asking you to visit my site would only make sense if I needed you *on my site* - for an impression, for a conversion, for something. I don't. So why would I make you leave your reader, your client, your comfortable corner of the internet, just to come to mine?
What I want instead is simple: that you can read what I write the way you'd read a book on a cold winter evening, wrapped in a warm blanket. Privately.
Quietly. On your own terms, in your own space, without anything tracking your eyes or nudging you toward something else.
Your RSS reader is yours. Your Fediverse instance is yours. The content should be yours too.
If you're on the Fediverse, you can follow both accounts directly:
- my-notes → @mynotes
- it-notes → @itnotes
These are low-traffic accounts. If you don't want them to get lost in your timeline, feel free to hit the notification bell. I promise it won't make much noise.
So from now on, it will be.
Week in Fediverse 2026-02-20
Servers
- snac v2.90
- Castopod v1.15.0
- Ktistec v3.3.0
- tootik v0.21.1
- Badgefed v0.1.1
- Gush! v0.0.30
- Wanderer v0.18.5
- PieFed v1.6.6
- Our technical direction (Mastodon)
Clients
- Sengi v1.8.0
- tooi v0.21.2
- Summit v1.77.0
- Aria v1.4.3
- Pixelix v4.3.2
Tools and Plugins
- feed2fedi v3.5.0
- PeerTube Browser: A video discovery project for the federated PeerTube network
Protocol
- FEP-34c1: Collection Filtering using TREE Hypermedia Vocabulary
Articles
- Where Does Community Live?
- Why MAEPs? What should they look like?
- how to not regret c2s
- Reimagining Fediverse Advocacy
- FR#154 – Search and Community
-----
#WeekInFediverse #Fediverse #ActivityPub
Previous edition: https://mitra.social/objects/019c5906-05c0-87bf-8302-8226a8513c00
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
#OverUnder 046 with @stefano
He's a #Unix enthusiast, he hangs out at the #BSD cafe, and write about various systems.
If Unix tips interest you, you should definitely check him out.
Today, he shares his thoughts on #DragonFlyBSD, #AWS, #TuxedoComputers, #zsh, and #Nespresso.
#terminal #shell #opensource #coffee #blog #cloud #Tuxedo #fediverse #mastodon
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
I just had such a lovely conversation with #bsd "barista" @stefano about building community here. What a nice way to start the week -- by being reminded that there are thoughtful humans who care about genuine connection.
Thank you to @_elena and others who recommended him.
Now I want more fedi friends! 😃 Anyone? Anyone?
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.
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
When I talk about the importance of going all in on the Fediverse, I speak based on experience.
At Opera we built a massive user community. When I quit, we had something like 35 million registered users and 35 million monthly visitors.
The new Opera management did not see the value of that. They believed it was cheaper and better to just use Facebook and that investing in your own community was a waste of money. So they closed down MyOpera and built a following on Facebook and Twitter instead. Then they got caught by the bait and switch when Facebook changed and you would no longer reach your audience, without paying. Later on Twitter changed as well.
This is important to explain to companies and institutions as they go shopping for social media sites to invest in. The best investment is clearly in your own site, being part of the Fediverse. It is not even all that expensive to do. It may take longer to build, but at least it is your own.
Not saying you cannot build a following on those other sites, but your long term strategy should be the Fediverse with your own server.
We try to lead the way here and thus we build Vivaldi Social. Not just for our selves, but to make a point and support the Fediverse.
Mastodon Migration Blog » 🌐
@mastodonmigration.wordpress.com@mastodonmigration.wordpress.com
What are Follow Packs?
They are just packaged topical lists of up to 35 accounts you can follow from your Mastodon or other Fediverse account. You can follow the entire pack by importing a file. And the entire pack loads into a list, so it becomes a feed for that subject. You can also just browse for accounts you might want to follow individually.
So, they’re like Bluesky Starter Packs?
Yes, but not quite as convenient. It’s not hard, but because Mastodon does not have a one-click way to do this, you need to download a follow pack file and then use Mastodon’s import facility. Instructions are provided in the directory and also below.
What Follow Packs are there?
Packs are being added all the time. Right now there are packs for Astronomy and Space, Climate, US Politics and Miscellany. For a current directory check out the Mastodon Migration FediBlog at: https://mastodonmigration.wordpress.com/2024/11/20/mastodon-follow-pack-directory-nov-20-2024/
How do I do do it?
Check out the latest directory at https://mastodonmigration.wordpress.com/2024/11/20/mastodon-follow-pack-directory-nov-20-2024/ . Basically determine which pack you want to follow and download the .csv then import the pack. Instructions are provided. Follows are loaded into a list in your account.
OK, but I don’t want to mess up my lists. What happens if I already follow an account in the pack?
That’s fine. The followed account will just be added to the new list, and if you already had that account in a list, it will now just be in both lists.
Can I then add more accounts to the list?
Sure! That’s the idea. Many of these accounts boost other great accounts in their topic area. You will quickly find additional accounts you will want to follow. When you do follow a new account add it immediately to the list by clicking the “…” button at the top of the profile and selecting “Add or Remove from lists”
What if I don’t like your pack list title?
Simply change it. Click on the list, then the gear icon and you can edit the list name and contents. Also, you can determine if you want to “Hide these posts from home” so they don’t clutter up your home feed.
What if I’ve been added to a list and I don’t want to be in it?
Every follow pack has a listed administrator. Message them to ask to be removed.
How do I know if my account is in a Follow Pack?
You can search through the directory. Also, whenever a new directory is posted all members of every pack are notified by being copied on the post.
What if I don’t want to follow accounts from Threads or Bluesky?
Any pack that contains Threads or Bluesky bridged accounts will have a special notice. Just don’t import one of them.
#FollowPack #StarterPack #MastodonMigration #MastoTips #Help #Directory #Guides #Mastodon #Fediverse #FediBlog
Follow Pack Notices
OPT-OUT NOTICE: If your account is listed in any Follow Pack and you do not want it to be, please message the pack administrator and refer to the pack from which you would like your account removed.
BRIDGE ACCOUNT NOTICE: Packs that include accounts that bridge outside the Fediverse will be identified with a special notice.
REPLIES ON MASTODON NOTICE: Replies include all named accounts. Please edit any replies to remove addresses you do not intend to send the reply.
Follow Pack Instructions
Download the pack .csv file and import into Mastodon to follow all accounts:
– Click on a FollowPack .csv file link to download
– Click on Preferences (gear) icon on bottom right
– On mobile or narrow desktop click top right “hamburger” button
– Click Import and Export >>> Import
– Import type dropdown: Select “Lists” (NOT “Following list”)
– Verify that ‘Merge’ is selected (IMPORTANT)
– Click Browse… button >>> Select “[file name] – list.csv”
– Upload >>> Confirm
______________________________
This post comes from the WordPress Mastodon Migration Blog: https://mastodonmigration.wordpress.com/
You can receive all new posts to this WordPress Blog on Mastodon by following Mastodon account:
https://mastodonmigration.wordpress.com/@mastodonmigration.wordpress.com
(Copy and paste above address into search to find and follow)
Important: Replies on Mastodon to this WordPress post by default include all named accounts. Please edit your reply to remove all addresses you do not intend to send the reply. Thank you.
#accountlist #activitypub #astronomy #Astrophysics #bluesky #Booster #Climate #ClimateScience #Dire #Directory #FediBlog #fediverse #followpack #followpackdirectory #GlobalWarming #guide #Guides #Help #mastodon #mastodonmigration #MastoTips #Media #Miscellany #mmfp #Politics #Random #socialMedia #Space #StarterPack #Threads #twitter #USPol #USPolitics #USPoliticsBoos #USPoliticsMedi #USPoliticsMedia #USPoliticsThreads
This afternoon, an acquaintance joined a Mastodon instance and asked me which "celebrities" are present in the Fediverse, as if it were important to determine the value of a social network based on that.
I told him that the most important user in the Fediverse is him. Just as it’s you, reading this. Someone who has decided to interact with others freely. Who has chosen to trust their administrator (or create their own instance) more than they trust those who run traditional, monolithic, centralized social networks.
So, I want to thank all the friends of BSD Cafe, whether local or not, for being here and making this place what it is. And I thank all my friends in the Fediverse, who make my timeline lively, interesting, intelligent, fun, and thought-provoking - every day, at any time.
#BSDCafe #Mastodon #Fediverse #SocialNetworks #SocialMedia #Community #Trust #OpenSource #DigitalFreedom #JoinTheFediverse
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
I want to launch a hashtag where, every Tuesday, I'll post a message and it would be great if it became a habit for many.
In a world full of conflicts, selfishness, and egocentrism, it would be nice to focus on the good that others do, what makes our lives better thanks to the contribution of others.
My first #ThankYouTuesday to the friends of #BSDCafe - both within the community servers and beyond - who have undoubtedly contributed to making my life better, more stimulating, and richer. So, I extend this gratitude to all those who, here in the fediverse or elsewhere, are present and positive, giving me inspiration and motivation.
Truly, thank you!
#ThankYouTuesday #gratitude #positivity #community #fediverse #mastodon
Lol
Guess who's the "most popular" person in the Fediverse.
Week in Fediverse 2024-03-22
Servers
- Hatsu v0.1.1
- lotide v0.15.0
- Friendica v2024.03
- snac v2.50
- Hubzilla v9.0
Clients
- Fedilab v3.28.2
- Tuba v0.7.0
- Husky v1.5.4
- Mastodon for iOS v2024.2
- Photon v1.28.4
- Voyager v2.0.0
Tools and Plugins
- Granary v6.2
- Fedi badge: A badge generator for ActivityPub-enabled social media platforms
Articles
- Bonfire Launches Open Science Network for Academics and Researchers
- Pixelfed introduces Loops, a Short-Form Video App
- Oh, Zot! Nomadic Identity is Coming to ActivityPub
- The Efforts to Extend ActivityPub
- Threads has entered the fediverse
- Last Week in Fediverse – ep 60
-----
#WeekInFediverse #Fediverse #ActivityPub
Previous edition: https://mitra.social/objects/018e4384-6968-4bee-0dc6-9f542a42d847
15 million users in the Fediverse, now.
No ad-blocker needed.
Zero ads.
My data stays on my server.
Interactions are genuine, driven by people's desire, not an algorithm pushing for conflict to boost engagement (and ad sales).
Nobody's here just because it's trendy. If you're here, you want to be here.
The best social media experience I've had in years.
Thank you to all of you, among these 15 million accounts, who have helped make this a wonderful place to be.
#Fediverse #Privacy #NoAds #GenuineInteractions #Decentralized #ThankYou #Mastodon