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/

RE: mastodon.social/@_elena/116929…

Installed #yunohost yesterday on my Proxmox home server to fiddle around and was about to deploy #GoToSocial. But this "Danger" Box in the docs, saying the domain will be taken forever by this instance of GTS scares me. Or is this the case for every #ActivityPub Server anyway?

I thought, only the full handle like "@user@social.domain.net" can be problematic when being refused because of caching and generated keys. Any experience with that? docs.gotosocial.org/en/v0.22.0…

#selfhosting

Elena Rossini 🌈

2026-07-16 11:52:18

Working on a brand new post for my series "a newbie's guide to self-hosting with #YunoHost" - showing people how to set up their own #GoToSocial microblogging instance.

Sorry it's been taking a while: I started over when I realized most people use subdomains... and I'm doing a thorough step-by-step explainer that any newbie could follow - I hope 😅

The whole series is available here:

🔗 : blog.elenarossini.com/a-newbie…

#SelfHosting #MySoCalledSudoLife #blog

A newbie's guide to self-hosting with YunoHost

Here is a 5-part guide about how to get started self-hosting essential internet services with the YunoHost system

^{Elena Rossini}

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 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 #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 🌈