Shall we consider GotoSocial?

Also, it occurs to me if the TWG were to commit to running an additional federated service, IMO it would be more of a value add to stand up another fediverse app that provides complimentary services to mastodon such as pixelfed, write.as, peertube, loops, etc. instead of one that seems to be focused on text blogging/microblogging which mastodon already does.

Also yeah their website isn't loading for me either, and their codeberg readme clearly states it's beta software, neither of which exactly inspires confidence...

I would consider it if we were to set up a new instance. But since it involves migration, I don't think it's worth it, especially because of the issues you mention.

The fact that their page https://gotosocial.org/ doesn't even open for me doesn't inspire confidence at all. Not having a designated front-end doesn't sound good either.

I have no objections to hosting a GoToSocial instance in parallel with our Mastodon instance. I don't think very many people would be happy to migrate over permanently, though, so at best we'd end up hosting two services, which would certainly require more overhead than running Mastodon only.

My impression was that GoToSocial's real strength was for self-hosting; very quick to set up and pretty low maintenance. That's not really our situation, so I'm not sure how much advantage it would provide.

I'm kinda fine with whatever as long as the technical working group is on board with the extra labor this would require of them.

Oh, I'll add that I have a friend who uses... something not Mastodon... which I think might have been GoToSocial, and that I had some problems federating with them from my Hubzilla account. So GoToSocial might present some barriers to maintaining connections outside Mastodon for users who migrate to GoToSocial.

I would say lack of attention to web interface is a non-starter.

Finishing software, meaning spending all that time it takes to complete the last 20% of something, particularly user-facing software - is something that is easy to be unaware of unless you've spent time doing it.

When choosing between "server resources" vs "person time" - it's quite rare that it's better to minimise server resource usage. Ruby and Rails are really effective thesedays.

That said, I do really do love a good Go, Rust, Zig implementation... but practically I don't think it's the right option to choose here unless someone is unstoppably, personally motivated.

@robertguthrie really well said.

If we're on the topic of trying/switching software, I just want to throw in the wrench of https://bonfirenetworks.org, which is a new platform deeply politically aligned with us, co-led by a former leading Social.coop member. It is designed to be heavily customizable.

+1 for trying Bonfire. They are developing many features for the kind of community we are. Supporting ActivityPub indeed. Have a look at their site, <https://bonfirenetworks.org/>

"Nathan Schneider (via Loomio)" \ schreef op 1 augustus 2025 16:00:52 CEST:

>

Good reminder thanks @Nathan Schneider . Is there a lot that runs on Bonfire yet, very easy to configure? Or is it still 'all to play for'? The very openness of Bonfire might mean a lot of work? But Bonfire is built under the ActivityPub protocol, yes?

I really dig GoToSocial. But instances this size aren't really the use case, more linux and self hosting nerds.

The character limit can be adjusted manually and we could just vote on that here. Some instances – like tldr-nettime, which notoriously revolves around complex topics – opt for (the Masto-fork) Hometown, which has more by default.

I love the diversity of the fediverse, and you can easily ride many horses. But we did grow out of the #BuyTwitter campaign, so we're clearly microbloggers.

@Robert Guthrie

I would say lack of attention to web interface is a non-starter.

If the goal is to eventually develop a web interface, then yes, bang on. But that's a non-goal of GtS. They're focused on building a resource efficient and feature-complete back-end, to be used with third-party clients that implement the Mastodon client-to-server API. The GtS devs outsource the UX design to people who enjoy that and do it well (hopefully), so they can focus on what they enjoy and do well.

When choosing between "server resources" vs "person time" - it's quite rare that it's better to minimise server resource usage.

If you're willing to host on AWS, and ramp up revenue to keep pace with server costs (as mastodon.social does), then sure. But that's an anti-goal of GtS. Which began as a single-account server, with the goal of being efficient enough to be run on an old PC in the closet. Thus decentralising server hosting, to further decentralise social networking.

I understand it now supports multiple accounts, but I think @Daniel Brandes is right that it's optimised for hosting small groups like families and social clubs, more than larger organisations like social.coop.

I agree with @Nathan Schneider that Bonfire is a more aligned choice for experimenting with a second fediverse service. Not only is Mayel well known to many of us, but so are many of its advisory circle, including @Lynn Foster , @Bob Haugen, @Doug Belshaw and Nathan himself.

@mike_hales

Is there a lot that runs on Bonfire yet, very easy to configure?

As I understand it, Bonfire consists of a base engine and a range of extensions (like plugins?) that can be combined in different ways, to make a range of web interface 'flavours' designed around different use cases. Which is quite innovative in itself. So far, Bonfire Social has 1.0 release candidate, and that's what I'd suggest social.coop kick the tires on.

Bonfire is built under the ActivityPub protocol, yes?

Definitely. But it brings a number of new features that Mastodon lacks, like 'circles' and 'roles' that offer granular control over who sees a post, markdown editing, and particularly support for groups.

From my reading of Mike's OP and the comments so far, the proposal is to stand up a second fediverse instance for those keen to experiment, not to kill the current Mastodon instance. I don't think abandoning Mastodon would be wise unless and until a replacement has been thoroughly use-tested and stress-tested, and there is overwhelming consensus to do so.

@Danyl Strype Thanks for tagging me. FWIW I would be very up for social.coop having a Bonfire instance alongside the current Mastodon provision.

Not trying to derail the conversation, and perhaps this is for another thread, but I'd also be interested in social documents, for example. So things like CryptPad or Docs.