In 2018 I switched from Twitter to Mastodon. I was rather confused in the beginning. I didn’t quite grasp the concept of all these servers being connected but that you should login on your home server. I also struggled to find people to follow. After I read up on how Mastodon worked the concept landed. I hadn’t quite found a place I wanted to call home though. What I really wanted was my own Mastodon instance. Queer Garden Permalink: “Queer Garden”
Setting up my own instance was made easy by masto.host. Hugo, masto.host’s owner, was kind and helpful. He did the entire setup from start to finish. All I had to do was point my domain at masto.host’s servers. Queer Garden launched on the 14th of August 2018. At the time the cost for this endeavour was €35/year for the domain name and €5/month for the server; in total running Queer Garden for a year took less than €100,-. Some years later I enabled full text search, a €3/month add-on, which increased the yearly cost a little. Even so the total running cost stayed under €140/year.
In October of 2022 masto.host had to increase its prices. They’d been running some clients below cost for a long time and this was no longer feasible. Hugo worked with me to try and reduce Queer Garden’s footprint but it wasn’t enough to prevent a plan upgrade. The new plan came in at $29/month. Coupled with an increase in the domain name price, now €45/year, this meant that Queer Garden’s running cost had ballooned to nearly €400/year. This is still what I pay. With roughly twenty active members that’s about €20,- per member per year. Moderation Permalink: “Moderation”
One of my goals with Queer Garden was to create a safe environment for queer people, and more broadly, minoritized people in general. Mastodon has some nice moderation features. As an admin you can suspend or silence other instances for your entire instance. As a member you can do the same thing for yourself, you can also choose who can see your toots, and there’s a feature to report toots to the moderators. Over the years this toolset for moderation has hardly grown.
There have been calls for improved moderation tools in Mastodon. But these have largely gone unanswered by the Mastodon development team.
Community led initiatives like the #Fediblock-hashtag, created by Artist Marcia X and Ginger, have given people a way to share information about bad actors across the fediverse. The Bad Space, created by Ro, is another example of what could be in terms of features built into Mastodon.
The Bad Space aggregates the moderation efforts of a select few instances. It presents this information on the website so that others can learn about the included bad actors. Like Oliphant’s blocklist it produces blocklists in CSV-format that you can import in your instance’s admin panel. This is where another failing of the Mastodon software rears its head: there’s no way to automate this process. You have to personally import this list with every update. This makes for an unsustainable, and at best impractical, solution.
These tools have filled some of these moderation needs required to run a fediverse instance. The implementation of moderation tools in Mastodon remains wanting. Looking at alternatives Permalink: “Looking at alternatives”
I looked at glitch-soc a few times. It has a lot going for it among which is local-only posting; this is something that fits so well with my goal of creating a safe community. Another benefit is that glitch-soc is a “soft fork” of Mastodon. In this case that means you can switch between the two server software versions without losing your data (there are some other consequences though).
Masto.host doesn’t offer the glitch-soc server software. If I wanted to switch to glitch-soc I would have to switch to another hosting solution. The idea of self-hosting has floated around in my head over the years. This is something I’m still considering. I have some experience with running a web server and have a VPS for my business. But those are relatively easy to maintain. Mastodon on the other hand has quite a few moving parts. Not something I feel like I would want to tackle in terms of setup let alone maintain.
There are some hosting partners that offer glitch-soc out of the box; MidnightCloud for example. Another solution can be found in installing it with YunoHost. A move to either of those would technically be possible. For whatever reason, I have never dared to take the plunge. Maybe it’s the safety of the known in masto.host. Perhaps it’s not wanting to (potentially) mess up Queer Garden’s member data? Whatever the reason, Queer Garden still runs vanilla Mastodon and is still hosted at masto.host. Enter the sloth Permalink: “Enter the sloth”
I’ve been following tobi, one of GoToSocial’s developers, for quite some time on mastodon. They frequently post updates about GoToSocial’s progress, new features, and bugfixes. Which is to say that I’ve been aware of GoToSocial, or GtS for short, for quite some time.
Earlier this year I decided to have a go at setting up my own GtS server. With the GoToSocial documentation by my side I set up the project on my trusty Mac mini. This was a nice way to see how I would fare in setting up the software. I have to say I struggled a bit but this was mostly related to trying to run it on an unsupported platform (and my inexperience with PostgreSQL). Not long afterwards it was time to put this experience into practice and set up GtS on a VPS. Setup Permalink: “Setup”
To make the most of this experiment I ordered a new VPS with 1 vCPU, 2GB of RAM, and 20GB of disk space. This was also a good time to use one of my “I should do something with this someday” domain names. I paired the VPS with feisar.eu. I used this setup guide for a GoToSocial server by Lynn to help me through the process from start to finish, I found it tremendously helpful. With the help of Lynn’s guide I was able to setup GtS with a split domain configuration. This allows me to have a username like “@zoe@feisar.eu” but have the server software run at “gts.feisar.eu”; keeping “feisar.eu” free for other purposes. Thanks to GtS’ low server requirements people have gotten it to run in a bunch of unexpected places including a phone and a car! Time to toot! Permalink: “Time to toot!”
With the setup complete it was time to have a poke at the sloth and see what’s what. I filled in my account details and posted my first toot. Thanks to GtS’ compatibility with the Mastodon API, I was able to log into my account with Ivory (my current go-to iOS Mastodon client). Early on I ran into an issue with posting images from Ivory. But this was solved after looking through the logs; it turned out to be an issue with my Coraza setup. There was definitely a learning curve in getting familiar with the various moving parts mentioned in the guide. Overall though the setup process was a breeze. Admin features Permalink: “Admin features”
As an admin one of my favourite features of GtS is the ability to subscribe to blocklists. The way I have it setup: A subscription to the 50% heat list from The Bad Space Any new blocks added to that list are added as “drafts” I check this periodically and approve the blocks
This is a level of automation and flexibility that Mastodon doesn’t offer. Being able to do this feels like such a breath of fresh air. At the same time I’m filling the “Domain Allows”-section with instances I know I want to federate with. The idea of running GtS in “Allowlist Mode” is exciting to me. In “Allowlist Mode” only instances that you approve are able to federate with your instance. This is an experimental feature but one that I would like to play around with. Frontend Permalink: “Frontend”
GtS doesn’t come with its own frontend. Not in the way that Mastodon does. GtS has an admin panel where you can configure things or deal with moderation. It also has a profile view for each account, you can view my profile to see an example. But what it doesn’t have is a way to post anything. Or view other people’s toots.
This is where the Masto-FE fork comes in. Masto-FE is a standalone version of the Mastodon frontend. The forked version I linked to includes changes that make it the perfect companion for GtS. You can set your toot to be local-only for example, or use Markdown to format your toots.
With the split domain configuration it would be possible to run GtS on a subdomain and have Masto-FE run on the main domain. That way members can still navigate to the main URL and have full access to a web client. Backend Permalink: “Backend”
On the backend there’s also a lot to like. One thing in particular I appreciate is how easy it’s to upgrade GtS. Thanks to a few release candidates being released in the past month I had the opportunity to go through about four update cycles. I wrote a little script to execute the various parts of the update cycle; it takes me about two minutes in total.
The steps are: Run the backup service: sudo systemctl start restic.service Navigate to install folder: cd /var/lib/gotosocial Set the version, file, and URL tags: GTS_VERSION=0.19.2 && GTS_FILE=gotosocial_${GTS_VERSION}_linux_amd64.tar.gz Download the release: sudo wget https://codeberg.org/superseriousbusiness/gotosocial/releases/download/v${GTS_VERSION}/${GTS_FILE} Download the checksum: sudo wget https://codeberg.org/superseriousbusiness/gotosocial/releases/download/v${GTS_VERSION}/checksums.txt` Compare sha256: grep ${GTS_FILE} checksums.txt | shasum -c Stop GtS: sudo systemctl stop gotosocial.service Extract the release: sudo tar -xzf gotosocial_${GTS_VERSION}_linux_amd64.tar.gz Move the binary and set rights: sudo chmod u=x,g=x,o-rwx /var/lib/gotosocial/gotosocial sudo chown gotosocial:gotosocial /var/lib/gotosocial/gotosocial sudo mv /var/lib/gotosocial/gotosocial /usr/bin/ Cleanup the folder: sudo rm -rf /var/lib/gotosocial/checksums.txt /var/lib/gotosocial/example/ /var/lib/gotosocial/${GTS_FILE} Start GtS: sudo systemctl start gotosocial.service
It would be nice to fine-tune this and perhaps automate it further with some bash scripting. For now this is good enough. Plus seeing the separate steps makes knowing things are going well, and debugging them when they don’t, easier. Running cost Permalink: “Running cost”
The domain name I’m using is rather cheap at €22,50 for three years. The “lite” VPS costs about €4/month. All together that’s less than €5/month. I expect this number to change as the instance grows. But for now it’s a much nicer figure than the running cost of Queer Garden. Conclusion Permalink: “Conclusion”
I’ve been really enjoying my time with GoToSocial so far and look forward to doing more with it. What I haven’t decided yet is how to move forward. I want to keep the Queer Garden name and domain. I don’t want to force people to move to different software and lose their data. As I move forward with testing I can definitely see myself offering GtS to Queer Garden members at “gts.queer.garden” for example. With time, perhaps, I can deprecate Queer Garden’s Mastodon instance and serve Masto-FE on the main domain. Time will tell.
Your h-entries should have, at minimum, the following properties:
e-content — the main content of the post
p-name — if your post is an article with a name, use this classname.
dt-published — the datetime the post was published at, in ISO8601 format, with a timezone
u-url — the canonical URL of the post, especially important on pages listing multiple posts
It’s a common convention for the published datetime to be a link to the post itself, but they can be separate if you want.
There should also be some way to discover the author of the post — either link to your homepage (which should have your h-card on it) from anywhere within the body of the page with rel=author, or optionally embed a p-author h-card in the h-entry.
The web is an expressive medium, and as such there are many other properties which you can add to your posts. Check out the h-entry documentation for a full list.
Want to be able to use h-entry data in your code? Check out the open-source implementations.