@stefano@littlefedi.social @stefano No slowness! That's awesome. I have a few numbers of comparison for you. I do something a bit similar, but not for as cheaply. I think it's awesome you got it working in a *BSD. This will bring more resiliency to the ecosystem. Those efforts to economize the cost are appreciated! Please keep up the great work!

For the sake of comparison, I have a single-user #GotoSocial server behind a "Super Owl Reverse Proxy":
owleyes.blue/posts/gotosocial-…

This lets me run the latest GotoSocial within my LAN, on a Raspberry Pi 5, with 2GB of RAM. It idles at 915MB RAM, 210MB of swap is lackadaisically used. swap is very quiet with "vmstat 1". This is running a Raspberry Pi desktop, with the secure VNC server running. So I could save some RAM there if I wanted - using SSH only, no VNC. I turn VNC on sheerly because I can - easy to toggle in raspi-config. The RAM goes down to 670MB with no desktop, no VNC. So one of those 1GB of RAM Pis would do (and I suggest a swap space, would be very low activity), if done "headless".

I use stock Raspberry Pi OS, based on #Debian 13. I have a 500GB NVME, and is about 60% full. It reports 850MB/sec with an "hdparm -t". It is connected with GbE to a Gigabit switch. I get a rock-steady 930MB/sec with iperf3. This pi never breaks a sweat with my 1 GotoSocial user - I could run other services as well, as long as the RAM held. The load average sits at zero pretty much, all day long. The temp stays 48 deg C, in a nice, metal Argon Neo case, with the NVMe tray accessory.

This Pi 5 is overkill for a single-instance GotoSocial server, but the all-in one, great metal case makes the cost worth it to me - feels like a finished product, and doesn't scare normies when I show it to them.

I've been running this instance for 6 months, works great. If anyone wants my services to have their own similar relatively inexpensive gotosocial server (cloud or LAN), I'm for hire! #fedihire #getfedihired #linux #OpenSource #Fediverse #Mastodon

I am a little bit sad that the #Fediverse largely cristallised in a way that made Mastodon-like microblogging the default, and everything else an 'extension' at best.

Of course there are other systems and software choices out there, but from what I can see, the only non-microblogging one with real staying power is Pixelfed.

I am a big fan of the 'personal macroblogging' style of social media, i. e. what Facebook and Myspace were back in the day. Specifically, a big focus on structured social data and the way software uses that to provide functionality automatically.

I want expansive profiles with tons of fields like hobbies, birthday and other anniversaries, fun fact and trivia, favourite bands, foods, songs, ideology, location, nicknames, game collections...

And I want the software to be able to use that data for cool functionality! I want birthday reminders for my friends, I wanna get profile recommendations for people with similar hobbies and tastes! I want to be able to create events and notify everyone who is into the same things! I want to be able to have hobby groups to post into and fanpages and all.

Over here on the microblogging side of things, profiles are pretty barebones and there's hardly any data integration. The only fields that software really considers is name, pronouns, hashtags and in some cases specific integrations like ListenBrainz on GoToSocial. That's it. Everything beyond that is just posts.

I get why collecting and sharing vast amounts of personal data kiiinda went out of fashion, but I think consent-based systems rather than data brokers would make me comfortable enough to share these things.

I know Friendica and Diaspora exist, but their development is super slow, they don't federate well, and more importantly, their communities are nonexistant. What use is the best technology in the world if nobody uses it? Noone uses Friendica events and birthdays and whatever. That makes me sad.

#fedi #mastodon #pixelfed #friendica #gotosocial

@Chao-c'

BTW I had account on identi.ca, which was StatusNet powered (I believe).

It was. At least until Evan and Erin could no longer justify it running on that janky OStatus protocol. The result was the ActivityPump protocol, the pump.io software and Identi.ca's switch to pump.io with all hands on board.

Yes, and it should not be implemented in Ruby or PHP or something like that. I have seen one online discussion forum being rewritten from PHP to Rust few years ago, and the improvement in responsiveness of the web platform was amazing. (I do C, not Rust, but C is too oldschool now, and the performance penalty of Rust is minor, probably not noticeable at all)

