Why My WordPress?

https://alex.kirk.at/2026/04/14/why-my-wordpress/

Friends 4.0

It has been baking for much longer than I wanted, but today I released the next major version of my Friends Plugin for WordPress.

Focusing on ActivityPub

The biggest change is a deviation from the original idea: Friendships between WordPresses have been removed. With ActivityPub (when the respective ActivityPub plugin is installed, too) we have a communication protocol that is supported by many more platforms than just other WordPresses that also happen to have installed the Friends plugin.

Removing friendship functionality reduces a lot of complexity in the plugin that changed some fundamentals of WordPress. The friendship functionality had been deactivated for a while behind a checkbox.

This means that the Friends plugin now focusses on functionality of subscribing to feeds (be it RSS, Atom or ActivityPub) and integrating outward communication via ActivityPub (direct messages, replies).

Themes

To make the consuming more attractive, I have worked on providing more integrated themes. I had added the ability to contribute themes already some time ago, thanks for the FediPress theme contribution! Being more a developer than a designer, my default Friends theme has been deemed more functional than pretty (from what I heard).

So, the new themes are:

A Block Theme, which allows you to modify the Friends page using the Site Editor and gives it the design of your own site’s theme.

A Google Reader Theme makes it look like Google Reader. This comes with keyboard shortcuts and the accordion-like behavior of the posts.

I had already done a prototype of a Mastodon Theme and have now added a functional one that is shipped by default.

All the themes now support light and dark mode (which makes the Mastodon theme look a bit unusual in light mode).

I hope that the screenshots above highlight the versatility of the plugin and how much the visual appearance can shape the perception.

Migrations

A big reason for the 4.0 version number was the number of migrations of internal data structures towards more taxonomies (the Friends plugin did not and does not use custom tables). This removes the last bits of supporting WordPress users as friend users and adds proper term relationships between friends and subscriptions. This also allowed to add support for folders.

But it makes a transition from an earlier version potentially a bit tricky. With this amount of changes and migrations, I opted to make it easier to discover what’s new and what is already migrated. I hope that all migrations go smoothly but if they don’t, this gives you insight into where things might be stuck.

The amount of necessary fundamental changes and migrations made this release somewhat risky and was a reason for the long time since the last release. I am hoping that with these changes now shipped, I can provide more frequent updates again!

Oh, I also shipped a new version of the Enable Mastodon Apps plugin (1.5.0) which makes use of some of the taxonomy changes in Friends that now allow to distinguish between mentions and direct messages, and there should be a speed-up in many endpoints, especially the notifications endpoint.

Enjoy this new release, which I hope will make it easier and more feasible to use Your WordPress as Your Personal Mastodon Instance.

Introducing tags.pub

https://socialwebfoundation.org/2026/03/17/introducing-tags-pub/

Connecting Decentralized Social Networks and Rethinking Interoperability

Download file | Play in new window | Duration: 00:58:07

In this episode, host Matthias Pfefferle catches up with long-time friend and open web builder Ryan Barrett. If you’ve ever wondered who’s behind the scenes connecting all these wild and sprawling decentralized networks like the IndieWeb, the Fediverse, and now Bluesky, well, Ryan Barrett is your guy.

They share into the story of Bridgy and BridgyFed, tools Ryan Barrett built to help posts, conversations, and even likes travel effortlessly between platforms that, let’s be honest, don’t always want to talk to each other. It’s a real look at why we still need these kinds of bridges, the ups and downs of working in open source, and what it’s like turning a side project into something that lots of people rely on.

You’ll get a peek into the early days of blogging, the messy but fun world of protocol building, and some of the tough questions that come with running “critical infrastructure” without a big company behind you. Whether you love the nerdy details or just want to know why your favorite blog can show up in the social media feed of tomorrow, this conversation is all about keeping the web open and a bit of the chaos that comes with it.

Join Matthias and Ryan for a chat that proves building bridges, both tech and personal, is still as important (and fun) as ever.

Thanks to our sponsors…

The best time to migrate is before you’re under pressure. Omnisend moves everything essential for you now, so you’re fully ready when you plan for that large campaign. Use the code OpenChannels and get 30% off your first 3 months of any paid plan.

If you build stores for clients, WooCommerce gives you the flexibility to create exactly what merchants need. Customize workflows, extend with thousands of integrations, and scale without switching platforms. Check it out at WooCommerce.com.

https://youtu.be/Ls3Jb8Zjijg

Takeaways

• Bridging Decentralized Networks: Ryan Barrett has spent years building tools (most notably Bridgy and BridgyFed) that connect different social networks like the IndieWeb, Fediverse, and Bluesky (Atmosphere). These act as cross-posters or bi-directional bridges, letting users interact across platforms more seamlessly.

• Funding and Organization: Initially, all this was a side project for Ryan Barrett, but it has evolved. They’ve started a nonprofit, received some grant and crowdfunding, and put basic governance in place; though it doesn’t currently provide a full salary, it does cover operational expenses.

• Why Bridges Are Needed: Despite the vision of decentralized networks, true interoperability doesn’t exist by default. Instead of expecting everyone to align on a single protocol, Ryan Barrett argues that we’re still learning and evolving, so bridges are necessary while experimentation continues.

• Not Just a Temporary Fix: Bridges aren’t just a stopgap; as protocols and ideas keep changing, the need for interoperability will persist. Ryan Barrett believes that even with established protocols like ActivityPub or AT Protocol, new experiments and networks are inevitable.

• Personal Motivation: The roots of these tools trace back to Ryan Barrett’s desire to maintain ownership of his content and the social interactions around his blog, especially as conversations moved onto walled garden platforms like Facebook and Twitter.

• Evolution of Open Web Tools: Early efforts included cross-posting content, but Ryan Barrett emphasized “backfeed” such as importing comments, likes, and reactions from social platforms back to his own website, so all engagement was aggregated in one place.

