Skip to main content


"There can be at most one successful protocol for a given use case."

#EvanPoll #poll

  • Strongly agree (4%, 5 votes)
  • Somewhat agree (14%, 18 votes)
  • Somewhat disagree (51%, 64 votes)
  • Strongly disagree (29%, 37 votes)
124 voters. Poll end: in 5 hours

Evan Prodromou reshared this.

in reply to Evan Prodromou

Feel free to share examples to back up your reasoning!
This entry was edited (18 hours ago)
in reply to Evan Prodromou

the entire series of 802.11 protocols? Depending on how narrowly you define your use case you could really home in on one. But if it's broadly defined, have your pick. I think my current wireless router supports four different protocols right now?

BLE (coded PHY), Zigbee and propRF protocols share plenty of overlap.

in reply to Jake

@Affekt that's a great example. Are they different protocols?
@Jake
in reply to Evan Prodromou

I'd say yes, for Wi-Fi you're covering different PHYs for modulation and frequency, different error correction, and lots of other stuff. If a protocol is the set of rules that says how one device can talk to another then those differences necessitate a different protocol. In the case of the low power RF protocols, BLE vs Zigbee, those are definitely distinct from each other at multiple levels.
This entry was edited (17 hours ago)
in reply to Evan Prodromou

yeah, they're both supported in hundreds of millions of devices worldwide. I've seen furnace filters with BLE. There's a huge market share for Zigbee in IoT/smart home and industrial applications. You'll find 2.4GHz propRF in electronic shelf labels, utility meters, and sensors among other use cases.
in reply to Jake

@Affekt so, I'd give IOT as an example of a problem area where too many incompatible protocols has inhibited growth of the market.
@Jake
in reply to Jake

I slept in it and came up with another couple of examples. For more than two decades we had CDMA and GSM as differing protocols for cell phones in the US. For satellite positioning there's GPS and GLONASS (depending on how you want to define protocol since those are both one way signals)
in reply to Jake

@Affekt did it help to have multiple protocols for phones in the US?
@Jake
in reply to Evan Prodromou

We could discuss definitions but… same kind of thing surely, no?
in reply to Evan Prodromou

that I have to think about it! a lot!

[The cheap answer is that every human language is a protocol for inter-human communication, and there are thousands of those…]

in reply to Luis Villa

@luis_in_brief when humans had one language, we built a tower to Heaven, and God had to strike it down and confuse our tongues or we'd get too powerful.
in reply to Evan Prodromou

I think most folks would agree that OAuth is a better and newer protocol than SAML, but SAML is still widely deployed for many of the use cases you could address with OAuth.

I expect that OAuth will eventually fully replace SAML but it will take a long time.

in reply to Evan Prodromou

various ways of doing rpc's between computer. Seems like every big tech company has its own protocol. Go has a simple internal one. There are/were xml things for it.
They usually have different trade offs: how efficient they pack data, If that efficiency is optimized for packing/unpacking speed or final packet size.
Also a bunch of NIH.

If you count power delivery to homes as protocol: 230V, 50Hz I'm not sure if Europe settled on a 16A 3 phase. Then there is 110V, 60Hz, and alternatives.

This entry was edited (14 hours ago)
in reply to Evan Prodromou

this one's nuanced for me.

I am somewhat disagree but only if the protocols play nice.

In the social media space, it seems as though ActivityPub and protocols that proceeded it that you were also a part of, came first. (Correct me if I'm wrong, I barely know about all the different protocols)

If that's the case, it's really on the other protocols to play nice and show that they support open communication.

However, that's not happening, so I lean towards agree.

in reply to Evan Prodromou

Somewhat disagree. Today I was mildly inconvenienced to discover a given email host supports IMAP but not POP. Both have their use cases, and in this case I was planning to use POP. On a side note, I wish JMAP was more widely supported.
in reply to Evan Prodromou

Making me think real strongly about network effects — I want to say disagree, but there _are_ major forces making that not entirely be the case.
in reply to Mx. Aria Stewart

@aredridel I tell anyone I can about network effects. If the value of a network is in the possible connections (Metcalfe's Law), the value of a network with N nodes varies with N^2. That's why big networks succeed.

If you take a total population of nodes N and split it into two incompatible networks of equal size N/2, the value of each is proportional to (N/2)^2 or N^2/4. If you add up the value, it's N^2/2 -- about half of what the value would be with one united network.

in reply to Evan Prodromou

Exactly. And yet, there's problems of scale, so the equation isn't quite so simple, and trying to make one network do everything is perhaps even more limiting.
in reply to Evan Prodromou

knives do not necessarily have to go on the right side of the plate. Lefthanders benefit from their being two protocols.
in reply to Ben Thompson 🐕

@jbenjamint I'd say the protocol there is "put the knife on the side of the dominant hand"
in reply to Evan Prodromou

I am going to strongly agree with this. Having to understand multiple protocols for the same use case is a lot of mental load and makes the abstraction of the use case leakier. Multiple protocols also requires a bunch more development decisions: deciding which protocol is "best", which library is most robust, etc. This all takes away from the effort of designing the larger scale system of which the use case is a smaller part of.
in reply to Evan Prodromou

If only. We have about a dozen major graphics APIs, all of which are significant, roughly half of them have formal standards, and there's relatively few use cases that don't map to more than one of them (besides "IHV only allows this one").