3 ms·

I agree that it's sad. However, here's some rationale as to why we feel that it's the appropriate choice for the project: https://whispersystems.org/blog/the-ec

by moxie 10y ago

I agree that it's sad. However, here's some rationale as to why we feel that it's the appropriate choice for the project: https://whispersystems.org/blog/the-ecosystem-is-moving/ https://whispersystems.org/blog/the-ecosystem-is-moving/

aftbit 10y ago
Thanks for the well-reasoned and well-explained post. I still instinctively disagree, but I need to go make a cup of tea and ruminate a bit before I can fully explain why. My biggest concern is that centralization necessarily leads to a central point of failure. While someone might be able to run their own fork of Signal in that case (kudos for making the server open source as well as the client!), nobody seems to be trying right now. Contrast that with email, XMPP, or HTTP, where millions of people have developed the operational skills necessary to do a modern deployment. Your point about people moving between services instead of between providers seems true enough, in every space except for chat. People choose their chat provider based almost entirely on what their friends and colleagues use. Look at Facebook Messenger, Google Talk/Hangouts, even the ancient Yahoo Instant Messenger - all have significant user bases, despite not being number 1 technically in basically any category. As for a truly federated applications protocol (with no implicit centralization), HTTP springs to mind. Despite your argument about HTTP being stuck in the 90s, a number of significant changes have occurred in this century. WebSockets, HTTP/2, and nearly ubiquitous TLS, among others, not to mention all the improvements in the browser space now that we finally have a sane standards process. And all of this is possible despite the fact that no single company has a majority of either server or client implementations. More importantly, HTTP is used in a far different way today than it ever was in the past. Instead of delivering pages of content over fast pipes to desktops, HTTP delivers rich web apps over flaky wireless connections to handheld computers - and the same protocol developed in the 80s has evolved nicely to serve both of these purposes. Federation may not be the best answer for OWS, and it might not even be the best answer for the Signal community (today), but it is not necessarily the kiss of death for a project either.

by moxie 10y ago

aftbit 10y ago

Thanks for the well-reasoned and well-explained post. I still instinctively disagree, but I need to go make a cup of tea and ruminate a bit before I can fully explain why. My biggest concern is that centralization necessarily leads to a central point of failure. While someone might be able to run their own fork of Signal in that case (kudos for making the server open source as well as the client!), nobody seems to be trying right now. Contrast that with email, XMPP, or HTTP, where millions of people have developed the operational skills necessary to do a modern deployment. Your point about people moving between services instead of between providers seems true enough, in every space except for chat. People choose their chat provider based almost entirely on what their friends and colleagues use. Look at Facebook Messenger, Google Talk/Hangouts, even the ancient Yahoo Instant Messenger - all have significant user bases, despite not being number 1 technically in basically any category. As for a truly federated applications protocol (with no implicit centralization), HTTP springs to mind. Despite your argument about HTTP being stuck in the 90s, a number of significant changes have occurred in this century. WebSockets, HTTP/2, and nearly ubiquitous TLS, among others, not to mention all the improvements in the browser space now that we finally have a sane standards process. And all of this is possible despite the fact that no single company has a majority of either server or client implementations. More importantly, HTTP is used in a far different way today than it ever was in the past. Instead of delivering pages of content over fast pipes to desktops, HTTP delivers rich web apps over flaky wireless connections to handheld computers - and the same protocol developed in the 80s has evolved nicely to serve both of these purposes. Federation may not be the best answer for OWS, and it might not even be the best answer for the Signal community (today), but it is not necessarily the kiss of death for a project either.