• Preference for Usable, Practical Solutions: Rather than inventing radically new standards, Ryan Barrett prefers building bridges and services that work with what’s already out there, favoring RSS, Webmention, and existing APIs, so end users don’t need to host their own solutions.

• Protocols: No Single Winner: Discussing IndieWeb, ActivityPub, AT Protocol, and others, Ryan Barrett sees good ideas in each but doesn’t believe there’s a “best” protocol yet. He values building blocks, modularity, and combining approaches, rather than betting on one framework.

• End-User and Publisher Focus: Most usage of BridgyFed comes from publishers and content creators (e.g., major media), but individuals also use bridges, especially those who want to maintain a single profile and reach across networks without friction.

• Invisible Interoperability: Often, users don’t even realize they’re talking across different networks using BridgyFed; they see and interact with others seamlessly, which is the ideal scenario for Ryan Barrett.

• Critical Infrastructure Concerns: With adoption rising, BridgyFed has become important infrastructure. To ensure long-term reliability, they’ve made it open source, started a nonprofit, and instituted governance. There are plans to make it more resilient and less dependent on a single operator.

• Looking Forward: Major focus areas for the future include supporting long-form content (via standards like standard.site), expanding migrations and account portability, and readying bridges for new protocols like Nostr and Farcaster.

• Philosophy of the IndieWeb: The IndieWeb is described as both a philosophy (“everyone should have a website and control their own profile”) and a protocol stack (Webmention, microformats, etc.), but it’s fundamentally about individual ownership and choice in the online experience.

• The Web Isn’t Going Away: There will always be vastly more websites than social network accounts. Even as trends shift more towards platform accounts, the open web remains a massive, foundational part of online life and bridges can help keep it connected to emerging networks.

Mentioned Links and Resources

• Bridgy & BridgyFed – A suite of tools for bridging between the IndieWeb, Fediverse, and Bluesky/Atmosphere. 🔗 https://brid.gy/
• ANEW Social – The nonprofit organization behind BridgyFed. 🔗 https://anew.social/
• Granary – A tool and service to convert between web formats like RSS and microformats. 🔗 https://granary.io/
• Standard.site – A common lexicon/format for long-form content on Bluesky and other AT Protocol platforms (mentioned as “standard.site” for composing and sharing articles). 🔗 https://standard.site/
• snarfed.org – Ryan Barrett’s website, personal blog, and IndieWeb hub. 🔗 https://snarfed.org/
• Fed.brid.gy – The main instance of BridgyFed bridging service. 🔗 https://fed.brid.gy/
• IndieWeb – Community, resources, and documentation about owning and controlling your content and identity online. 🔗 https://indieweb.org/
• Bounce – A tool to help you migrate from one network to another and keep all of your followers (powered by BridgyFed). 🔗 https://bounce.anew.social/

Timestamped Overview

• 00:00 Between Gigs Crowdfunding Nonprofit
• 05:14 Early Protocol Evolution Debate
• 10:11 Blogging Era and Social Media
• 12:11 Backfeeding Social Interactions
• 16:20 Early Web Standards Collaboration
• 19:26 Graph API and Decentralization Challenges
• 22:43 Struggling with Protocol Implementation
• 25:12 Engineering Formats as Lego Blocks
• 30:46 Usability and account recoverability
• 33:36 Decentralized Social Functional Separation
• 37:27 Decentralized Communication via Open Standards
• 39:34 Building for the Present Web
• 45:08 BridgyFed: Connecting Diverse Platforms
• 47:04 Transforming a Side Project
• 51:05 Custom Domains for Bridged Accounts
• 54:23 Network Migration and Bounce Tool
• 56:58 Indie Web Collaboration Reflections

Matthias Pfefferle:
So welcome, you’re listening to the Open Web and Fediverse series, part of the Open Web Conversations channel and Open Channels event production. And today’s guest is building infrastructure that bridges together what should be interoperable by default. He’s literally building bridges between the indie web, the Fediverse, and the atmosphere. I hope it’s called like that for almost 15 years now. Welcome to the podcast, Ryan Barrett.

Ryan Barrett:
Thank you, Matthias. I’m glad to be here.

Matthias Pfefferle:
I think my introduction was almost perfect, but Maybe you want to add something?

Ryan Barrett:
Yeah, no, I, you and I go back so long. We’ve been doing indie web stuff together for at least 15 years. And so it’s, I’m excited to be here. It’s, it’s really fun to get to talk to you about kind of everything that led us to where we are now.

Matthias Pfefferle:
Yeah, but maybe you say some words about what I teased a bit with. You are the bridge builder.

Ryan Barrett:
Yes. Yeah. So who am I? Yes. So I’m, you know, a stereotypical Silicon Valley software engineer. It’s been my day job. But on the side for a long time, I have— I’ve done indie web stuff and somehow I ended up doing a lot of converters and bridges and translators. Going from one place to another. Uh, so yeah, the— what I’m known for and what I spend most of my time on today is, um, a suite of tools, uh, Bridgy and BridgyFed. We now, we now call them maybe BridgyClassic and BridgyFed. Um, these, uh, are kind of like cross-posters or bridges between different networks, uh, as you mentioned. So the web IndieWeb in particular, the Fediverse, and Bluesky, or the Atmosphere as you called it. And so BridgyFed is where I spend most of my time these days, and it is a full-featured bi-directional bridge. So if you are on Bluesky, you can see people who have bridged themselves on the Fediverse. You can see their profile, their timeline, you can follow them. If they post, you’ll see their posts on Bluesky. You can reply to them on Bluesky. The replies and likes and reposts will go back and forth. And so we try to make that as native and seamless as possible. And it takes a lot of work, but it’s fun.