This reminds me of how the Fediverse is all over the place in terms of programming languages. Everyone has their own Holy Grail.

Friendica and its descendants are written in PHP. They may not be the fastest (even though what bogged down early Friendica were its heavyweight federation connectors to everywhere, especially the one for Facebook that came in 2011). Mike either discarded or rewrote these when he rewrote Red. But they happily run on a run-of-the-mill LAMP stack.

Mastodon is written in Ruby on Rails. Hubzilla runs circles around it in terms of performance per account/channel, and that has to say something. The only thing that managed to top this was early diaspora*, written in Ruby on Rails for Mac with MongoDB as the database system.

The *omas are built in Elixir. Granted, they're utter featherweights, especially considering their features. They're legendary for their low server impact. Then again, Pleroma apparently is spaghetti code straight from hell. Its own devs often don't have a clue where to go look for bugs, much less how to fix them. (Miraculously, the Akkoma devs do manage to get ride of quite a number of them.)

The *keys are built in TypeScript and Vue.js. I guess one reason why Misskey is infamous for having so many forks and forks of forks is because there are tons of people who can code in JavaScript, the primary mobile programming language.

Iceshrimp.NET is a still very incomplete "rewrite" of old Iceshrimp in C#. It was largely tackled to get rid of all those nasty bugs inherited from Misskey that even Misskey doesn't manage to get rid of. I've heard quite some outcry: Iceshrimp.NET is a sell-out to Microsoft. I guess whoever uttered that didn't go check who owns TypeScript.

PieFed is a dead giveaway: Python. And PieFed makes more headlines in the Threadiverse for server politics than for its underlying technology, except that Lemmy pales in comparison.

GoToSocial is a dead giveaway, too: Go. And it was one of the first Fediverse server applications to not come with a Web UI. Those who use it for a single-user server often don't even bother installing one and use some Mastodon app or other instead. Besides, why drag around a Web UI if there are much better third-party Web UIs than whatever you could whip up?

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Friendica #Hubzilla #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Iceshrimp #IceshrimpJS #Iceshrimp.NET #PieFed #GoToSocial #PHP #RubyOnRails #Elixir #JavaScript #TypeScript #VueJS #C# #Python #Go

The positive result of the #Codeberg membership votes to ban so-called "vibe-coded" projects from Codeberg (see here) makes us very proud to continue hosting #GoToSocial on @Codeberg!

Following the votes and changes to the terms and conditions, Codeberg has written up their stance on LLM's and "vibe-coded" projects:

Although often well intentioned, sharing the result of an prompt and calling it "libre software" does not make the world a better place. Codeberg is not and does not want to be a place to dump such generated single-use software that no one else will ever look at. We are a place for people to collaborate and improve software together. Within this context, the recent votes can be understood as a reconfirmation of those principles: As we want to center on human collaboration, we will not actively support or engage in the creation of LLMs and will not put our limited resources to use for storing single-use software that would pollute our FLOSS commons.

The blog post is well-written, well-sourced, and worth reading in full:

blog.codeberg.org/protecting-o…

Since GtS has a very pointed anti-LLM policy in our Code Of Conduct, it's particularly pleasing to us that Codeberg is now pointing out that users are no longer welcome on Codeberg if they "[send] LLM contributions in violation of project's custom policies". Happily for us, this has not been a recurring problem on GtS as we tend to give off vibes that keep slop-fondlers at arm's length, but it's good to know that our anti-"ai" policy has institutional support now in case it becomes more of a problem in future.

If you want thank Codeberg by supporting them with membership and/or donations you can do so here: join.codeberg.org/

Hello sloth aficionados!

This is a security announcement for an issue that was fixed in #GoToSocial releases v0.21.3 and v0.22.0. If you are running an earlier version of GoToSocial please find time to upgrade to one of these releases as soon as possible!

The security vulnerability allows a remote attacker crafting (properly signed) ActivityPub activies to send Create, Update and Announce activities to a GtS instance that persist statuses / boosts as if they were written by a remote victim account. This happens due to our (previously) incorrect handling of multi-valued attributedTo and actor in the effected activities. We are not aware of anybody using this vulnerability in the wild, but it remains possible on all GtS versions v0.21.2 and below.

