Using GoToSocial as the Social Layer for Your Apps

I have been experimenting with GoToSocial as an identity and social layer for my applications. The goal is simple: let people use social features inside an app without asking them to understand the Fediverse first, create several accounts, or jump between websites to interact.

This post is the background and, more importantly, the why. The next parts will get into the implementation.

You may know me as the person who does weird things with the Fediverse: implementing ActivityPub on a static site, combining badges with federation in BadgeFed, or building a Fediverse link-in-bio service at FediProfile. Well, I have another experiment. Buckle up.

The path to this problem

Some time ago, I created a social media management app named VocalCat. It had limited success, but it was my first production-grade side project in a long time. I built it with .NET, Blazor, and PostgreSQL. The stack scaled nicely, so I kept using it. My ActivityPub implementation for static sites used mostly the same tools, with SQLite added to the mix.

Then I created BadgeFed.

BadgeFed combines ActivityPub and Open Badges to add social and decentralized layers to digital credentials. I have talked about it at FOSDEM, LinuxFest Northwest, and FediCon. You can see it running at badgefed.org, and communitycredentials.org has moved beyond being only a proof of concept.

The decentralized layer is relatively straightforward: an Open Badge is placed inside an ActivityPub object that can travel across instances and different Fediverse software.

The social layer follows naturally:

That worked, but it exposed a different problem.

The wallet I did not want to build

I deliberately avoided creating a wallet inside BadgeFed. I wanted other people and communities to create wallets instead. Maybe that was naive, but the point of decentralizing badges is to avoid one central application owning the entire experience.

That works in theory, especially for people already familiar with the Fediverse. In reality, BadgeFed and Community Credentials are most useful to people who are neither technical nor existing Fediverse users. They kept asking for a wallet.

I still did not want to put one directly into BadgeFed, so I created FediProfile. It looks like a Fediverse link-in-bio page, but it was also a pretext for building a wallet.

In FediProfile, you can add as many links as you want. The profile is itself an ActivityPub actor, so people can follow it. When one of its social links is also an ActivityPub account, such as a Pixelfed or Mastodon account, the profile can boost content from that account. This gives other people one place to follow your work across multiple services.

The less obvious purpose was badge collection. Badges can be issued to profile URLs, so a profile that already connects someone's social accounts is also a natural place to receive and display credentials.

It worked. FediProfile is no longer just a proof of concept; it is a wallet that does not look like a wallet. You can create an account at hub.vocalcat.com.

The multiple-account problem

Then @johannab arrived with some very good ideas about using Fediverse software to empower communities. Those conversations brought a practical question into focus: how do we prevent people from creating a new account for every piece of software they want to use?

Today, someone may create a Pixelfed account for photos, a Mastodon account for short posts, and a Lemmy account for communities. People who already understand federation may accept that model. Everyone else gets confused. This is not a theoretical problem; I have watched it happen.

There are several efforts to provide a more portable identity, and Bluesky has done interesting work with DIDs. But I kept returning to a narrower question: what can we build right now with the software and protocols already available?

Reducing login friction

One lesson from VocalCat was to avoid making people create another password whenever possible. VocalCat allowed people to sign in with Google, LinkedIn, Mastodon, or GitHub through their respective OAuth flows.

I carried that approach into BadgeFed and FediProfile. People can sign in using a Mastodon or GoToSocial account, or with LinkedIn. Community Credentials was designed for people outside the Fediverse, so its account friction needs to be close to zero. When I eventually added a wallet there, I reused the same login.

Authentication was only one part of the friction, though.

Bringing interactions into BadgeFed

Interacting with a BadgeFed credential was still cumbersome. A person had to copy its URL, open a Fediverse client, resolve the URL, and then comment, like, or boost it. That is possible, but it is not a good default workflow for someone who does not already live in Mastodon.

So I tried a different approach: what if BadgeFed included the relevant parts of a Mastodon client?

I implemented that, and you can try it at badgefed.org. After signing in, BadgeFed uses the person's OAuth token to call the Mastodon API. They can reply to, like, or boost a credential without copying its URL into another application. They can even upload images.

The credential is still federated, and software beyond Mastodon can still interact with it through ActivityPub. The difference is that the user does not need to leave BadgeFed to participate.

This creates a social layer for digital credentials without isolating the conversation inside one platform, as happens with traditional credential platforms and professional networks. Honestly, it is one of the coolest things I have built recently. I know, I say that often.

The missing account

The embedded client solved the workflow for someone who already had a compatible Fediverse account. I wanted to go further: what about a person who does not have one?

My ideal flow looks like this:

  1. A person signs in to BadgeFed or Community Credentials using an account they already have.
  2. They enable social features with one setting.
  3. The system provisions the social account they need.
  4. They can immediately reply to, like, and boost credentials inside the application.

They should not need prior knowledge of ActivityPub or the Fediverse, but the resulting account and interactions should still participate in the open social web.

I expected this to become a long journey through Go, the GoToSocial codebase, and probably a custom fork.

GoToSocial surprised me. I did not need to begin with its codebase; I needed to read its documentation. GoToSocial supports OpenID Connect and can use an external identity provider for sign-in and account provisioning. That covered the central capability I thought I would need to build myself.

It is not completely invisible provisioning. On the first login, GoToSocial asks the person to confirm a username, which cannot later be changed because it becomes part of their ActivityPub identity. The identity provider must also return a unique, non-empty email claim. That is still some friction, but it is very different from asking someone to create and manage another set of credentials.

Why GoToSocial changes the design

The important part is not only that users can avoid another password. GoToSocial can provide the social server behind an application while the application provides the experience appropriate to its own community.

That changes the responsibility split:

It also means I do not need to implement an ActivityPub server, federation behavior, moderation primitives, storage management, or blocklist support directly inside every application. There will still be integration and operational work, and I do not yet know every limitation. But this is a much smaller and more maintainable problem than building or forking a social server for each product.

What this series will cover

This series will explore how to use GoToSocial to add social features to other software. The implementation goal is not to hide the Fediverse forever. It is to make the first interaction simple enough that people can discover its benefits by using it.

The next posts will cover:

  1. Configuring GoToSocial with an external OpenID Connect provider.
  2. Provisioning or connecting accounts with minimal user action.
  3. Using the Mastodon-compatible API from an existing application.
  4. The moderation, security, consent, and account-lifecycle questions that appear once the happy path works.

I did not expect my static-site ActivityPub guide to reach nine parts. I expect this one to take two or three, but we will see. The first practical milestone is straightforward: sign in to an existing application, enable its social features, and interact without creating and managing another password.

That is what we will build next. Thanks for reading.