Matthias Pfefferle:
Yeah, because of a lot of work, you mentioned that you do that as a side hustle. Is that still a side hustle thing?

Ryan Barrett:
Uh, right now I’m between gigs, so I’m mostly full-time on it. Uh, eventually I’ll go find a real job again, but, um, uh, right now I have more time for it. Uh, thanks in large part, uh, about a year and a half ago maybe I started working with Anuj Ahuja, who comes from working on similar stuff, and we have, um, I resisted kind of taking donations for a long time, but we now do crowdfunding and, uh, grant funding, and we, we started nonprofit. And so there is a bit more of kind of real organization and governance and some funding behind it. We don’t have enough funding to kind of pay ourselves salaries yet, but we can cover expenses and things like that.

Matthias Pfefferle:
Is it a plan to do that as a main profession anytime soon?

Ryan Barrett:
I don’t know. I’ve never been much for like a 5-year plan or a 10-year plan for myself. I just do what I’m doing while it works. And then when it’s time to do something else, I do something else. Um, I have never quite felt like this is my career. Um, so, but I’m doing it mostly full-time now. We’ll see how it goes. And I mean, even if I go get a different job and do something else,, you know, as a day job, like I wouldn’t shut this down. Um, it’s more a question of like, how much time am I spending building new parts of it and maintaining it as opposed to just kind of running it as is.

Matthias Pfefferle:
I think that’s the main problem for everyone working in open source and decentralized platforms in general, I would say. Um, yeah, but As I said in the introduction, it’s kind of weird that you need something like a bridge to bridge decentralized networks together. So why all of that?

Ryan Barrett:
Yeah, there is one way of thinking about this that is kind of like we want everyone, you know, all the different software projects to use the same protocol so that they can interoperate. Of course, I get that. Another way of thinking about it is we are still so early to all of this. It’s— yes, it’s been decades, but decades is not that long. I think if we said, okay, have we figured out all of the questions and we know the best way to do all of this, we’re doing it in maybe an activity pub. ActivityPub got everything right, no more questions to answer, like no more problems, so there’s no need to try anything new. Like ActivityPub is it, or, or Atmos protocol or anything else. That’s the final answer forever. Like, I don’t think anyone would believe that, right? Like, I think we are so early and there’s so much more to learn and figure out and, uh, kind of invent, we have to try a bunch of new things. ActivityPub is great. App Protocol is great. IndieWeb is great. I like Nostr. I like Farcaster. There are a bunch of good ideas, but we have like, yeah, there’s just so much more to figure out. And often like you can’t slowly evolve an existing network or protocol to try some big new idea. Uh, often if you have a big new idea that’s very different, it’s just too far away. And so you can’t like very gradually, inch by inch, move this one over there. You have to just try a new thing. And so I think trying new things is great. Uh, I think right now is the time to try lots of different ways to do decentralized social, right? But while we do that, we’ll have lots of different networks that don’t talk. Right. And so I like having things talk. And so I think bridges are useful.

Matthias Pfefferle:
So is that still a temporary thing for you?

Ryan Barrett:
Or, uh, probably not. I mean, so if the question is like, will we try things and then we’ll find the best way and everyone will use the one best way and then we’re done. No, I don’t think so. I think change is the only constant. I think we are always improving things. Um, Email is a great example. You could say, yeah, we tried a few different ways for people to kind of talk asynchronously online many, many decades ago. We settled on email. That’s great. But now if you think about how do you talk to your friends online, it’s mostly not on email, right? It’s on messaging or social or other things. And so we didn’t really have— even when we settled on email, like later, it’s not that SMS competed with email, but it was a new idea, right? And so I think there will always be new ideas, and that’s good.

Matthias Pfefferle:
So you said, or you already mentioned, that it’s nearly since forever, um, you are working on that. I think it’s almost 15 years. So, um, What led to a bridge? What is the history about all of that? Why have you decided to, okay, there are so many, like the XKCD comic, there’s so many competing standards, let’s build a bridge?

Ryan Barrett:
Right, right. Yeah, so the short answer is kind of the open source scratching my own itch. So way back in maybe 2000, I was in college. I had a website, a little— I didn’t— no one knew to call it a blog, but a website or a blog. Okay, good. When Facebook came out maybe a year or two later, at least very early in college for colleges, I signed up and tried it and I thought, oh, this is interesting. And I kind of immediately realize, oh, this is good and useful, but it’s not mine. I don’t control it. Like, I can, I can make my profile and post, but at the end of the day, if they want to change how things look or they don’t like me and want to, you know, ban my account or something, like, I— they can do that. I can’t control it. And so it’s okay. I mean, that’s like any service. But what I ended up doing was I would, when I posted, I would always just post on my website and then I would just copy and paste into Facebook. Then I knew at least anything I write there, like I’ll still have a copy of, I’ll still control. Okay. That is fine. Like as other services come out like Twitter or whatever, I would, I did the same thing. Gradually. So there was this era, you remember this, I mean, you and I have been doing indie web stuff together forever. The blogging era, this was the early to mid, maybe 2000s. There was an era where lots of people wrote blogs and would kind of respond to each other’s blog posts on their blogs and comment on those blog posts. And that’s great. Everyone had their own website and did that and it worked well. When social media kind of got bigger, one thing we would do is we would write blog posts and then post links to our posts on Facebook, Twitter, et cetera.

Matthias Pfefferle:
The famous cross-posting.