This was kindly disclosed to us by Lain of the Pleroma project, thank you Lain!

Timeline:

• June 23rd, Lain emailed admin@gotosocial.org with details of the issue.
• June 24th, a fix was merged.
• June 25th, versions v0.21.3 and v0.22.0-rc4 including the fix were released, along with a pre-disclosure warning of the security issue urging users to update.
• July 6th, security vulnerability publicly disclosed by this post.

GoToSocial

2026-06-25 13:50:21

Hello everyone, the two releases we announced today (v0.21.3 and v0.22.0-rc4) each contain an important fix for a security vulnerability about which we will disclose more details next week to give people time to upgrade.

In the meantime:

If you're on #GoToSocial v0.22.0 release candidates, please update to v0.22.0-rc4 as soon as you can: gts.superseriousbusiness.org/@…

If you're on #GoToSocial v0.21.2 or below, please update to v0.21.3 as soon as you can: gts.superseriousbusiness.org/@… The update from v0.21.x to v0.21.3 contains no database migrations or anything so it should be very quick + easy.

GoToSocial is a type of Fediverse server which emphasises user safety and being lightweight to host. It's really good, and is particularly popular with those who self-host their Fediverse accounts.

The developers of GoToSocial's software are currently trying to raise money to keep the project going. You can help by donating at:

➡️ opencollective.com/gotosocial#…

Here is more info about what the money is needed for:

➡️ gts.superseriousbusiness.org/@…

You can follow them at @gotosocial

#GTS #GoToSocial

GoToSocial

2026-06-29 15:29:06

Hello sloth valuers! #GoToSocial could use your help!

TL;DR, please help us by donating to our OpenCollective page so we (Tobi and Kim) can pay ourselves a basic monthly wage.

---

Long explanation:

In order to keep work on the GtS codebase buzzing along, Tobi and Kim have to perform the increasingly expensive chore of maintaining their flesh temples by consuming calories, keeping warm and dry (or cool and wet, depending on the circumstances), doing routine bodily maintenance, and so on. Not to mention paying for electricity, internet, etc.

The money we need for all this has so far largely been provided to us by NLnet, the Dutch organization that funds a lot of fediverse projects (among other interesting things). NLnet's support has been of incredible value. Indeed, without it GoToSocial would not exist in its current form; we'd have long since had to get "real jobs" and GtS would have been relegated to being a side project.

However, due to the way that funding from NLnet works, we get paid only for delivering features that we scope out long in advance of when the funding period actually begins. In other words, we get paid every time we merge a big feature, details of which are agreed up to a year beforehand. However, this payout happens only intermittently, since big features take a large amount of time to write.

As everyone who works on code knows, there's more to a project than just writing headline features. We don't get paid for spending time doing things like maintenance, bugfixes, small bonus features, refactoring, triage, helping people in the Matrix chats, code review, and what have you. So, the intermittent way that we get paid means we have to juggle working on very important but unpaid "maintenance" stuff, alongside paid "feature" stuff when our bank accounts start to look worryingly moth-filled. This causes semi-regularly panics in the both of us, as neither of us are particularly resilient when it comes to dealing with financial pressures.

To make working on GoToSocial more sustainable, then, we want to be able to pay ourselves--the two most active devs--a basic monthly salary for all the work we do that isn't big headline features. This will allow us to commit time to unglamorous but vital maintenance chores, without the constant background worry that by doing so we're going to end up running out of money at a critical moment. To make this happen, we need your help!

Thanks to all our donors on OpenCollective and Liberapay, we'd accrued enough unspent money over the years to be able to pay ourselves 1,000 EUR each, each month, for the months of February, March, April, and May 2026 (plus a little bit here and there from Liberapay). For transparency's sake, you can see those payouts here.

As you'll see from our OpenCollective budget, however, we don't make enough from donations to keep this up, and indeed at the time of writing we have only 2000 EUR left in our OpenCollective budget, which gives us ~3/4 of a month when accounting for ongoing hosting costs.

