3 ms·
I agree entirely. Now help me understand something… why have signal and telegram and everyone made proprietary formats and centralized implementations instead o
by SV_BubbleTime 5y ago
I agree entirely. Now help me understand something… why have signal and telegram and everyone made proprietary formats and centralized implementations instead of an open email2.0 that they also support immediately?
This isn’t my field, so maybe someone has?
- remirk 5y agoSignal says it's harder to innovate in a federated system. [1] [1] https://signal.org/blog/the-ecosystem-is-moving/ https://signal.org/blog/the-ecosystem-is-moving/
- tptacek 5y agoIt clearly is harder to innovate in a federated system. Look at what happened with Matrix, and how much time passed between them standardizing E2E encryption and getting E2E encryption universally deployed (I think that switch just flipped last year?). Not everything Moxie Marlinspike writes is correct, but he's been pretty well vindicated on that. Use whichever secure messenger you like, though.
- SV_BubbleTime 5y agoUnderstood, and that makes sense. But do I want innovation? Or do I want encrypted email 2.0? They didn’t want to make it, good to go there, but why hasn’t anyone else wanted to make it?
- rytor718 5y agoI missed this, very interesting read. He's not entirely wrong. But why are these protocols frozen? I've never developed one so I may just be ignorant of the challenges there, but if, for example, I wanted the XMPP protocol to be able to work with rich media, what's stopping me from updating said protocol to work with rich media instead of relying on optional extensions? In my mind, users of the protocol will receive the update (if they choose of course), thereby making the feature a default for the protocol that isn't reliant on extensions. I admit I don't fully understand why protocols are frozen in this way, even though I agree with the author that the ones we currently have are definitely frozen. Any insights appreciated!
- MattJ100 5y ago> But why are these protocols frozen? They're not "frozen". As mentioned in a sibling comment I wrote a blog post about this very topic - https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/ Your point about optional extensions vs a protocol update isn't really as clear-cut as people think it is. To add a non-optional change to an open protocol in a decentralized network would necessitate blocking people from the network when you roll it out. That's not going to make for a good communication network. The alternative is what XMPP does. The protocol evolves by adding new extensions, and deprecating old ones. Each extension generally has fallback considerations. For example when group/offline media sharing was added many years ago, it was designed such that clients implementing the extension could render the media. Older clients, or clients that can't render media (e.g. terminal clients) simply display a URL. The XMPP Standards Foundation annually publishes its "compliance suites", which (versioned by year) guides implementations on what they need to support. https://xmpp.org/about/compliance-suites.html https://xmpp.org/about/compliance-suites.html
- a-dub 5y agovery interesting. lots to think about!
- MattJ100 5y agoMany people, including myself, disagree with Moxie's stance towards decentralization. I wrote a blog post comparing Signal's approach to the approach taken by many decentralized networks: https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/ And others have written their own: - An Objection to "The Ecosystem is Moving": https://gultsch.de/objection.html https://gultsch.de/objection.html - "Have you considered the alternative?" https://homebrewserver.club/have-you-considered-the-alternative.html https://homebrewserver.club/have-you-considered-the-alternat... - "Re. The Ecosystem is Moving": https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-moving/ https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-mo... Decentralized networks can certainly move. They may not usually move as fast as a centralized one can, but that does not make reliance on a central entity a good alternative.
- cwyers 5y agoOkay, but Moxie has actually produced a secure and usable messaging system, based on his stance. Have any of the people who disagree with him gone ahead and produced something that proves their viewpoint?
- d110af5ccf 5y agoCynically, because they are companies trying to turn a profit. Also many (most?) of the complaints raised in the article will be an issue for any federated system. The article is arguing against end user control and decentralization. It just isn't upfront about it.
- sneak 5y agoSignal is a nonprofit.
- SV_BubbleTime 5y agoThat doesn’t mean they don’t make money, pay salaries, pay grants, accept grants, invest, etc. They are allowed operating reserves, pay taxes, etc. People seem to think non-profit means no money collected, that’s incorrect. It is also within Signal’s interest that the remain competitive and achieve market success.
- notriddle 5y ago> It is also within Signal’s interest that the remain competitive and achieve market success. What good is a communication protocol with nobody to talk to?
- hda2 5y agoOpenAI started as a nonprofit :)
- thayne 5y agoSignal is a non-profit. Signal also has a blog post on why they chose not to support federation: https://signal.org/blog/the-ecosystem-is-moving/ https://signal.org/blog/the-ecosystem-is-moving/ It basically boils down to being able to add features and change things without worrying about whether the federated servers keep up.
- R0b0t1 5y agoThey have, it's called mixmaster/mixminion. It hasn't seen much use since it was introduced.
- SV_BubbleTime 5y agoThat’s an anonymous remailer isn’t it? Is that a ground up replacement for email or is it an extension (bandaid)?
- R0b0t1 5y agoIf it actually enhances security why is it "just a bandaid?" Recreating everything for fun isn't productive.
- SV_BubbleTime 5y agoI was under the impression that the topic is “email will never be secure and must be replaced”.