Ryan Barrett:
Yeah. Yeah. Yeah. Okay, sure. Gradually what we saw was that more and more people spent more time inside these social networks as opposed to reading kind of on the blogs. And so when I would post a link to a blog post I wrote, something I wrote, more and more people would comment kind of on Facebook or on Twitter or wherever instead of on my blog post on my website. Okay. The downside there is I don’t have— I’ve been like that conversation like about what I’m talking about. Is on Facebook or is on Twitter. Like, I don’t keep a copy of it, I don’t have a record of it, right? Um, you know, so that, that was a change that was disappointing. And so cross-posting was one thing. There were tons— there were always tons of tools to say, oh, post to Facebook and Twitter and Instagram and whatever. Like, that’s pretty easy. So lots of people did that, that’s useful. But what I wanted was the comments or the replies on Twitter. And then eventually the likes and the reposts and the quotes and everything, I wanted those to show up on my website too. And other people had thought of this, and you know, it was, it was a good idea, but it was much— it was more complicated to build, and so not many people did it. This is what we call in the indie web backfeed. And of course, the indie— at this time I had also kind of discovered the indie web, or was discovering at this time, and it was doing— had similar ideas kind of between websites themselves without worrying about social networks. But so what I eventually built was this tool to go use the Twitter API, use the Facebook API, etc., to find all of those replies and likes and reposts and figure out and kind of map from my original post there to the, my blog post and copy them all back to my blog post so they would show up there and other people would see them there.

Matthias Pfefferle:
So the first version, the first bridge was to bridge your blog content to, let’s say, closed social network and get the reactions out of it.

Ryan Barrett:
Yes. And especially, I mean, primarily the backfeed. So at the beginning, I didn’t do the cross-posting. I just I’m not— I’ve never been very online. I don’t post a ton. I post once every few days. Copy and paste is fine for me. But the back feed was the key part. And originally this was either 2000— I need to check the— maybe January 2012. The first version I did of this was WordPress specific. It was not Webmention. It was not kind of this open standard, this indie web standard. It was WordPress specific and it did, I think, Facebook and Twitter and that was it. And it was probably only replies or comments, but it was something, you know, and it kind of grew from there.

Matthias Pfefferle:
But it was as a service, it was not directly baked into WordPress. So is there a specific or was there a specific decision to do it like that or is this something that made the most sense?

Ryan Barrett:
So, I always knew this— all this should work as kind of open standards. Open standards. I wanted it to be interoperable. I didn’t want it to be specific— as much as I love WordPress, I didn’t want it to be specific to WordPress or anything else, right? And so, the standards I knew originally at that time were— the standard I knew for this was OStatus around then. And so my, my long-term idea was to build an OStatus bridge for all of, for the closed social networks. So that since, so the, I mean, the, the big idea here is they, they were closed, but they all had APIs. And so you can, like, there’s OStatus, there’s this open standard, and then there are these APIs. And the APIs were pretty full-featured. And so I figured like I have these two Lego blocks, I can just kind of use the API and translate the OStatus and back. And that should, that should work.

Matthias Pfefferle:
So one of the earlier versions were even compatible between OStatus, the open, let’s say predecessor of the Fediverse activity pub. And Facebook and Twitter?

Ryan Barrett:
So I never got— I never fully implemented OStatus for Facebook and Twitter. The first version of BridgyFed was OStatus. It was IndieWeb to and from OStatus. Before I did ActivityPub there. That was 2017. So BridgyFed was a different— a similar but different service, yes. But I did a number of these. So I did implement WebFinger for Facebook, Twitter, et cetera. I did portable contacts. POCO was a similar standard. Yeah, this is like us going back to 2010 era. What were the— and I did OpenID for Facebook and Twitter. So there were parts there, uh, and also, I mean, a lot of this was just around, it was in the air, and I happened to know a number of the people working on these standards, um, Evan, but also people like Brad Fitzpatrick, Brett Slatkin, uh, David Recordon. We all, you know, talked now and then. And so this was Chris, yeah, um, this was OStatus, but also kind of Buzz at Google and let’s see, Brad was doing things like the Social Graph Explorer API at Google and there were a lot of similar ideas. As a separate side project, I had written a little app that used— that did OpenID for Google accounts. Like any Gmail account, that kind of thing. There were a lot of these ideas. This was the, like, that blog era, 2000 to 2010, was also very much the Web 2.0 mashup era, Yahoo Pipes kind of thing. And also people at the same time thinking about Webfinger, OpenID, OStatus, these early, early decentralized social, decentralized services. And so there were lots of people and lots of ideas. Can I plug this into that? Like there are a bunch of parts. Let’s just plug them all together and see what works.

Matthias Pfefferle:
Yeah. Ostatus itself felt very mesh-appy. So putting together a lot of open standards and all the decentralized protocol. So when you worked on all of that, have you had the hope that it might get implemented? In the social networks? Because back in the days, Facebook and Twitter were really part of the discussions, not around maybe old status specifically, but there were other projects like data portability, for example, where they were really involved into that discussion. Was that kind of the hope you had?

Ryan Barrett:
No. Okay. Facebook very concretely for a while did a number of these things that had RSS. You know, it— I’m trying to remember if it did OpenID.

Matthias Pfefferle:
They did. They did OpenID. They had XMPP as the foundation of their Facebook chat. So they used quite a lot of open standards. I think they even used microformats for their profiles. It was, they were quite open to that.

Ryan Barrett:
And then also the things they created. So the graph API for a while, they very much positioned it as this kind of open generic thing that other people could use. And so this was the era of, again, David Recordon was there for a while and other people. I think the culture there. Was very much engineering driven and kind of just scrappy hackers, um, just throw a bunch of stuff together and engineers like standards. And so yeah, there was a while where they were very open to this stuff, which was great. Twitter, not so much. I think Twitter, you look at what Jack Dorsey was saying back then and recently, but, um, he had big, big ideas and vision for protocols and decentralization, but It never felt like that translated into anything concrete that they shipped. Facebook was very different. They shipped a ton of it. It didn’t last forever. But one thing when I think about the things I build, I very rarely like want to tackle an adoption problem. Like if you make a new protocol, like you can do it all right, you know, and make all the right choices or whatever, but you have to get everyone to use your new protocol or your new tool. That’s very slow and difficult. I would much rather, yeah, I’d much rather build something that people can use as is, especially developers, without having to, without a big adoption challenge. I think that’s another reason I tend to build these things as services. I want individual users to be able to use these things as easily as possible. I don’t want them to have to self-host anything. I don’t want them to have to get their Mastodon or Friendica or Pleroma or whatever to add a new feature. And so, yeah, I tend to avoid kind of adoption problems. I tend to build for what is here now and not for some hypothetical future.

