One of the central promises of open social media services is interoperability—the idea that wherever you personally decide to post doesn’t require others to be there just to follow what you have to say. Think of it like a radio broadcast: you want to reach people and don't care where they are or what device they're using. For example, in theory, a Bluesky user can follow someone on Mastodon or Threads without having to create a Mastodon or Threads account. But these systems are still a work in progress, and you might need to tweak a few things to get it working correctly.

Right now, broadcasting your message across social platforms can be a funky experience at best, deliberately broken up by oligopolists. The idea of the open web was baked into the internet via protocols like HTML and RSS that made it easy for anyone to visit a website or follow most blogs. The fact social media isn’t similarly open reflects an intentional choice to privatize the internet. 

Bridging and managing your posts so they’re viewable outside a singular source is part of the broader philosophy of POSSE, short for Post Own Site Syndicate Elsewhere (sometimes its Post Own Site, Share Everywhere). Instead of managing several accounts across different services, you post once to one primary site (which might be your personal website, or just one social media account), then set it up so it automatically publishes everywhere else. This way, it doesn’t matter where you or your audience is, and they're not walled off by account registration requirements. 

We’ll come back around to POSSE at the end of this post, but for now, let’s assume you just want your current main open social media account to actually have a chance to reach the most people it can. 

Why Post to the Open Social Web

Because the Fediverse and ATmosphere use different protocols, we need to use a third-party tool so accounts can communicate with each other. For that, we’ll need a bridge. As the name suggests, a bridge can connect one social media account to another, so you can post once and spread your message across several places. This isn’t just some niche concept: major blogging platforms like Wordpress and Ghost integrate posting to the Fediverse.

Bridging is an important facet of POSSE, but also something more people should consider, even if they don’t run their own websites. For example, if you don’t want to create a Threads account just to interact with your one friend who uses that platform, you shouldn’t have to. The good news is, you don’t. There are several bridging services, like Fedisky, RSS Parrot, and pinhole, but Bridgy Fed is currently the simplest to use, so we’ll focus on that. 

How to Post to Bluesky from Mastodon

From your Mastodon account (or other Fediverse account, for simplicity’s sake we’ll stick to Mastodon throughout), search for the username @bsky.brid.gy@bsky.brid.gy and follow that account. Once you do, the account will follow you back and you’ll be bridged and people can find you from their Bluesky account. You should also get a DM with your bridged username. If you don’t see the @bsky.brid.gy@bsky.brid.gy user when you search, your Mastodon instance may be blocking the bridging tool. 

Threads users who have enabled Fediverse sharing will be able to find you with your standard Mastodon username (ie, @your_user_name@mastodon.social), but if they haven’t enabled sharing, they will not be able to see your account. While this search is still a beta feature, you might find it easier to share the full URL, which would look like this: https://www.threads.net/fediverse_profile/@your_user_name@mastodon.social

People on Bluesky can find you by: Either searching for your Mastodon username, or if that doesn’t work, @your_user_name.instance.ap.brid.gy. For example, if your username is @eff@mastodon.social, it would appear as @eff.mastodon.social.ap.brid.gy.

An example of a Mastodon username from the Bluesky web client.

How to Post to Mastodon and Bluesky from Threads

Yes, Threads is technically on the Fediverse, and you can bridge your Threads account to Mastodon or Bluesky (unless you’re in Europe, where the feature is disabled), but it’s a different process than on Bluesky and Mastodon.

