▦ 2 → Protocols & Clients
by: Shahruz Shaukat
A lot of “decentralizing” a communications protocol seems to be about designing a format for information to be shared between a broadcaster and a receiver, and allowing anyone to create “clients” to use that format.
A client can be anything that interacts with one protocol, multiple protocols, or just a part of a protocol. It can also extend a protocol.
-
An email app is a client that sends email using SMTP and receives emails with IMAP. These protocols enable anyone to use any email client with any email service, and send messages to anyone without worrying about what app they’re using.
-
A web browser uses HTTP to receive HTML to render webpages.
-
A podcast hosting service is a client that handles storage and distribution of podcasts. It only concerns itself with one half of the protocol (the podcaster’s) and not the other (the listener’s).
-
A podcast bookmarking app is a client that handles the other half of the protocol (listening) and builds unique functionality on top of it.
Something can be a client without using decentralized protocols: Facebook’s app and website would be considered Facebook clients. The Telegram and WhatsApp apps are both clients that support messaging but can’t talk to each other because they don’t use the same protocol.
Decentralized communications protocols theoretically put a lot of control into the hands of the users: if you can delete one app, install another, and still have all your stuff (your media, your messages, your social graph, etc), then monopolies on these kinds of apps shouldn’t be able to exist.
How it seems to usually play out though doesn’t support that argument.
-
Google Reader was a popular enough RSS client that when Google shut it down, it was effectively considered the end of RSS & independent blogging. Google had been able to invest enough of their own resources to make the most widely used and well-designed RSS reader, so when they shut it down there weren’t really alternatives that had all the same qualities.
- There’s another element here with things like Facebook, Twitter, Tumblr, Instagram,… using similar “feed” formats and competing more directly on growing attention & retention. It’s possible RSS / independent blogging couldn’t have survived that wave even if Google Reader was never shuttered.
-
Apple Podcasts, Spotify, etc are competing now with propriety subscription podcast formats. Podcasters have to upload their premium shows directly to those service’s dashboards to make them work. This isn’t a necessary approach for enabling paid subscriptions. Patreon for example uses private RSS feeds that can be plugged into any app.
-
Email feels safe right now but there’s a staleness to the standard that’s not aging well. Does Google eventually decide that hosting almost 50% of email users means they can start experimenting with things that only work if you have a @gmail.com address and use Gmail clients?
- Some reasons I don’t think it’s aging well: inconsistent HTML/CSS adoption, no responsive layouts, lots of spam, no way to control if you’re sending data back to the sender when you open an email, etc.
So decentralization alone doesn’t necessarily mean a well funded corporation can’t find some leverage to have significant control over it.
Some things that feel different about Web3 / Ethereum today compared to those examples:
-
Building on top of a decentralized platform (Ethereum) means protocol designers & developers aren't competing with their platform. Ethereum can't steal an app that's successful and make an "official" or native version of it to compete with it, unlike Apple or Facebook who have used their developer platforms that way many times.
-
Licensing is more accessible. There are more standards for common needs, and more ways to learn what they each do. This allows developers to set up more restrictions to prevent their work from being co-opted. For example, the Rainbow wallet app (an Ethereum client) is maybe the most user-friendly, polished mobile wallet today. It's open source and uses a GNU GPL 3.0 license which allows anyone to use the Rainbow code however they want (including commercial use), but they must make their own project open source too with the same license. Having the foresight to work that way feels fresh - it's not how tech startups have typically operated in the past.
-
Backend / API code is public and unchangeable by anyone, including whoever deployed it.
-
This has security benefits - there's no way for bad actors to steal funds in a well designed smart contract.
-
It also means people have to think ahead and try to build things that are extensible and adaptable with time. In that sense developers are inherently working in a "protocol design" moreso than an "API design" one.
-
𖨆 // I'm not sure where to end this post and it can kind of just keep going forever, so I'm stopping here for now.
🕊 Where to next?