Matthias Pfefferle:
Okay. So it’s more you want to have a platform that proves that it works instead of building, in Germany, we would say, air castles. Yes. Something, yeah, as you said, hypothetical, we could do if anyone would implement that, we could do XY. Right. So that, but I think I kind of agree with that. I was always also the, I want to implement something because it’s, for me, it was kind of a similar socialization with all the web stuff. So I also started with a blog and wanted to keep that momentum. So it was not defining protocols or using protocols because it’s the right way to do that, or because I wanted to work on something like that. It was simply because I needed it and I wanted to see if it works. So I kind of agree with that. But on the other hand, I’m kind of the lazy guy and implementing protocols is really not an easy thing. So I always tend to choose something to work on. And I was always impressed by your work to kind of being the, how you say that in English, the jack of all trades and implement everything when I struggle with implementing only one protocol. So why? I understand that theoretically, but why all of that work? So because that is, that is insane.

Ryan Barrett:
Yeah.

Matthias Pfefferle:
Yeah.

Ryan Barrett:
I mean, I, I wouldn’t, don’t sell yourself short. I mean, you, you did the WordPress Webmentions plugin. I think that for a long time, and maybe still, that was maybe the single most important indie web project. Yeah, period. And that was a full new protocol, like two of them. Like you had to do Webmention and microformats.

Matthias Pfefferle:
Yeah. But I compared with AT Proto or Nostril or ActivityPub, I think Webmention is a very easy, straightforward thingy. There are parts that are tricky, but not because it’s, the spec is hard, but it’s hard to, for example, to get semantics out of HTML is not a fun thing, but it’s more because websites are crappy and not because a standard is implemented or a standard is complicated to implement. So I think that’s a bit of a different level of complexity?

Ryan Barrett:
Uh, yes. Yeah, that’s fair. Um, yeah, scraping arbitrary HTML is no fun. Uh, if you say we require microformats, it’s much better. So, you know, like, takes work, but so yeah. So why have I done so many or worked on so many of these protocols and formats? Um, I think some of it is as engineers, the root of what we do is just put blocks together and build things out of smaller pieces. This is Lego, right? And regardless of what it is we’re building as engineers, protocols and formats are Lego blocks. There are these clear— they may be complicated, but there are these clear instructions for how to connect to it or how to like publish or consume a format, a data format, right? And so as an engineer, to me, when I see a few of them, a few formats, for example, I think, oh, it’s just like this, this field in this format goes to this field in this other format and this field goes here. And then for protocols, oh, this message goes here. This one sends X and this one receives Y. And so it’s, yeah, it’s very tempting and sometimes fun to just take a lot of Lego blocks and plug them together. And when you see that, like, they should be able to plug together and no one’s done it yet, sometimes, like, separate from the use case, the end user functionality, it’s fun to just go try and say, oh yeah, they plug together, or oh no, they don’t. This is WebSocket and this is HTTP, so then I need to bridge that and then I can plug them together or something similar. So one part of it is as an engineer, it’s fun to plug Lego blocks together. Another part is scratching my own itch.

Matthias Pfefferle:
Okay. So I always wanted to have that discussion with you and it’s even better to have that in public. So you implemented a ton of different protocols. And if you have not implemented it, you even understand the spec or know what to do theoretically. From all of these different specs, maybe we can go through the three main things and afterwards we can maybe talk a bit about Nostr. I have not read about Farcaster at all, to be honest. But what of these three protocols would best not fit your needs, but the nearest to what you would see as this is how it should work?

Ryan Barrett:
Yes.

Matthias Pfefferle:
Is that even answerable?

Ryan Barrett:
So I think it is. I would start with a metaphor or an analogy. If you study cryptography, like in academia, in college, there’s always been a saying like, don’t invent a cipher, you know, or you don’t make a good, a successful career as a cryptographer by inventing ciphers. You make it by breaking ciphers. I feel a bit like that here. I can look at a bunch of these different protocols and networks and say, oh, here are the pros and cons. Here are the good parts. Here are the bad parts of each one. I don’t feel qualified or ready to make my own, and I don’t know if I’m— if I would look at any of them and say, oh, this is the best one. Um, I think there are better and worse. Oh, Status was well-intentioned but not so great.

Matthias Pfefferle:
Um, I think well-intentioned sums it up quite good.