And so, we're asking you, dear sweet reader, sexy-ass cool reader, for a donation or two to our OpenCollective pot:

opencollective.com/gotosocial#…

With your help, we want to be able to raise about 2,500 EUR per month, so that we can continue to pay ourselves 1,000 EUR each per month, plus various other costs that are paid out of the OpenCollective.

Thank you for reading this absolute saga of a post, and for considering donating to us. We really appreciate it!

GoToSocial - Open Collective

Develops open source Fediverse/ActivityPub software

^{opencollective.com}

Hello #GoToSocial enjoyers, after a very fruitful release candidate process (thanks everyone!), we've just released the proper version of GoToSocial 0.22.0, aka Shrubby Sloth 🌿:

codeberg.org/superseriousbusin…

This is a big feature release that contains support for relay subscriptions and relay push connections, a new instance account directory, better threading using tombstones for deleted statuses,, and support for auto-cleanup of old remote statuses, among lots of other things!

⚠️⚠️⚠️ As always, please read the migration notes carefully for instructions on how to upgrade to this version, in particular note that there are several config file changes that need to be addressed when you're updating from a previous version of GoToSocial to this version.

This release also contains a long-ass database migration to move status boolean columns (like pinned, local, etc) to a single bitfield column. This saves a lot of space in the database, but it also means on startup the migration has to iterate through all statuses in your database and set the new field. Please be patient and don't interrupt this process! ⚠️⚠️⚠️

Release highlights

• Relay support: GoToSocial now supports subscribing to relays (as an admin action), and pushing posts to relays (configured per-user, with filters available).
  Documentation for admin-level relay subscriptions.
  Documentation for user-level relays pushes.
• Automated cleanup of old remote posts: you can now configure your instance to clean up threads of remote statuses that haven't been interacted with by anyone on your instance. This should save a lot of space in folks' databases!
  Documentation for post caching + pruning.
• Delivery error tracking for remote instances: there's now a page in the settings panel where admin can view errors encountered while attempting delivery of posts to instances that may be experiencing technical difficulties or may have gone offline. You can use this to get a quick view on possible "dead" instances that you can then remove from your database with a domain block.
• Accounts directory: there's a new setting to allow admins to expose (or not) a directory of accounts on the instance! Your account will only be shown in the directory if you opt in via your privacy settings.
  Documentation for inclusion in account directory.
• Better tracking of deleted statuses/status tombstones: GtS now stores tombstones for deleted statuses, allowing threads to remain intact even when a status in the middle of the thread has been deleted.
• Better status codes + info pages on deleted or hidden statuses: the old 404 page when you try to open a hidden status in the browser has been replaced with a more informative error page.
• Way more configurable http server + client options: we've exposed a whole shitload of settings that you can tweak on the HTTP client + HTTP server that GoToSocial uses. We don't recommend changing these, but if you really want to, now you can.
• Show your Träwelling status on your profile by setting your Träwelling page as a field value, similar to how our ListenBrainz integration already works.
• Allow setting a name for your tokens, and sorting tokens by last used time in the token view of the settings page. Should make it a lot easier to track which tokens you've created, and when they were used by which apps!
• Better layout for web view of profiles that hide all posts from the web: it just uses a single-column view now.

Thank you for reading and happy pride 🌈

Hello sloth valuers! #GoToSocial could use your help!

TL;DR, please help us by donating to our OpenCollective page so we (Tobi and Kim) can pay ourselves a basic monthly wage.

Long explanation:

In order to keep work on the GtS codebase buzzing along, Tobi and Kim have to perform the increasingly expensive chore of maintaining their flesh temples by consuming calories, keeping warm and dry (or cool and wet, depending on the circumstances), doing routine bodily maintenance, and so on. Not to mention paying for electricity, internet, etc.

The money we need for all this has so far largely been provided to us by NLnet, the Dutch organization that funds a lot of fediverse projects (among other interesting things). NLnet's support has been of incredible value. Indeed, without it GoToSocial would not exist in its current form; we'd have long since had to get "real jobs" and GtS would have been relegated to being a side project.

