Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Im saying the other way around. One protocol, 3 clients for 3 demographics.


sort by: page size:

It's reasonable when it's your own custom protocol, but it's a very different story for an open one that has multiple clients.

Your objection is that there are multiple clients for an open protocol?

Its probably more than one company. but even then, lets say that it was one company, shouldnt decentralized,open protocols have open specs to help create more clients?

The issue is not so much the diversity of clients, but fragmentation caused by proprietary protocols they use.

It hardly seems wrong to judge a protocol by the client software when there is only one client worth mentioning?

However there is a whole ecosystem of clients, and they can't all be back doored. You are also free with write your own client, and many do (which is why we have so many in the first place).

Protocols, not platforms, people!


they still have to support older clients. so it is not that easy to just change the protocol.

It's never about the protocol, it's about the SLA of the server and UX design of the client.

That's sounds a lot like protocol negotiation, just implicit vs explicit and limited to 2 algos.

It's just another protocol.

If clients supporting multiple protocols become popular they could default to a sensible open protocol. Which, as the default in the popular app(s), would become the most widely used protocol. People can switch at their leisure because the app supports both, but over time the users transition because it's the default.

Since the old and proprietary protocols are only sustained by the network effect, they lose users, and eventually support for them gets dropped.

It's a method of transitioning from a collection of proprietary systems with their own network effects to an open one, by temporarily supporting both. For obvious reasons the operators of the proprietary systems don't want to be subject to that competition, which is they same reason they shouldn't be allowed to shut it out.


At that point I think the choice gets back to their whole goal of

> A client comfortable for daily use which implements every single protocol feature should be a feasible weekend programming project for a single developer.

This isn't a particularly appealing protocol characteristic to me, but YMMV.


I'm not disagreeing. To say that there is only one way or to project presumed goals and intentions is too far for me.

I firmly believe that protocols are developed through vigorous rewrites and aren't nearly as important as the data-stores they provide access to. I would like our data-stores to be stagnant and as required we develop protocols. Figuring out a method to deal with whatever the hosted data-store's chosen protocol is seems correct to me. I just don't see mutual exclusivity. Consider the power of supporting both protocols.


Multiprotocol clients are a dead end. For a developers, it's a never-ending catch-up game against hostile adversary (original service is never happy with being used via third-party clients)

Sorry, to clarify, when i say protocol I specifically mean the E2E encryption protocol.

Also, have you thought about asking your clients/whatever to use one app to communicate with you? Even if you get half of them onboard, it sounds like it would save you a lot of mental bother.


That's a reflection on a small number of Yet Another Not Invented Here clients, as opposed to the protocol and paradigm

It’s a protocol and isn’t tied to any one implementation. There are a lot frontends for it and anyone can make another.

That seems fixable if we were to build a new client / protocol

Not sure what your point is but in that case I'd rather go the obvious third way which is that they would support a subset of open protocols instead of all of them.
next

Legal | privacy