Ryan Barrett:
Yeah, you know, like we talked about earlier, it was so early we had so much more to learn. There were so many more new ideas we needed. It was maybe, it was one of the very early decentralized social protocols, like in the modern age, if you don’t count Gopher or Usenet, like the really old school stuff. Of course it wasn’t going to be great, right? But you had, we had to start somewhere. We had to try some things. So right now, what do I think is good? Yeah, maybe we’ll put a link in the show notes. I did a talk at the App Protocol conference last year. I think it was called All the Protocols Compared. So that’s the long version of this answer. But there are a number— I look at the modern protocols. So the big ones that we would think about, IndieWeb, ActivityPub, App Protocol, Nostr, Farcaster, Maybe DSNP. I don’t think that ever really hit and is definitely slowing down now. Um, yeah, so what are good ideas? Um, I think asymmetric key identity, so identity based on public keys, is a good idea. Um, and you see that in a number of these protocols. That is App Protocol, Nostr, Forecaster, DSMB, um, and blockchain. Uh, the key problem with public keys is, or key-based identity, is that it is recoverability. If we want to make something so usable that all of our family can use it, if we tell them, oh, never lose your password, if you lose your password, you’ve lost your account, that’s unacceptable, right? It’s just like not okay. So you need recoverability and there is, we’ve made progress there. There’s like complicated techie stuff, like multisig. Um, there’s very usable stuff like Bluesky where, um, custodial keys, like you had your identity as a key, but they manage the key for you. So those are, there are some good ideas there. Um, I think relays are another one. There was a movement for a while of like pure peer-to-peer, secure scuttlebutt, etc., where we wouldn’t even use— oh, we have the internet, every device is connected, each device should be able to talk to another device without servers. I think in a different world, in a different timeline, the internet may have evolved that way, but it didn’t in ours. We have NAT, we have CGNAT, um, tunneling, etc. It is a very client-server internet that we have grown. Um, and so realistically, you need parts of the network that are always online, and those will be servers. And so the shape of Nostr relays, Proto relays, um, Snapchain and Farcaster Even now you look at, uh, there are Fediverse relays. They are much smaller in scope, but this idea that there are servers and there are multiple and they can talk to each other and they’re, they’re somewhat dumb. Nostr relays are basically these like very limited databases. App Protocol relays are just kind of multiplexing and demultiplexing. They take multiple streams and combine them into one stream. And that’s it. When you look at kind of networking, computer networking coming out of the IETF, this is TCP/IP, Ethernet, et cetera. A lot of networking design ages ago followed this end-to-end principle where you put all of the logic, guaranteed delivery, only once delivery, congestion control, all the logic is in the endpoints on the computers that are the server or the client. The network is dumb. It’s just routing packets. I see some similar ideas in relays in these decentralized protocols. And I think that can make some sense. So yeah, those are two ideas I like. And then also kind of decomposing or separating a lot of the functionality. Some things we see, so in decentralized social, you need data storage. You’re going to have some admin, some moderation. You’re going to have feeds. There’s more of this kind of what I would call the product logic or business logic, like the social part, not the decentralized part. And newer networks are pulling those apart so that you can, you know, custom— like, you can run a custom feed in Blue Sky, in Atmosphere, and that’s totally separate from moderation, right? And literally different people, different organizations can run those and not talk to each other and not be in the same software project, and that’s good. So that’s maybe a third idea I like recently.

Matthias Pfefferle:
Because you mentioned, uh, the, the indie web as a protocol, do you see that really as a protocol? Because I thought about the indie web more like an, uh, philosophical thing, an idea, um, that has some protocols, but it’s more how you use the internet or how you use the web?

Ryan Barrett:
I think it’s both. Yes. Yeah. Like for power users or tech people who use all this stuff, like the, often the dream we have is I want one place or one master or one kind of main place where I control my profile online and where I post, and then that goes everywhere and talks to everything, all the other networks, and everything comes back. But I, I only do it from one centralized or one place for me, at least. Um, maybe it’s my Fediverse account, maybe it’s my Bluesky account, maybe it’s my website. For us in the indie web, often we think of it as our website. Um, and so you’re right, indie web Either first or like importantly is a philosophy. It’s like everyone should have a website. And ideally everyone should have a domain that they own for their website. And so there are some tech and protocols, but I think we would say in the indie web, if you have your website, your own website, especially if you have your own domain, you are part of the indie web. You don’t have to do webmention or microformats or anything else. So philosophically, yes, I agree. Also, there is this indie web protocol stack, Webmentions, microformats, MicroPub, MicroSub, others. And so those add a lot of functionality. But yeah, I think it’s both.

Matthias Pfefferle:
Yeah, but in the end, it feels a lot like more in the Ostatus directory. So direction, not directory. So it’s more a These are parts you could use to have a kind of decentralized communication, but it’s not directly a full-flavored protocol for decentralized communication. And I mentioned that because I really like how you design your bridges, because oftentimes, or I thought, mainly about, okay, if you’re bridging the Fediverse to the Atmosphere, then I should join as an ActivityPub node. But in recent discussion, you always mention, um, when you have a blog, why not use way simpler mechanisms like, for example, RSS or other indie web standards like Webmention and things like that. And I really like that because in the end, implementing RSS or Webmentions or anything else that is in the IndieWeb stack is quite easy and straightforward. And using that to connect to a bridge that does all the heavyweight stuff, um, is kind of, you use open standards in, in, in every level of that bridge thing and even reuse paradigms that you mentioned, like the abstraction of, or the multi-layer thing. So you do not have to care about federation and about who can connect with your site. You implement some basic protocols like the next level of pingbacks, some RSS, maybe some web semantics. And I do all the heavy lifting stuff for you.

Ryan Barrett:
A lot of this again is I think just me avoiding air castles and me not wanting to have to convince someone to install software anywhere. I don’t really know how to predict the future. And so I tend to live in what is, what exists now for any given network or anyone’s website. Like, what does it do now? And it probably does RSS. Most, many websites at least probably don’t do ActivityPub. So yeah, I kind of take that, like, where are people now and what can I build that they can And turn on, or not even, I mean, Granary, for example, like there’s a library and tool, a service I run called Granary that converts between formats. You can use Granary to convert someone’s website like RSS to microformats and they don’t even have to know, right? Like you can use it. Um, and that’s again very much the Web 2.0 mashup kind of permissionless web crawling mentality and era. You know, the era we kind of grow— you and I and other people kind of grew up in. And there are different ideas now and that’s great. But yeah, I think a lot of it is what can I— how can I make this work? How can I make something useful? Assuming nothing changes and assuming no one installs any new software anywhere.

