5 ms·

I don't see how this approach stops a centralized service from taking over via the standard approach of Embrace, Extend, Extinguish [1]: - Embrace: BigTech imp

I don't see how this approach stops a centralized service from taking over via the standard approach of Embrace, Extend, Extinguish [1]: - Embrace: BigTech implements the protocol. For example, say text messaging. - Extend: BigTech implements some custom additions to the protocol, that only work for their service. For example, add support for sending photos, but only ones stored on BigTech's servers. - Extinguish: Once people get hooked on your custom features, make it hard for competitors to replicate. For example, stop competitors from being able to load photos from BigTech's servers. 1: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

vorpalhex 4y ago
[2] is the step that can be addressed.
- karpierz 4y ago
  Extend? How do you address it?
  - vorpalhex 4y ago
    "Protocol extensions must be able to be implemented by all users of the protocol and may not require a particular providers service but allow any alternative so long as it is protocol compatible" Basically force those extensions to be equally cross-compatible.
    - jacobr1 4y ago
      Though protocols are not law. You can have non-conforming implementations. If these are popular enough (potentially due to $proprietary_thing) then people will just use them. Other services will need to decide if they want to continue to interoperate.
    - karpierz 4y ago
      Two key issues with a rule like that: 1. What forces me to comply with this rule? 2. What does "able to be implemented" mean? In theory, you can re-implement my entire codebase. In practice, you'll find it very difficult to maintain feature parity with me if I repeatedly extend the protocol faster than you can implement it. Especially if I don't publish my code or document the extension or if I simply have more resources available to me (either in terms of server-bandwidth or programmers).
userbinator 4y ago
We've already seen this happen with Google and browsers. In this case, they extend so quickly and also manage to spread much propaganda about how their way is better, that they're basically using change as their weapon. Protocols aren't the solution when people are so easily manipulated. Perhaps stagnation is the solution. Something that stays static for a longer time is also going to have more implementations.
cuteboy19 4y ago
The most successful example of EEE is not Microsoft but rather Linux. It embraced the Unix* style, extended it with its own stuff and now all non Linux unices are basically an afterthought
- __d 4y ago
  It doesn't really undermine your point, but, well ... iOS/macOS/watchOS/tvOS/etcOS is hardly an afterthought, and they are all non-Linux Unix systems.
gweinberg 4y ago
It depends on who cares, and how much. The world isn't one-size-fits-all, and if 90+% of internet users are happy with a platform that arbitrarily bans users or censors content as long as it supports the marquee tag, that's their business. Conversely, I could see using a system that only gets me a very limited amount of content as long as I consider it to be high quality, and if my friends' ex-wives or people I haven't seen since high school and wasn't close to then never use the system, well, I think I can handle that.

vorpalhex 4y ago

[2] is the step that can be addressed.

karpierz 4y ago
Extend? How do you address it?
- vorpalhex 4y ago
  "Protocol extensions must be able to be implemented by all users of the protocol and may not require a particular providers service but allow any alternative so long as it is protocol compatible" Basically force those extensions to be equally cross-compatible.
  - jacobr1 4y ago
    Though protocols are not law. You can have non-conforming implementations. If these are popular enough (potentially due to $proprietary_thing) then people will just use them. Other services will need to decide if they want to continue to interoperate.
  - karpierz 4y ago
    Two key issues with a rule like that: 1. What forces me to comply with this rule? 2. What does "able to be implemented" mean? In theory, you can re-implement my entire codebase. In practice, you'll find it very difficult to maintain feature parity with me if I repeatedly extend the protocol faster than you can implement it. Especially if I don't publish my code or document the extension or if I simply have more resources available to me (either in terms of server-bandwidth or programmers).

userbinator 4y ago

We've already seen this happen with Google and browsers. In this case, they extend so quickly and also manage to spread much propaganda about how their way is better, that they're basically using change as their weapon. Protocols aren't the solution when people are so easily manipulated. Perhaps stagnation is the solution. Something that stays static for a longer time is also going to have more implementations.

cuteboy19 4y ago

The most successful example of EEE is not Microsoft but rather Linux. It embraced the Unix* style, extended it with its own stuff and now all non Linux unices are basically an afterthought

__d 4y ago
It doesn't really undermine your point, but, well ... iOS/macOS/watchOS/tvOS/etcOS is hardly an afterthought, and they are all non-Linux Unix systems.

gweinberg 4y ago

It depends on who cares, and how much. The world isn't one-size-fits-all, and if 90+% of internet users are happy with a platform that arbitrarily bans users or censors content as long as it supports the marquee tag, that's their business. Conversely, I could see using a system that only gets me a very limited amount of content as long as I consider it to be high quality, and if my friends' ex-wives or people I haven't seen since high school and wasn't close to then never use the system, well, I think I can handle that.