Hi! I’m Ryan. I’ve been building social network bridges and related tools for over 12 years, including Bridgy, which connects personal web sites and blogs to centralized social networks, and Bridgy Fed, which connects them to the fediverse.
I love how decentralized social networks like the fediverse and the IndieWeb let us move away from walled gardens controlled by single monolithic entities. I love that we can control our own destinies online, nurture and grow our own communities and instances, and still interact with people elsewhere. I want to be able to interact across networks just like we interact across servers. That’s why I build bridges!
Recently, I’ve been working on adding new protocols to Bridgy Fed, starting with Bluesky. It’s still months away from launching, but I expect it will draw in people who aren’t familiar with Bridgy Fed yet, and I know it will affect people in obvious and not-so-obvious ways, so I want to start a conversation. What do you think? How do you hope this will work? What are your concerns? What feedback do you have, especially now while big changes may be easier to make? I’ve talked with a number of fediverse admins and representatives so far, but I want to hear from you too.
Here’s some information about Bridgy Fed:
- I build and run it myself, with occasional contributors and lots of support, but still mostly alone. It’s open source.
- I don’t plan to incorporate or monetize in any way. No donations, no paid tiers, no VC funding. I’ve self-funded Bridgy classic for 12 years and Bridgy Fed for 6 years so far, and I can continue indefinitely. I have experience scaling services like these as personal projects. I care about and believe in decentralized social networks, and I build and pay for these tools as a way to give back.
- The bridge is fully bidirectional. Anyone on supported network A can follow anyone else on supported network B, see their posts, and reply, like, and repost them. Bridgy Fed translates interactions from A to B, and vice versa.
- The two currently supported networks are the fediverse and the IndieWeb, specifically HTML with microformats2 and webmentions.
- Bluesky support is under development, but hasn’t launched yet. Bluesky themselves need to enable federation first, and I have more work to do too.
- All native moderation features will work automatically: blocking, muting, server level blocking/defederating, etc. This includes the fediverse’s authorized fetch aka secure mode, which Bridgy Fed supports: it always includes valid HTTP Signatures when fetching actors and other objects. (There’s a lot more to think about around content moderation too!)
- Bridgy Fed doesn’t index anything and has no search functionality. You can only follow someone on a different network by entering their exact Bridgy Fed handle.
- Bridgy Fed will use a discoverable opt in mechanism: when someone first requests to follow or interact you across the bridge, it will send you a one-time-only DM to ask if you want to enable it. You’ll only be bridged if you say yes.
- Accounts and posts are not bridged proactively. A user on network A is only bridged into network B if someone on network B follows them.
- Here’s how handles and ids are translated across networks.
- Bridges are never quite as good as native accounts. Feature parity between networks is incomplete, culture and norms differ, context collapses, etc. I don’t expect to ever make the bridged experience as good as native, I just hope to make it possible.
- I know some admins may determine that this kind of bridge isn’t in their users’ best interests and choose to defederate/block it. That’s their prerogative. I hope to be open minded, hear where they’re coming from, and see if I can make any changes that might allay their concerns. I don’t always expect to change everyone’s mind, but I do plan to honor and abide by admins’ decisions on behalf of their users.
- I’m familiar with many of the existing bridge/cross-posting efforts, eg mostr.pub, Sasquatch, and SkyBridge. They’re great! They rarely reach this level of functionality though, specifically bridging any existing account to any other supported network.