Matthew S. Smith
The rise of the Fediverse is only accelerating as companies like Mozilla and WordPress make moves to support it. Even Meta is rumored to be working on a decentralized social network.
But there's one particular start-up that seems determined to go its own way.
I spoke with @tchambers and @evan about what's driving the Fediverse migration - and the obstacles that can thwart some would-be users.
Evan Prodromou
'Prodromou, however, has strong words for any organization looking to enter social media with a new decentralized social media protocol. “I’m not interested in any protocol besides ActivityPub,” he says. “Anyone working on brand new protocols in 2023 should stop immediately. They are going to do more harm than good."'
This may be surprising for people who have known me for a long time. I've generally been supportive of trying new protocols and tools.
Evan Prodromou
AP has turned a corner. It's standardized and in wide use.
Building extensions on top of AP is useful and necessary, but starting over with incompatible protocols is a bad plan.
Blue Sky in particular is a bad project. It started after AP was standardized. The team had access to many many people's time and all the docs and experience of the fediverse.
But they opted to make a snowflake protocol instead. I think because they want to capture value at the protocol level.
Don't use Blue Sky.
Evan Prodromou
I'm really sorry I have to say this. I see everyone who works on decentralized social networks as a colleague in a very important project. We might not all agree on the details of architecture or data structures, but we are working toward the same goal.
I think the acquisition of Twitter raised the stakes significantly. We need to all be working towards growing this network. Sowing confusion by launching incompatible products today may be well-intentioned, but it's clearly counterproductive.
Evan Prodromou
I don't think I've wished failure on any decentralized social network platform before.
My sincerest hope is that the Blue Sky team has a change of heart and starts building on well-established protocol standards instead.
There is a long-shot option that they are able to cannibalize the existing fediverse, then use that to push out to even more users. I think this is really unlikely.
So the next best option is that they fail quickly and are forgotten soon.
Evan Prodromou
@Samir that was my first option, yes.
Samir Al-Battran
@evan or maybe at some point make it compatible with ActivityPub?
Evan Prodromou
The absolutely worst option is that they achieve a modicum of success, and then there are multiple, competing, incompatible networks.
We know from Metcalfe's law that a network that takes up half the available audience doesn't have 1/2 the value to users; it has 1/4 the value. The division makes each network much worse.
Most people and companies, when presented with the choice, won't bother. They'll wait until someone else figures it out.
Evan Prodromou
It is a shitty, stupid way to slow down all decentralized social networking, at a time when fast adoption is at its most important point.
Evan Prodromou
@22 mostly about Blue Sky. I know that a lot of people have existing protocols to support. I think anyone starting with new incompatible protocols in 2023 better have a really, really, REALLY good explanation for why the benefits outweigh the damage they'll do.
22
@evan thanks for this follow-up! I’m still surprised by the force of your feeling and I’m trying to read between the lines—when you said “Anyone working on brand new protocols in 2023 should stop immediately” are you mostly talking about BlueSky? Or do you mean exactly what you said, anything not building upon ActivityPub is wasted effort?
Evan Prodromou
@22 I'd also say that AP is an extremely extensible protocol. You can build some really cool stuff by making new Activity Streams 2.0 activity and object types.
Evan Prodromou
@22 it's tough; unfortunately I don't see an alternative. Are you working on a new, incompatible social networking protocol?
Evan Prodromou
They are not critical design flaws.
Dying servers is only a problem if you don't use your own domain. We're in an intermediary period; more people and orgs will run their own servers in the future
Scalability isn't a problem reserved for AP. Fanout of messages to thousands of recipients takes time and resources. True in siloed networks as well as federated.
Search is not a technical but a cultural issue in the fediverse.
Risotto Bias
@evan I think it solves some problems that AP is unwilling to approach (dying servers / DID, scalability, search), and are all critical flaws of how AP was designed that make it more burdensome on the servers that have to host a thundering herd of dumb clients
Evan Prodromou
@risottobias the thundering herd problem, when clients all get the OpenGraph data for a link at once, is a problem with an obvious solution.
We have a rich representation for a link ("Link") in Activity Streams 2.0. Before sending out a post with a link in it, the sending server should do ONE opengraph query, and add the metadata as a link to the outgoing message.
Evan Prodromou
@risottobias OK. I hope you fail fast and don't do too much damage.
Risotto Bias
@evan *sigh*
I'll use the protocol that isn't painful to develop on, and doesn't cost a fortune to run.
Evan Prodromou
@22 I don't think that's true for gzipped payloads.
I think a low energy implementation of AP would be great. A lot of the fields in AS2 are optional.
I think there are some best practices that could work to make an AP server that is in low-power mode until the client connects, and then delivers outbound activities and solicits delivery of inbound ones.
22
@evan short answer:no ?
Longer answer: no innocent ? I have long admired the decentralization of platforms like Secure Scuttlebutt—decentralized down to the physical network layer! Works over bicycle-net, sneaker-net!—even though their use of Merkle trees and resulting inability to delete/forget made me sadly give up on SSB. I’d love to see a lighter more energy-efficient ActivityPub. The Mastodon REST API is also incredibly heavyweight (several kilobytes for a single toot).
But. Your point is very well-taken.
Evan Prodromou
I think it's an interesting problem. A server running in low-energy mode most of the time would miss any incoming messages.
So you'd need a way to signal to other servers that your low-energy server is back online, and wants to collect any incoming messages.
One way to notify them is by delivering outgoing messages. We should probably make a best practice that if you're doing exponential backoff, and you get an incoming message from the server, it's a good time to retry.
John Panzer
@evan @22 That would be a much better use of time and energy at this point.
Evan Prodromou
@surfbum oh good. I want to do what's right for this community and for the internet, and sometimes that means telling well-meaning people they're on the wrong track.
Luke
@evan@prodromou.pub That is a really interesting read thanks.
Evan Prodromou
@mgaruccio I guess it's just having a resilient network that can handle having nodes that are just very occasionally available. Anyways, neat problem to think about.
Mike Garuccio
That feels like an interesting implementation but I’m not convinced this needs to be solved at the application layer. An idling raspberry pi 3 pulls ~1.5w, some hardware likely gets that below 1w at idle, and I’d applicable for all use-cases, not just a bespoke AP implementation.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.