Matthias Pfefferle:
But from your experience, you’re running a bridge. What is— so is having your own website and connecting to that bridge still a thing, or is that still us two being old nostalgic guys wanting back the blogosphere?

Ryan Barrett:
I mean, it’s still a thing because we do it. Yeah, some people do it. I, you know, my partner in this, Anuj, he wants that kind of techie power user dream of one place for his profile. And for him, it’s his Bluesky account. Or ideally might be eventually. For me, it’s my website. And so I think that choice is good. And there are more websites out there probably than accounts on any individual social network. So if Facebook, how many websites are there? Billions, at least tens of billions. There are probably more websites than Facebook accounts, right? And Facebook is the biggest social network. So I mean, If you count websites, and even if you say websites with their own domain, and so then does WordPress.com, does WordPress.com site without its own domain count? I don’t know. But yeah, I mean, there are more websites out there than any social network. So I don’t know.

Matthias Pfefferle:
But do you see a tendency or is there, do you get some feedback like, okay, you allowed me to stay on my side, so I will do that? Or is there a trend?

Ryan Barrett:
Yes, I understand the question. No, for the average, the average person these days is more likely to use social networks and have social media or have social network accounts and less likely to have their own website, especially with their own domain. I think, yes.

Matthias Pfefferle:
So it’s mainly bridging Fediverse accounts to AD Proto accounts and having your own website as part of this new bridge decentralized social network is still the niche?

Ryan Barrett:
Yeah, I think what we see often is the most— so for BridgyFed, for example, most of the websites on it are not personal websites. They are publishers, but they’re very popular. So I think Rolling Stone, for example, has almost is someone is bridged, um, and it has, I think, over 100,000 followers. It’s bridged, uh, accounts. Um, and so on the one hand, it’s probably mostly not personal websites, but there are, I don’t know, maybe 30,000 bridged websites on BridgyFed, and some of them are very popular, right? And so that’s useful.

Matthias Pfefferle:
Okay. So it’s kind of the content creator, I wouldn’t say niche because they may be few in total numbers, but not in follower counts. So, okay. But is there a trend of people following or understanding what that means, bridging between different networks and actively using it, or is this more an I’ve found someone by accident and followed them and didn’t care where the profile is?

Ryan Barrett:
Yeah. So the, I think we are at a bit over 130,000 total bridged accounts on BridgyFed right now, which is good. It’s still, you know, it’s still on the one hand, it’s big. On the other hand, it’s small. Um, yeah, I think lots of people do see and interact with bridged accounts. Like, lots of people are on Bluesky and see and interact with a Fediverse account, or vice versa, and don’t know it. Um, especially for Fediverse accounts, for example, that have set custom domain handles on their— on the Bluesky side. Uh, both Anuj and I, one of our favorite things is to see, to find like big, big conversations where some of the people in the conversation are on Bluesky, some are on the Fediverse, some are even are on like, maybe I’m participating and I’m on my website or you. Um, and as far as we can tell, the people either don’t know or don’t care. Which is great. I love it, right? Like, that’s the dream. Yeah, I don’t— I like that people know about the bridge, but the goal, like, I also love when it works and people don’t know about it and it works anyway.

Matthias Pfefferle:
So maybe we’re coming to an end. Maybe a controversial question.

Ryan Barrett:
Sure. Fun.

Matthias Pfefferle:
So because you’re bridging quite some profiles and there is quite a discussion or discussions through all the networks, I would say you built quite a critical infrastructure. How to handle something like that for the long term?

Ryan Barrett:
Yeah. Uh, yeah, it’s an important question. So it’s better now than it used to be. It used to be one random guy’s side project, um, with zero funding, uh, zero organization or governance. Um, and so that was true for a long time. Uh, and a couple of years ago, some people online started looking at it and saying, oh, this bridge is good. It’s Maybe more than good now, maybe it’s important, uh, was getting big enough, uh, and there were enough accounts on it that were— people cared about having access to. And they were saying like, this is important, it needs to be reliable infrastructure, it needs governance, like how will we make sure this lasts and is stable, etc. On the one hand, like it was flattering that people cared about it enough to say that, right? On the other hand, I didn’t have any of that. It was one random guy’s side project. And so I wrote a post and basically said, hey, like, thank you all so watch. This is one random guy’s side project. Like, there’s nothing to it. Um, it’s open source. Uh, but yeah, uh, if you all want more governance, more organization, great. I’m not gonna do that. That’s not what I’m in this for. Um, so if someone else wants to, great. I was hoping they would say, oh, okay, we get it, and go away. Instead, a number of people popped up and said, oh, Hey, I’ll be that person. I’ll add the organization of the governance. And then I said to myself, well, shit. But so then we did, you know, I ended up working with Anuj and he’s been great. And we have a nonprofit in the US. We have grant funding and crowdfunding. We have a board of directors who are great and independent. Really helpful. So that helps. And I think the other answer is it is open source and it’s public domain licensed. So there are— it’s like totally unencumbered. Anyone else can run their own instance, can take the code and go with it. And so the only— if it died tomorrow, the existing bridged accounts, like, so the domain and the keys that are in the bridge for those accounts, those are important. And so if BridgyFed died, those would go away. That’s not going to happen. I think it’s possible I’ll shut it down at some point, but I fully plan, if I do that, to do an orderly shutdown. Ideally find someone to take it over so that the domain and the keys survive. And if not, you know, like, we would make it work. But yeah, it’s open source. It’s got an org, it’s got some funding. We’re okay for now.

Matthias Pfefferle:
Have you planned something like hosting it as a service for bigger sites or organizations?

Ryan Barrett:
We have talked about it a lot. I think we still don’t know what problem that solves.

Matthias Pfefferle:
I think from, from my perspective, it’s oftentimes the simply the domain thingy, because everything for now is kind of [email protected]. So it’s still very., yeah, very much promoting this single instance and maybe others want to have their own, maybe the Rolling Stone want to have @rollingstone.social or something like that. Is, was that even a question or is that something you think about?