• Open Settings > Account > Fediverse Sharing and set the option to “On.” This will make your posts visible to Mastodon (or other Fediverse) users, and vice versa. 
• Once the Fediverse sharing is enabled, you’ll likely need to wait a week, then you can bridge to Bluesky. Search for and follow the @bsky.brid.gy@bsky.brid.gy account (it may take some digging to find it, but if that doesn’t work you can try visiting the profile page directly. 

People on Mastodon (or other Fediverse accounts) and Bluesky can find you by: Mastodon users can find you at, @your_threads_username@threads.net while Bluesky users will find you at, @your_threads_username.threads.net.ap.brid.gy (seriously, that will be the username). Note that some Mastodon instances may block Threads users entirely.

An example of a Threads username from the Mastodon web client.

An example of a Threads username from the Bluesky web client.

How to Post to Mastodon and Threads from Bluesky

From your Bluesky (or other ATProto) account, search for the username, “@ap.brid.gy” and follow that account. Once you do, the account will follow you back and you’ll be bridged, so people can follow you from Mastodon or other Fediverse accounts. You should also get a DM with your bridged username.

People on Mastodon (or other Fediverse account) and Threads can find you by: Your username will appear as @your_bluesky_username@bsky.brid.gy. For example, if your Bluesky username is @eff@bsky.social, it would appear as @eff.bksy.social@bsky.brid.gy.

An example of a Bluesky username from the Mastodon web client.

How to Post Everywhere from Your Own Website

You can bridge more than social media accounts. If you have your own website, you can bridge that too (as long as it supports microformats and webmention, or an Atom or RSS feed. If you have a blog, there’s a good chance you’re already good to go). When you do so, the bridged account will either post the full text (or image) of whatever you post to your personal site, or a link to that content,  depending on how your website is set up. You’ll also probably want to log into your Bridgy user page so you can manage the account. 

Where people can find your bridged account: Usually, a user can just search for your website’s URL on their decentralized social network of choice, or enter it on the Bridgy Fed page. But if that doesn’t work, they can try @yourdomain.com@web.brid.gy from Mastodon or @yourdomain.com.web.brid.gy from Bluesky.

An example of a bridged website username in the Mastodon web client.

How Your Account Username Looks on Each Platform

You’re Bound to Run Into Some Quirks

• Sometimes messages take a little while to crossover between networks, and sometimes they don't crossover at all.
• You can’t log into a bridged account like a regular account, but Bridgy Fed does provide some tools to see incoming notifications and recent activity in case they’re not coming through properly.
• ActivityPub and ATProto don’t have the same feature set, so you will have certain capabilities for one account you might not have in another. For example, you can edit posts on Mastodon, but not on Bluesky. If you edit a post that’s bridged from Mastodon to Bluesky, the Bluesky post will not be updated. 
• Replies can sometimes get lost, especially if the person (or people) replying to you doesn’t have sharing turned on.
• Ownership of accounts can get weird. For example, if you post to your own website and use a tool like Wordpress or Ghost for federation (more info below), you don’t necessarily get access to a “normal” social media account, with a standard login and password.
• And more! This is still a work in progress that has some technical quirks, but it’s improving all the time, and it’s best to keep telling yourself that troubleshooting is part of the fun.

Other Cool Stuff You Can Do

As mentioned up top, there’s a lot more you can do, and an increasing number of tools are making this process simpler. Bridgy Fed is one way to post to more places from a single account, but it’s far from the only way to do so. Here are just a few examples.

• Micro.blog is a paid service where you can blog from your own domain name, then post automatically to Mastodon, Bluesky, Threads, Tumblr, Nostr, LinkedIn, Medium, Pixelfed, and Flickr.
• Ghost is a blogging and newsletter platform that offers direct integration with the Fediverse, as well as support for Bluesky. Wordpress offers the option to join the Fediverse through a community plugin. Other newsletter platforms, like Buttondown, also have plans for federation. 
• Surf.social is a landing page and social media utility where you can show off all your various accounts (Federated or not). From the reader point of view, you can follow one publications numerous types of posts in one place. For example, 404 Media’s Surf.social feed includes its YouTube feed, podcast feed, and its journalist’s social media posts.
• If you think these new handles are a bit ugly, you can use a custom domain for Bluesky or fediverse account from your website. 

Of course, there are plenty of other tools, blogging platforms, and other utilities out there to help facilitate posting and bridging accounts, with new ones coming along every day. 

With proper support, time, and effort, eventually we will all be able to seamlessly interact across platforms, take our follows and followers to other services when a platform no longer suits our needs, and interact with a variety of web content regardless of what platform hosts it. Until then, we still need to do some DIY work, support the services we want to succeed, and push for more platforms and services to support federated protocols.

Correction: an earlier version of this blog was missing the full Bluesky username in the account username chart.

If you want to overthrow Big Tech, you’ll need Section 230. The paradigm shift being built with the Open Social Web can put communities back in control of social media infrastructure, and finally end our dependency on enshitified corporate giants. But while these incumbents can overcome multimillion-dollar lawsuits, the small host revolution could be picked off one by one without the protections offered by 230.

The internet as we know it is built on Section 230, a law from the 90s that generally says internet users are legally responsible for their own speech — not the services hosting their speech. The purpose of 230 was to enable diverse forums for speech online, which defined the early internet. These scattered online communities have since been largely captured by a handful of multi-billion dollar companies that found profit in controlling your voice online. While critics are rightly concerned about this new corporate influence and surveillance, some look to diminishing Section 230 as the nuclear option to regain control. 

The thing is, that would be a huge gift to Big Tech, and detrimental to our best shot at actually undermining corporate and state control of speech online. 

Dethroning Big Tech

We’re fed up with legacy social media trapping us in walled gardens, where the world's biggest companies like Google and Meta call the shots. Our communities, and our voices, are being held hostage as billionaires’ platforms surveil, betray, and censor us. We’re not alone in this frustration, and fortunately, people are collaborating globally to build another way forward: the Open Social Web. 

This new infrastructure puts the public’s interest first by reclaiming the principles of interoperability and decentralization from the early internet. In short, it puts protocols over platforms and lets people own their connections with others. Whether you choose a Fediverse app like Mastodon or an ATmosphere app like Bluesky, your audience and community stay within reach. It’s a vision of social media akin to our lives offline: you decide who to be in touch with and how, and no central authority can threaten to snuff out those connections. It’s social media for humans, not advertisers and authoritarians.

Behind that vision is a beautiful mess of protocols bringing open social media to life. Each protocol is a unique language for applications, determining how and where messages are sent. While this means there is great variety to these projects, it also means everyone who spins up a server, develops an app, or otherwise hosts others’ speech has skin in the game when it comes to defending Section 230.

What exactly is Section 230?

Section 230 protects freedom of expression online by protecting US intermediaries that make the internet work. Passed in 1996 to preserve new bubbling communities online, 230 enshrined important protections for free expression and the ability to block or filter speech you don’t want on your site. One portion is credited as the “26 words that created the internet”:

“No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider.” 

In other words, this bipartisan law recognizes that speech online relies on intermediaries — services that deliver messages between users — and holding them potentially liable for any message they deliver would only stifle that speech. Intuitively, when harmful speech occurs, the speaker should be the one held accountable. The effect is that most civil suits against users and services based on others' speech can quickly be dismissed, avoiding the most expensive parts of civil litigation. 

Section 230 was never a license to host anything online, however. It does not protect companies that create illegal or harmful content. Nor does Section 230 protect companies from intellectual property claims. 

What Section 230 has enabled is the freedom and flexibility for online communities to self-organize. Without the specter of one bad actor exposing the host(s) to serious legal threats, intermediaries can moderate how they see fit or even defer to volunteers within these communities.

Why the Open Social Web Needs Section 230

The superpower of decentralized systems like the Fediverse is the ability for thousands of small hosts to each shoulder some of the burdens of hosting. No single site can assert itself as a necessary intermediary for everyone; instead, all must collaborate to ensure messages reach the intended audience. The result is something superior to any one design or mandate. It is an ecosystem that is greater than the sum of its parts, resilient to disruptions, and enables free experimentation with different approaches to community governance.

The open social web’s kryptonite though, is the liability participants can face as intermediaries. A greater potential for liability comes with more interference from powerful interests in the form of legal threats, more monetary costs, and less space for nuance in moderation. And in practice, participants may simply stop hosting to avoid those risks. The end result is only the biggest and most resourced options can survive.

This isn’t just about the hosts in the Open Social Web, like Mastodon instances or Bluesky PDSes. In the U.S., Section 230’s protections extend to internet users when they distribute another person’s speech. For example, Section 230 protects a user who forwards an email with a defamatory statement. On the open social web, that means when you pass along a message to others through sharing, boosting, and quoting, you’re not liable for the other user’s speech. The alternative would be a web where one misclick could open you up to a defamation lawsuit.

Section 230 also applies to the infrastructure stack, too, like Internet service providers, content delivery networks, and domain or hosting providers. Protections even extend to the new experimental infrastructures of decentralized mesh networks.

Beyond the existential risks to the feasibility of indie decentralized projects in the United States, weakening 230 protections would also make services worse. Being able to customize your social media experience from highly-curated to totally laissez-faire in the open social web is only possible when the law allows space for private experiments in moderation approaches. The algorithmically driven firehose forced on users by antiquated social media giants is driven by the financial interests of advertisers, and would only be more tightly controlled in a post-230 world.

Defending 230

Laws aimed at changing 230 protections put decentralized projects like the open social web in a uniquely precarious position. That is why we urge lawmakers to take careful consideration of these impacts. It is also why the proponents and builders of a better web must be vigilant defenders of the legal tools that make their work possible. 

The open social web embodies what we are protecting with Section 230. It’s our best chance at building a truly democratic public interest internet, where communities are in control.

People building the future of the social web — interoperable and decentralized — need to protect themselves against copyright liability. Like anyone who creates and operates platforms for user-uploaded content, the hosts of the decentralized social web can take preventive measures to reduce their legal exposure when a user posts material that violates someone’s copyright.

This post gives an overview of the steps to take. It’s meant for operators of Mastodon and other ActivityPub servers, Bluesky hosts, RSS mirrors, and other decentralized social media protocols, and developers of apps for those protocols — but it will apply to other hosts as well. This isn’t legal advice, and can’t substitute for a consultation with a lawyer about your specific circumstances. It focuses on U.S. law — the law may impose different requirements elsewhere. Still, we hope it helps you get started with confidence.

Why should I care? Copyright’s Sword of Damocles

In some circumstances, the operator of a platform that handles user content can be legally responsible for content that infringes copyright. That can happen when the platform operator is directly involved in copying or distributing the copyrighted material, when they promote or knowingly assist the infringement, or when they benefit financially from infringement while being in a position to supervise it. But these judge-made rules are often difficult and uncertain to apply in practice — and the penalties for being found on the wrong side of the law can be severe. Copyright’s “statutory damages” regime allows for massive, unpredictable financial liability. That’s why it’s important to limit your risk.

For Server Operators: Limiting Risk with the DMCA Safe Harbors

If you run a social network server, the safe harbor provisions of the Digital Millennium Copyright Act (DMCA) are an important way to limit your liability risk. The DMCA shields server operators from nearly all forms of copyright liability that can result from “storage at the direction of a user” — in other words, hosting user-uploaded content. But to qualify for this protection, there are steps a server operator has to take.

1. Designate A Contact To Receive Copyright Infringement Notices

First, you’ll need to provide contact information for someone who can receive infringement notices (a “designated agent”). That information needs to be posted in at least two places: on your server in a place visible to users (such as a “DMCA” page or post, or as part of your Terms of Service), and in the U.S. Copyright Office’s “Designated Agent Directory.” To post that information to the directory, you have to create an account at https://www.copyright.gov/dmca-directory/ and pay a small fee. The directory listings expire after three years, and once expired, your safe harbor protection goes away, so it’s important to keep that listing current.

2. Respond Promptly to Notices and Counter-notices

When you receive infringement notices, it’s important to respond to them promptly. Notices are supposed to identify the copyright holder, the copyrighted work they claim was infringed, and the post they claim is infringing. By deleting or disabling access to the posted material, you protect yourself from liability with respect to that material.

The theory behind Section 512 is that hosts don’t have to be in a position of deciding whether a post infringes someone’s copyright — it’s up to the poster, the rights holder, and potentially a court to decide that. A host who takes down posts whenever they receive an infringement notice is well-protected. But it’s equally important to recognize that hosts aren’t required to take down content in response to every notice. Infringement notices are frequently wrong, misguided, or abusive, or simply incomplete. Hosts who want to stand up for their users’ speech can choose to disregard infringement notices that seem suspect. While this risks losing the automatic protection of the safe harbor in each instance, it can still be done safely with careful preparation, ideally using a plan crafted with help from a lawyer. Bear in mind that people sending false notices, including by failing to consider whether a post is a fair use before asking a host to take it down, can be liable for damages under the DMCA.

The DMCA also allows the person who posted the material to send a “counter-notification” asserting that they really did have the right to post and that there’s no copyright infringement. Responding to counter-notifications is a good way for a host to demonstrate that they look out for their users. When a host receives a counter-notification, they should forward it on to the person who sent the original takedown notice and let them know that the post will be restored in 10 business days. Then, after that waiting period has elapsed, the host can restore the posted material. Just like with infringement notices, a host isn’t required to honor a counter-notification that appears to be fraudulent, but there’s no penalty for honoring it anyway.

3. Have A Repeat Infringer Policy

The next requirement is to have a policy of terminating the accounts of “subscribers and account holders” who are “repeat infringers” in “appropriate circumstances,” and to carry out that policy. Yes, that’s a vague requirement. It doesn’t require a “three strikes” policy or any other sports analogy. It just needs to be reasonable. Be sure your policy is spelled out in your website terms or “DMCA” page.

4. Don’t Ignore Known Infringement

Hosts need to take down user posts whenever the host actually knows that the post is infringing. In other words, a host isn’t protected if they ignore takedown notices based on technicalities in the notices, or if they learn about the infringement some other way. But hosts don’t need to actively look for infringement on their servers — only to act when someone notifies them.

5. Don’t Encourage Infringement

Finally, make sure that nothing you post or advertise actively encourages copyright infringement. For example, don’t post examples of users uploading copyrighted music or video without permission, or insinuate that your server is a good place for infringing content.

There are some other technicalities in the DMCA that can affect the safe harbor, which is why it’s always a good idea to consult with a lawyer. But following these steps will help protect you when you run a social media server — or any other kind of user-uploaded content platform.