However, due to the way that funding from NLnet works, we get paid only for delivering features that we scope out long in advance of when the funding period actually begins. In other words, we get paid every time we merge a big feature, details of which are agreed up to a year beforehand. However, this payout happens only intermittently, since big features take a large amount of time to write.

As everyone who works on code knows, there's more to a project than just writing headline features. We don't get paid for spending time doing things like maintenance, bugfixes, small bonus features, refactoring, triage, helping people in the Matrix chats, code review, and what have you. So, the intermittent way that we get paid means we have to juggle working on very important but unpaid "maintenance" stuff, alongside paid "feature" stuff when our bank accounts start to look worryingly moth-filled. This causes semi-regularly panics in the both of us, as neither of us are particularly resilient when it comes to dealing with financial pressures.

To make working on GoToSocial more sustainable, then, we want to be able to pay ourselves--the two most active devs--a basic monthly salary for all the work we do that isn't big headline features. This will allow us to commit time to unglamorous but vital maintenance chores, without the constant background worry that by doing so we're going to end up running out of money at a critical moment. To make this happen, we need your help!

Thanks to all our donors on OpenCollective and Liberapay, we'd accrued enough unspent money over the years to be able to pay ourselves 1,000 EUR each, each month, for the months of February, March, April, and May 2026 (plus a little bit here and there from Liberapay). For transparency's sake, you can see those payouts here.

As you'll see from our OpenCollective budget, however, we don't make enough from donations to keep this up, and indeed at the time of writing we have only 2000 EUR left in our OpenCollective budget, which gives us ~3/4 of a month when accounting for ongoing hosting costs.

And so, we're asking you, dear sweet reader, sexy-ass cool reader, for a donation or two to our OpenCollective pot:

opencollective.com/gotosocial#…

With your help, we want to be able to raise about 2,500 EUR per month, so that we can continue to pay ourselves 1,000 EUR each per month, plus various other costs that are paid out of the OpenCollective.

Thank you for reading this absolute saga of a post, and for considering donating to us. We really appreciate it!

Hello everyone, the two releases we announced today (v0.21.3 and v0.22.0-rc4) each contain an important fix for a security vulnerability about which we will disclose more details next week to give people time to upgrade.

In the meantime:

If you're on #GoToSocial v0.22.0 release candidates, please update to v0.22.0-rc4 as soon as you can: gts.superseriousbusiness.org/@…

If you're on #GoToSocial v0.21.2 or below, please update to v0.21.3 as soon as you can: gts.superseriousbusiness.org/@… The update from v0.21.x to v0.21.3 contains no database migrations or anything so it should be very quick + easy.

GoToSocial

2026-06-25 08:18:25

Greetings fellow kids!

We just released v0.21.3 of #GoToSocial, aka Most Sacrilegious Sloth:

codeberg.org/superseriousbusin…

This is the last bugfix + dependency update release for v0.21.x!

⚠️ We strongly urge everyone currently on v0.21.2 or lower to update to this release, as it contains some important bugfixes related to exif data stripping and a security fix for a vulnerability whereby malformed AP messages can cause mischief. We will make a more detailed post about this vulnerability next week, to give people time to update. ⚠️

If you're updating to this version from v0.21.x, it's a very easy update with no db migrations.

If you're updating to this version from a version before v0.21.0, please follow the update instructions from v0.21.0, but replace 0.21.0 with 0.21.3 throughout. Be aware that the update to 0.21.x contains some database migrations. Please do read the notes carefully!

Don't switch to this version from current (25 Jun 2026) snapshots or v0.22.0 release candidates. They already have everything that's in here (and more).

• Video processing fixes.
• Updated robots.txt to tell more bullshit crawlers to fuck off.
• Fixed some streaming API stuff.
• Bug fixes related to exif stripping and malformed AP messages.
• Dependency updates.

Thanks for reading!

v0.21.0 Sacrilegious Sloth - superseriousbusiness/gotosocial

Here's version 0.21.0 of GoToSocial! Sacrilegious sloth! 🥇 🦥 We're really proud of this one, the sloth is starting to feel really useable and good! We're getting somewhere! Please read the migration notes carefully for instructions on how to up…