Ryan Barrett:
Yeah, definitely. So the default, you’re right, the handles, the addresses for bridged accounts have you know, something.brid.ui in them. But for a long time now, we’ve let you set a custom domain, um, on Bluesky, but also on the Fediverse. On the Fediverse, at least if you— for bridged websites. Um, okay. Yeah, and we could look into that. So I think the part that’s missing is if you’re on Bluesky and you bridge into the Fediverse. I need to go check. I don’t think we— I don’t think we let you set a custom kind of server part of your Fediverse address there, but we could. Um, but most of that— so we have the custom domains in Bluesky, we have them for websites into the Fediverse, so we’re mostly there. And people definitely use that, uh, especially the Bluesky part. But in general, yeah. So for example, my Fediverse address is [email protected]. It’s through BridgyFed. It doesn’t have grid.gy in it. Yeah.

Matthias Pfefferle:
Okay. So, but, but is that really a thing end users care about? Or is that more as a business owner?

Ryan Barrett:
I think both. I mean, I’m an end user and I did it. Lots of individual people bridging from Fediverse to the Blue Sky, to Blue Sky set custom domain handles. Um, so some people do.

Matthias Pfefferle:
Okay.

Ryan Barrett:
I think maybe more individual people than businesses. I think not nearly as many businesses know about the bridge and having more individual people. Yeah, we’re getting there, but it’s still early.

Matthias Pfefferle:
Okay. So what is, what are you most curious about for the next few months?

Ryan Barrett:
What is our big project? Yeah, there’s so much to do. So one thing we are working on, we’ve started to roll out, is, uh, long form.

Matthias Pfefferle:
So, uh, you know, just like you all think about WordPress for the WordPress community.

Ryan Barrett:
Yeah, yeah. So for a long time, we have bridged web, you know, posts on websites, articles on websites, into the Fediverse as the article Activity Streams 2 type. In Mastodon and other servers, this shows up okay but not great, just the title and the link. That’s something. Um, they’re working on that, I know. Um, Bluesky— Bluesky the app isn’t doing long form really, but other app protocol platforms are, uh, Leaflet, Offprint, uh, Pockets, um, Sequoia. And so some of them got together and made this common lexicon, basically a format called standard.site. And so we added support for that in the bridge. We maybe a week or two ago started publishing these standard site documents. We’re soon going to publish the publication or just kind of like site records, like who is this as opposed to what did they write. I know you all are looking at this too. You actually launched it, right?

Matthias Pfefferle:
I’m still experimenting with that a lot. So yeah, AT Proto is a whole different thing for me.

Ryan Barrett:
Yeah. But yeah, the, so that’s one thing that we’re excited about. Another is we’ve been looking, we’ve been working more on, we have another tool separate from the bridge called Bounce, which is, lets you migrate from one network to another and keep all of your followers. And it uses the bridge under the covers to make that work. Um, one thing we want to do is, uh, let you migrate. Basically, like, when you’re bridged, you have your native account, say, on the Fediverse, and your clone account, say, on Bluesky. Both sides, you know, both the Fediverse and Bluesky let you migrate in accounts. Bluesky’s migration is much more powerful, uh, and full-featured, but they both have that. And so we We want to let you take that existing clone account that you’ve had forever, um, and post it on and move it intact, like keeping its posts, its images, that kind of thing, to a new Bluesky PDS, a new Bluesky server, and then have that be in a real native account you can use. Um, so that’s one thing.

Matthias Pfefferle:
Yeah.

Ryan Barrett:
Um, and then we’re always looking at new networks. Uh, we have Nostr mostly complete in terms of the implementation. Just a few other things we’re still thinking about how to launch, but we’re talking with Rabble, uh, Evan Hendersplath, um, about Divine, which is a new kind of video platform on top of Nostr. And we, we want to make sure we can bridge that when it’s— when they launch that. We look at Forecaster. Forecaster has had a lot of drama in the last month or so, um, uh,, which is interesting. But, um, yeah, we look at that. And then there’s, yeah, there’s, there’s so much more out there to do, uh, lots of new ideas.

Matthias Pfefferle:
So I would love to, um, talk about the standards thing when you launch that. Maybe you want to join me again together with Anoush, uh, talking a bit more about the, the new stuff, uh, later this year. Um, where can we follow all progress you are doing.

Ryan Barrett:
Yeah. So our organization is called ANEW Social. So anew.social. BridgyFed is fed.brid.gy.

Matthias Pfefferle:
And I am snarfed.org, S-N-A-R-F-E-D.org.

Ryan Barrett:
Perfect.

Matthias Pfefferle:
I think I will link all of that in the show notes.

Ryan Barrett:
So I’ve had so much fun here, uh, and I’ve loved working with you again for at least 15 years on indie web stuff. We go back so far. And again, I mean, you’ve done a ton, uh, but yeah, early on, especially the WordPress Webmention plugin was I think the most important project in the indie web, um, you know, bar none. So, uh, yeah, thank you for all of everything you’ve done too.

Matthias Pfefferle:
Thanks a lot. What should I say about that? Thank you a lot for all your work and for doing it as a general service so that everyone can use it. I hope I can and will link and find everything for the show notes. If not, let me know. I will put everything in there. And yeah, thanks a lot for joining. And I’m curious about the next few months.

Ryan Barrett:
Me too. This was great. Thank you, Matthias.

Hey #ActivityPub friends. Are there any new ActivityPub / Mastodon features I should add to #ActivityBot?

It's a small bot-only ActivityPub server in a single PHP file.

https://gitlab.com/edent/activity-bot/

It can be followed, post images, allow quote posts, etc.

Is there anything else you would like a bot-server to be able to do?