hiya! if u enjoy reading my stuff, also check out my main website, https://cyrneko.eu!

hiya! the name's Alexia, you may know me from

@starlightnet.work

or

@cyrneko.eu

, but today I will be writing from here, a self-hosted PDS and some leaflet action :)

Today I wanna talk about being multi-protocol on the web, inspired by wafrn! I moderate over at app.wafrn.net and have helped build the software in the past -- both in code contributions, as well as more 'meta' topics like design (not just UI, but internal design too)

Point is, I've been around both blocks and have some thoughts to share in regards to this, what to watch out for, limitations, and of course, why I think it's important!

The History

So, multi-protocol apps and sites have been around for far longer than wafrn has, even before we started having these "social web" conversations that have sprung up recently, there have been feed readers that can do multiple formats, like RSS, Atom, and more recently JSON-feeds

But of course, in more recent times we've had things like Hubzilla or Friendica (I believe?) which have approached social media and (micro)blogging with an edge of decentralization by also supporting multiple protocols, like Diaspora and ActivityPub at once

and honestly, I think this is right and important!

Over time, we will inevitably move away from platforms and protocols, as we learn from past protocols and platforms to improve on our ideas and execution, and more projects pop up with different goals and concepts. Take for example polyproto.org or versia.pub, both of which basically exist because someone thought "this design is suboptimal for this usecase, let me try!"

Where I think this really does something special though, is when we take this ever moving landscape and decide we wanna keep our audience, our platform, our {whatever inspiring-sounding thing} as we move, and we make multi-protocol platforms.

Platforms that transcend the usual norms of being built on one technical document, or maybe a handful, that transcends the need to be 100% functional in every aspect in exchange for a much wider reach throughout the internet, and much more longevity too.

A case study: WAFRN

Wafrn, as previously stated, supports multiple protocols; Namely it supports both ActivityPub and ATProto with the app.bsky.* lexicon, as well as our own micro-lexicon for bites.

While we regularly have to work around many different protocol-specific restrictions, we've been doing so better and better as more contributors become part of the team, and it allowed us to have much wider appeal to...basically everyone!

I've seen people that I thought looked like they were totally happy with Mastodon or Bluesky swap over, purely because being multi-protocol was an appealing concept, especially because...

Being Multi-Protocol means being native

This is very important! One reason Wafrn is even gaining popularity is because we aren't burdened by the limitations of either network or their culture; We can interoperate with both as if we were just another node in their respective networks, implement their features and still enjoy existing on both networks.

We as the users can have a peaceful co-existence across networks, which is astounding considering how much Fedi hates Bluesky and vice-versa.

Well, alright, not everyone hates the other platform, but there's definitely a loud minority on both ends.

Consent and Context

That said, for any and all of these multi-protocol projects, it's very important to consider the context they exist in. The context of the culture, the tech, the implementation, etc.

For example, Wafrn was first made as a standalone thing, then later connected to the ActivityPub-powered Fediverse, and then even later connected to the ATmosphere, or more specifically bluesky.

Because so many people were concerned about Bluesky on the Fediverse (and still are), we made sure that Bluesky integration is opt-in, but once opted in still provides you with an actually decent experience on both sides, which attempts to bridge the gaps wherever is feasible.

Take, for example, the post length limit defined in the Bluesky lexicon. It's only 300 characters, which REALLY isn't a lot, so we decided to compromise by having long Wafrn posts be shortened with an ellipsis, and then embedding a URL to the original Wafrn post with the full content. We also included a full-text field that allows supported clients (like reddwarf.app) to still display the full post, including another Wafrn feature that isn't on Bluesky, CSS Styles and lots of HTML elements.

Benefits

This also ties back to a post I made a long time ago, going over how people are benefited by open standards, and how they tend to want such open standards if given the option.

That post is a bit old and I feel I've improved in writing since, but you can read it here: https://cyrneko.eu/people-want-open-standards_x5uvx7dphv.html

It's better for all of us if we invest time and effort into cross-protocol interoperability, and writing software that can account for the quirks of different platforms.

Wafrn is a bad example, because it wasn't designed to be this way and we're actively shoehorning in new features as we go, and refactoring all the Bluesky integration code slowly. If we were to start over, I think I can speak for the rest of the team that we should've taken a modular approach in which data is translated from the Wafrn-Native origin format to the required ActivityPub and ATProto formats in a "plugin" type way. Think that the data is ingested by an "AP Plugin" and an "ATProto Plugin" and then sent off that way.

Think perhaps something like Bonfire, which in itself is focused around modularity and extensibility. It'd be the prime candidate for this sort of thing.

The End.

That is all I have to say, for now! Maybe just because it's almost 5 in the morning, and my brain is starting to give out, but perhaps I will continue this train of thought in the future :3

I wish you, the reader, a good rest of the day or night!

If you enjoyed what you read, consider supporting me, tysm <3