^Codeberg.org

Greetings fellow kids!

We just released v0.21.3 of #GoToSocial, aka Most Sacrilegious Sloth:

codeberg.org/superseriousbusin…

This is the last bugfix + dependency update release for v0.21.x!

⚠️ We strongly urge everyone currently on v0.21.2 or lower to update to this release, as it contains some important bugfixes related to exif data stripping and a security fix for a vulnerability whereby malformed AP messages can cause mischief. We will make a more detailed post about this vulnerability next week, to give people time to update. ⚠️

If you're updating to this version from v0.21.x, it's a very easy update with no db migrations.

If you're updating to this version from a version before v0.21.0, please follow the update instructions from v0.21.0, but replace 0.21.0 with 0.21.3 throughout. Be aware that the update to 0.21.x contains some database migrations. Please do read the notes carefully!

Don't switch to this version from current (25 Jun 2026) snapshots or v0.22.0 release candidates. They already have everything that's in here (and more).

• Video processing fixes.
• Updated robots.txt to tell more bullshit crawlers to fuck off.
• Fixed some streaming API stuff.
• Bug fixes related to exif stripping and malformed AP messages.
• Dependency updates.

Thanks for reading!

Hello pals, here's the first release candidate for version 0.22.0 of #GoToSocial:

codeberg.org/superseriousbusin…

Admins who are feeling adventurous or desperate for the new stuff can try out this release candidate at their leisure.

As always, please read the migration notes carefully for instructions on how to upgrade to this version, in particular note that there are several config file changes that need to be addressed when you're updating from a previous version of GoToSocial to this version, and there are some quite long database migrations as well.

Release highlights

• Relay support: GoToSocial now supports subscribing to relays (as an admin action), and pushing posts to relays (configured per-user, with filters available).
  Documentation for admin-level relay subscriptions.
  Documentation for user-level relays pushes.
• Automated cleanup of old remote posts: you can now configure your instance to clean up threads of remote statuses that haven't been interacted with by anyone on your instance. This should save a lot of space in folks' databases!
  Documentation for post caching + pruning.
• Delivery error tracking for remote instances: there's now a page in the settings panel where admin can view errors encountered while attempting delivery of posts to instances that may be experiencing technical difficulties or may have gone offline. You can use this to get a quick view on possible "dead" instances that you can then remove from your database with a domain block.
• Accounts directory: there's a new setting to allow admins to expose (or not) a directory of accounts on the instance! Your account will only be shown in the directory if you opt in via your privacy settings.
  Documentation for inclusion in account directory.
• Better tracking of deleted statuses/status tombstones: GtS now stores tombstones for deleted statuses, allowing threads to remain intact even when a status in the middle of the thread has been deleted.
• Better status codes + info pages on deleted or hidden statuses: the old 404 page when you try to open a hidden status in the browser has been replaced with a more informative error page.
• Way more configurable http server + client options: we've exposed a whole shitload of settings that you can tweak on the HTTP client + HTTP server that GoToSocial uses. We don't recommend changing these, but if you really want to, now you can.
• Show your Träwelling status on your profile by setting your Träwelling page as a field value, similar to how our ListenBrainz integration already works.
• Allow setting a name for your tokens, and sorting tokens by last used time in the token view of the settings page. Should make it a lot easier to track which tokens you've created, and when they were used by which apps!
• Better layout for web view of profiles that hide all posts from the web: it just uses a single-column view now.

⚠️⚠️⚠️ This release contains a long-ass database migration to move status boolean columns (like pinned, local, etc) to a single bitfield column. This saves a lot of space in the database, but it also means on startup the migration has to iterate through all statuses in your database and set the new field. Please be patient and don't interrupt this process! ⚠️⚠️⚠️

@Postgres users: Following the migration, if you encounter slowdown on Postgres specifically (ie., timing out while loading home timeline) you may need to regenerate your Postgres visibility map. Please check our Postgres database maintenance documentation for steps on how to do this using the psql tool.

Thanks for reading ❤