#social-web — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #social-web, aggregated by home.social.
-
Free idea:
A Fediverse/Social Web front-end for YouTube. Kill the algorithm and the front page. You make an account on an instance, and that server handles delivering videos for you to click on.
They *could* do this in any way they want, but let's be honest, the best way to do it would be via community sharing. You can "boost" videos, and then all your followers can see those videos. You just follow people who tend to like the same kinds of videos as you. You can also directly follow the people you're subscribed to (like, the YouTube channel, not a Fediverse account), and get a consistent feed of all their uploads.
The people running it wouldn't need to handle hosting video content. They just cache metadata, and it should theoretically be quite similar to running a Mastodon instance. You don't even need to have a video player, you can just have a link that sends you to the official YouTube site.
Does this already exist? Last I heard, YouTube has pretty good support still for their APIs that let people do this kind of stuff.
-
Free idea:
A Fediverse/Social Web front-end for YouTube. Kill the algorithm and the front page. You make an account on an instance, and that server handles delivering videos for you to click on.
They *could* do this in any way they want, but let's be honest, the best way to do it would be via community sharing. You can "boost" videos, and then all your followers can see those videos. You just follow people who tend to like the same kinds of videos as you. You can also directly follow the people you're subscribed to (like, the YouTube channel, not a Fediverse account), and get a consistent feed of all their uploads.
The people running it wouldn't need to handle hosting video content. They just cache metadata, and it should theoretically be quite similar to running a Mastodon instance. You don't even need to have a video player, you can just have a link that sends you to the official YouTube site.
Does this already exist? Last I heard, YouTube has pretty good support still for their APIs that let people do this kind of stuff.
-
“…the World Wide Web Consortium ( #W3C ) formally re-chartered the #SocialWeb Working Group (2026–2028). At the top of its agenda is a standard designed to make server #migration seamless: #LOLA (Live, #OnlinePortability ).
In this article, we examine how the LOLA specification works, why seamless account #portability is the missing pillar of the #openweb, and how it compares to alternative models like the AT Protocol's Personal Data Servers ( #PDS ).”
https://opensocialbiz.com/articles/right-to-leave-w3c-lola-fediverse-account-migration -
“…the World Wide Web Consortium ( #W3C ) formally re-chartered the #SocialWeb Working Group (2026–2028). At the top of its agenda is a standard designed to make server #migration seamless: #LOLA (Live, #OnlinePortability ).
In this article, we examine how the LOLA specification works, why seamless account #portability is the missing pillar of the #openweb, and how it compares to alternative models like the AT Protocol's Personal Data Servers ( #PDS ).”
https://opensocialbiz.com/articles/right-to-leave-w3c-lola-fediverse-account-migration -
Today we're sharing additional guidelines about our Trade Mark Policy based on community feedback that we received.
The new guidelines, and more background about these changes, are available on our blog:
https://blog.joinmastodon.org/2026/08/sharing-guidelines-about-mastodons-trade-mark-policy/#Mastodon #Fediverse #SocialWeb #FediDev #MastoDev #FediAdmin #MastoAdmin
-
Today we're sharing additional guidelines about our Trade Mark Policy based on community feedback that we received.
The new guidelines, and more background about these changes, are available on our blog:
https://blog.joinmastodon.org/2026/08/sharing-guidelines-about-mastodons-trade-mark-policy/#Mastodon #Fediverse #SocialWeb #FediDev #MastoDev #FediAdmin #MastoAdmin
-
Finally, a special shout out and thank you to @neil - as well as the other friend who wished to remain anonymous - for their assistance with shaping these guidelines!
-
Finally, a special shout out and thank you to @neil - as well as the other friend who wished to remain anonymous - for their assistance with shaping these guidelines!
-
Hey friends, it's me again :blobfoxwave:
We have more news to share today, though I must admit, this news is a little less fun.
Recently, the @Mastodon team received a fair number of questions about our trade mark policy. We realised we could add some guidelines to help make the Policy more clear, so over the last few months, we did just that! I'll post a "plain English" version of the guidelines as a comment.
You can read more background about the changes we made, and see the guidelines themselves, in this blog post:
https://blog.joinmastodon.org/2026/08/sharing-guidelines-about-mastodons-trade-mark-policy/And the trade mark policy page is updated too:
https://joinmastodon.org/trademark -
Hey friends, it's me again :blobfoxwave:
We have more news to share today, though I must admit, this news is a little less fun.
Recently, the @Mastodon team received a fair number of questions about our trade mark policy. We realised we could add some guidelines to help make the Policy more clear, so over the last few months, we did just that! I'll post a "plain English" version of the guidelines as a comment.
You can read more background about the changes we made, and see the guidelines themselves, in this blog post:
https://blog.joinmastodon.org/2026/08/sharing-guidelines-about-mastodons-trade-mark-policy/And the trade mark policy page is updated too:
https://joinmastodon.org/trademark -
I have exciting news to share!! :mastodondance:
It looks like we're finally gearing up to start migrating people over into @Mastodon's new @zulip instance for certain parts of our community next week (#MastoAdmin #FediAdmin #FediDev #Mod etc.)! It has been a long time in the making and I'm sorry for the delay, but I'm so glad we're finally going to start getting people in there <3 We'll start by beta testing with a few individuals next week to make sure everything is ready for a larger wave of people to join <3 <3
More on #DefaultServerRecommendations soon too — stay tuned!
-
I have exciting news to share!! :mastodondance:
It looks like we're finally gearing up to start migrating people over into @Mastodon's new @zulip instance for certain parts of our community next week (#MastoAdmin #FediAdmin #FediDev #Mod etc.)! It has been a long time in the making and I'm sorry for the delay, but I'm so glad we're finally going to start getting people in there <3 We'll start by beta testing with a few individuals next week to make sure everything is ready for a larger wave of people to join <3 <3
More on #DefaultServerRecommendations soon too — stay tuned!
-
Elon, or data sovereignty, will never work. It never did, so why are you still using the same approach 20 years later?
Want to make a dent against walled gardens? Get Pacific-Asia into the open #SocialWeb.
So much untapped network power & influence. -
The point is, the open #SocialWeb is not tapping the proper crowd. The largest SNS / Social Media crowd is in Pacific-Asia (CJKM, ASEAN).
You can only reach this crowd by sponsoring Kdramas, Jdramas, Cdramas, Pdramas / Teleresyes, Tdrama / ThaiDramas, and so on.
Talking about privacy, Meta, -
The point is, the open #SocialWeb is not tapping the proper crowd. The largest SNS / Social Media crowd is in Pacific-Asia (CJKM, ASEAN).
You can only reach this crowd by sponsoring Kdramas, Jdramas, Cdramas, Pdramas / Teleresyes, Tdrama / ThaiDramas, and so on.
Talking about privacy, Meta, -
Here's yet another way.
Bluesky PBC, or someone with funds, should buy PPL (Product Placement) spots in popular Kdramas.
Watch how the ATmosphere network, and the open Social Web in general, grows.
#ATmosphere #SocialWeb #Bluesky -
Bluesky PBC, or someone else with funds, should partner/sponsor a Korean celebrity and their fandom to produce ATmosphere exclusive content.
Watch how the ATmosphere network, and open Social Web in general, will grow.
#ATmosphere #SocialWeb #Bluesky -
Invite links to the ATmosphere network should be restored but gamified.
It could be:
- Various levels of titles/achievements
- Some cool feature (unlock emoji reactions perhaps)
- Free 7 days pro to a user's choice of Standard site platform
- 7 days access to @[email protected] Premium -
Michael and Saskia have been invited to Rebuild 2!
We'll be there championing non-profit efforts, decentralised systems, and the brilliant projects on the Social Web - not just the Newsmast Foundation.
#Rebuild #SocialWeb #Community -
My advice to new activitypub devs:
- be bold: ship what big tech won't.
- consent first: opt in, never opt out.
- keep evolving: your v1 federation code will be wrong, and that's fine.
- federate the future: interop over lock in, every time.8 years in and I still come back to these.
-
My advice to new activitypub devs:
- be bold: ship what big tech won't.
- consent first: opt in, never opt out.
- keep evolving: your v1 federation code will be wrong, and that's fine.
- federate the future: interop over lock in, every time.8 years in and I still come back to these.
-
Your friends don't care about instances. They care about joining in 5 seconds.
On Loops for iOS it's one tap with Sign in with Apple. No server to pick, no email, no password, nothing to verify.
It. Just. Works.
Federation stays invisible until you go looking for it.
This is how #SocialWeb platforms go mainstream.
-
Your friends don't care about instances. They care about joining in 5 seconds.
On Loops for iOS it's one tap with Sign in with Apple. No server to pick, no email, no password, nothing to verify.
It. Just. Works.
Federation stays invisible until you go looking for it.
This is how #SocialWeb platforms go mainstream.
-
It is now possible to add YouTube, Twitter X, TikTok, and Instagram as a property on you Google Search Console account.
Someone should tell #Google to also include she Open #SocialWeb like the ATmosphere and Fediverse networks. -
We published two new resources on our Help Centre today.
To bring you more transparency about how our moderation team makes decisions, actions they might take against rule-violating behaviour, and the pathways available to you for appealing our decisions: https://help.joinmastodon.org/article/20-moderation-decisions-and-appeals
Plus, learn how to use one of our newest features, Collections, and help people across the #fediverse find new accounts to follow: https://help.joinmastodon.org/article/19-creating-a-collection
-
We published two new resources on our Help Centre today.
To bring you more transparency about how our moderation team makes decisions, actions they might take against rule-violating behaviour, and the pathways available to you for appealing our decisions: https://help.joinmastodon.org/article/20-moderation-decisions-and-appeals
Plus, learn how to use one of our newest features, Collections, and help people across the #fediverse find new accounts to follow: https://help.joinmastodon.org/article/19-creating-a-collection
-
💡 Jetzt online: Das neue #SocialMediaBriefing:
👉️️️ https://king-consult.de/berliner-fediday-im-september-social-media-und-oeffentliche-stellen-werbebudgets-open-social-web-alliance-digitale-unabhaengigkeit-von-anwalts-kanzleien/➡️ Themen:
🔹Wir beim #FediDay #Berlin (11-13 Sept.)→ @berlinfediday
🔹#SocialMedia -Handlungsrahmen des @lfdi_rlp für #Behörden & öffentliche Stellen
🔹@cathleen zum Stand der »Open #SocialWeb Alliance« #OSWA
🔹🇳🇱 #Behörden fordern mehr dig. Autonomie
🔹Lesetipp: @markus_netzpolitik zu dig. Abhängigkeit von #Anwalts-Kanzleien #Recht
🔹#TrötDerWoche von @volkswagenstiftung 👍️📨 per E-Mail abonnieren:
👉️️️ https://king-consult.de/social-media-briefing/ -
💡 Jetzt online: Das neue #SocialMediaBriefing:
👉️️️ https://king-consult.de/berliner-fediday-im-september-social-media-und-oeffentliche-stellen-werbebudgets-open-social-web-alliance-digitale-unabhaengigkeit-von-anwalts-kanzleien/➡️ Themen:
🔹Wir beim #FediDay #Berlin (11-13 Sept.)→ @berlinfediday
🔹#SocialMedia -Handlungsrahmen des @lfdi_rlp für #Behörden & öffentliche Stellen
🔹@cathleen zum Stand der »Open #SocialWeb Alliance« #OSWA
🔹🇳🇱 #Behörden fordern mehr dig. Autonomie
🔹Lesetipp: @markus_netzpolitik zu dig. Abhängigkeit von #Anwalts-Kanzleien #Recht
🔹#TrötDerWoche von @volkswagenstiftung 👍️📨 per E-Mail abonnieren:
👉️️️ https://king-consult.de/social-media-briefing/ -
Heute (Donnerstag) noch bis 16:40 Uhr:
#Umfrage zur Zukunft von #SocialMedia 👍/🫳 /👎 ?
👉 https://mastodon.online/@frebelt/117043428496085930
#EUDI #anonymity #AgeVerification #Altersverifizierung #SocialMediaVerbot #Kommunikation #BigTech #Meta #Instagram #Überwachung #WSocial #SocialWeb #DiDIT
-
Heute (Donnerstag) noch bis 16:40 Uhr:
#Umfrage zur Zukunft von #SocialMedia 👍/🫳 /👎 ?
👉 https://mastodon.online/@frebelt/117043428496085930
#EUDI #anonymity #AgeVerification #Altersverifizierung #SocialMediaVerbot #Kommunikation #BigTech #Meta #Instagram #Überwachung #WSocial #SocialWeb #DiDIT
-
I've written a blog post about influencers, parasocial dynamics, and social media. I look at the way most social media props up monolithic, hugely influential accounts with millions of followers, and punishing anyone who isn't reaching for maximum engagement. I compare this to the way that the Social Web operates, where we end up with accounts that aren't nearly as parasocial, and where much more people feel comfortable contributing to the conversation. Give it a read and I'll love you forever :honk_pride: :kirby_prideheart:
"The Internet was Supposed to be a Community"
https://riverseeber.net/blog/post/the-internet-was-supposed-to-be-a-community/
#blog #SocialWeb #SocialMedia #influencer #community #art #humans
-
I've written a blog post about influencers, parasocial dynamics, and social media. I look at the way most social media props up monolithic, hugely influential accounts with millions of followers, and punishing anyone who isn't reaching for maximum engagement. I compare this to the way that the Social Web operates, where we end up with accounts that aren't nearly as parasocial, and where much more people feel comfortable contributing to the conversation. Give it a read and I'll love you forever :honk_pride: :kirby_prideheart:
"The Internet was Supposed to be a Community"
https://riverseeber.net/blog/post/the-internet-was-supposed-to-be-a-community/
#blog #SocialWeb #SocialMedia #influencer #community #art #humans
-
Using GoToSocial as the Social Layer for Your Apps
Summary: How GoToSocial can provide identity, federation, and social features inside existing applications without requiring users to create and manage another account.
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:
- Issuers are ActivityPub actors, so people can follow them.
- Badges and awards are ActivityPub notes, so people can like, boost, share, and comment on them.
- In practice, people can follow issuers and receive their badges through the social web.
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:
- A person signs in to BadgeFed or Community Credentials using an account they already have.
- They enable social features with one setting.
- The system provisions the social account they need.
- 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:
- The application owns its domain-specific interface and workflows.
- The identity provider handles the user's existing sign-in.
- GoToSocial provides ActivityPub federation and Mastodon-compatible APIs.
- Users interact from the application instead of learning a separate social client first.
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:
- Configuring GoToSocial with an external OpenID Connect provider.
- Provisioning or connecting accounts with minimal user action.
- Using the Mastodon-compatible API from an existing application.
- 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.
Also readable in: https://maho.dev/2026/08/using-gotosocial-as-the-social-layer-for-your-apps/ by @mapache:
#GoToSocial #ActivityPub #Fediverse #OpenID Connect #OAuth #Social Web #BadgeFed #FediProfile
-
Using GoToSocial as the Social Layer for Your Apps
Summary: How GoToSocial can provide identity, federation, and social features inside existing applications without requiring users to create and manage another account.
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:
- Issuers are ActivityPub actors, so people can follow them.
- Badges and awards are ActivityPub notes, so people can like, boost, share, and comment on them.
- In practice, people can follow issuers and receive their badges through the social web.
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:
- A person signs in to BadgeFed or Community Credentials using an account they already have.
- They enable social features with one setting.
- The system provisions the social account they need.
- 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:
- The application owns its domain-specific interface and workflows.
- The identity provider handles the user's existing sign-in.
- GoToSocial provides ActivityPub federation and Mastodon-compatible APIs.
- Users interact from the application instead of learning a separate social client first.
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:
- Configuring GoToSocial with an external OpenID Connect provider.
- Provisioning or connecting accounts with minimal user action.
- Using the Mastodon-compatible API from an existing application.
- 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.
Also readable in: https://maho.dev/2026/08/using-gotosocial-as-the-social-layer-for-your-apps/ by @mapache:
#GoToSocial #ActivityPub #Fediverse #OpenID Connect #OAuth #Social Web #BadgeFed #FediProfile
-
Hiya friends - so you know how there are whimsical names for groups of animals, such as:
* A murder of crows
* A parliament of owls
* A flamboyance of flamingosWell I just learned that the only term for a group of Mastodons is a "herd." Which is fine, but I bet we can do better... 👀 suggestions in the comments, please!
-
Hiya friends - so you know how there are whimsical names for groups of animals, such as:
* A murder of crows
* A parliament of owls
* A flamboyance of flamingosWell I just learned that the only term for a group of Mastodons is a "herd." Which is fine, but I bet we can do better... 👀 suggestions in the comments, please!
-
We're excited to share the results from Mastodon's first #DiscoveryWeek!
In case you missed it, earlier this year our Head of Design @imanijoy arranged a week of workshops and surveys to get to know you, learn about your needs and wants, and discover how you're using (and want to use) Mastodon.
This week was tremendously helpful for us, and we're grateful to everyone who participated.
Here's what we learned:
https://blog.joinmastodon.org/2026/08/discovery-week-2026-what-we-learned-and-what-were-doing-next/ -
We're excited to share the results from Mastodon's first #DiscoveryWeek!
In case you missed it, earlier this year our Head of Design @imanijoy arranged a week of workshops and surveys to get to know you, learn about your needs and wants, and discover how you're using (and want to use) Mastodon.
This week was tremendously helpful for us, and we're grateful to everyone who participated.
Here's what we learned:
https://blog.joinmastodon.org/2026/08/discovery-week-2026-what-we-learned-and-what-were-doing-next/ -
AFAICT everybody on fedi is either estranged from their conservative family members or wants the fedi to remain small. Usually both.
EDIT: Many just don't want to upset these people.
-
AFAICT everybody on fedi is either estranged from their conservative family members or wants the fedi to remain small. Usually both.
EDIT: Many just don't want to upset these people.
-
Nicht verpassen: Morgen kommt ein neues #SocialMediaBriefing.
➡️ Folgt gern uns (ggf. Glocke aktivieren) oder dem Hashtag. Per E-Mail abonnieren:
👉 https://king-consult.de/social-media-briefing/Themen u. a.:
🔹#FediDay #Berlin @berlinfediday (11. - 13. Sept.)
🔹#SocialMedia-Handlungsrahmen für öffentliche Stellen
🔹Werbewirtschaft
🔹Update von @cathleen zur Open #SocialWeb Alliance #OSWA
🔹🇳🇱 #Behörden fordern mehr dig. Autonomie
🔹Lesetipp: @markus_netzpolitik zu digitaler Abhängigkeit von Anwalts-Kanzleien #Jura #Recht -
Nicht verpassen: Morgen kommt ein neues #SocialMediaBriefing.
➡️ Folgt gern uns (ggf. Glocke aktivieren) oder dem Hashtag. Per E-Mail abonnieren:
👉 https://king-consult.de/social-media-briefing/Themen u. a.:
🔹#FediDay #Berlin @berlinfediday (11. - 13. Sept.)
🔹#SocialMedia-Handlungsrahmen für öffentliche Stellen
🔹Werbewirtschaft
🔹Update von @cathleen zur Open #SocialWeb Alliance #OSWA
🔹🇳🇱 #Behörden fordern mehr dig. Autonomie
🔹Lesetipp: @markus_netzpolitik zu digitaler Abhängigkeit von Anwalts-Kanzleien #Jura #Recht -
So, after having spent a good amount of time actually interacting on Mastodon, I'm starting to identify kind of a structural rift between what we see on corporate social media vs here.
It's not just the profit model or the federation or whatever else (although those are factors that lead to this point). It's that on corporate social media, the system favors the creation of massive spoke hub "creators", which connect to a hell of a lot of users.
That is, there's a small collection of high influence creators. This is as opposed to how the Social Web/fediverse works, in which there's more (percentage-wise) "creator" nodes, but each one has less influence.
Here, take a look at a fancy graphic I made, since I feel like this should be a concept people feel viscerally.
🧵 (1/)
-
So, after having spent a good amount of time actually interacting on Mastodon, I'm starting to identify kind of a structural rift between what we see on corporate social media vs here.
It's not just the profit model or the federation or whatever else (although those are factors that lead to this point). It's that on corporate social media, the system favors the creation of massive spoke hub "creators", which connect to a hell of a lot of users.
That is, there's a small collection of high influence creators. This is as opposed to how the Social Web/fediverse works, in which there's more (percentage-wise) "creator" nodes, but each one has less influence.
Here, take a look at a fancy graphic I made, since I feel like this should be a concept people feel viscerally.
🧵 (1/)
-
In theory you can do anything you want, and in practice people do that too. As long as you don't break anything that #ActivityPub specs prescribe, the #ActivityStreams vocabulary is just a 'toolbox' of #SocialWeb primitives you can use as building blocks in your solution. The only issue arises if you want your mechanism to have #interoperability with other #fediverse solutions. They should either ignore, or understand it, and not break. Writing a #FEP is the best-practice way to walking the path of adoption of your approach.
-
In theory you can do anything you want, and in practice people do that too. As long as you don't break anything that #ActivityPub specs prescribe, the #ActivityStreams vocabulary is just a 'toolbox' of #SocialWeb primitives you can use as building blocks in your solution. The only issue arises if you want your mechanism to have #interoperability with other #fediverse solutions. They should either ignore, or understand it, and not break. Writing a #FEP is the best-practice way to walking the path of adoption of your approach.
-
Been on fedi since April 2017. No Agenda Social.
Was trying to figure out Join Diaspora in June 2011.
Slowly realizing that fixing our information ecosystem would provide the more fair and sustainable improvement in society for most people, rather than doing politics, since maybe 2007.
-
While updating the Mastodon app for Android, its updates are usually in KB or a few MB, but Instagram, Facebook, Threads & X updates are above 100 MB.
Why is that?
If a working social media app like Mastodon or Bluesky with all the necessary features can manage with a few MB for updates, why do other social media apps need so much data for every update?
#Mastodon #Bluesky #Threads #Instagram #X #socialmedia #SocialWeb #Tech #technology #app #coding #dev #AskFedi #IT #programming
#Facebook -
Someday everybody will be on the fedi and having gotten your followers thanks to being given time on mass media or promoted by corporate social media platform algos will have that number marked with an asterisk like the home runs scored during the steroid era.
