Signal-Server

or not the feature was available. So Signal is open source, but not in a way that's useful if you want to change something. I don't want to discourage people from using Signal. It's a great app. But I thought this was worth pointing out, assuming the LibreSignal is representative of what will happen if people want to make changes to their client.

. They asked for permission, and I said we'd prefer for them to use their own servers and their own name. The same thing we say to everyone. Many people do set up their own servers for their own products, these people chose not to. We didn't threaten anyone with anything, legal or otherwise. > 'Open' Whisper aren't open sourcing their server. The voice side is locked up. https://github.com/whispersystems/textsecure-server https://github.com/whispersystems/pushserver https://github.com/whispersystems/websocket-resources https://github.com/whispersystems/dropwizard-simpleauth By "the voice side," do you mean a TURN server? Plenty of options for you out there. Or are you just more interested in having something to blame us for? And LibreSignal already doesn't support voice, even with our servers, so your complaint doesn't make much sense. > Why have Signal Protocol chosen now to open the license up a little? Well, I can't help but wonder if it's because Olm is finally ready, done and merging for public release. The conspiracy theories never stop. We haven't changed anything, this has been what we said our policy was all along, but people thought that was some kind of conspiracy. Of course, now that we've made it an explicit license term instead, that's also suspicious somehow. Why would anyone ever want to be involved in this community you think we're not appropriately considering?

urite thought experiments is the process of how to evolve Matrix into a full e2e-and-metadata-privacy-protecting protocol at some point in future - as per http://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20En.... How you protect metadata privacy if locked to a single centralised service like Signal is perhaps questionable. We believe that avoiding being dependent on any single communication provider is just as important to user freedom as maintaining communication privacy. If I don't trust Signal to host my communication reliably, I want to pick my own provider... whilst still being able to talk to other Signal users. One could argue that end-to-end encryption is incompatible with federation, as if a vulnerability is found in the encryption ratchet you need the power to upgrade the world 'instantly', as WhatsApp or whoever can. However, I am not convinced this is a showstopper. It's certainly convenient that WhatsApp can instantly lock out all versions of an app which are known to contain a vulnerability from their network, but you can get a similar effect by issuing a press release as per heardbleed, poodle etc; giving users a way to check if they're vulnerable; encouraging them to move to a provider or app which is not vulnerable. It's not watertight, but it's a compromise I think many would be willing to make in exchange for having the freedom to select their communication provider and communicate with who they choose. 2. If the federated protocol has well-defined layers, it's not even a problem if the lower layers are slow and hard to evolve; you just go and swap out the higher layer ones. Internet Protocol is so widely deployed it's infamously painful to evolve... but it's a relatively simple and well-focused problem domain, so a huge migration like ipv4->ipv6 happens very rarely. But it hasn't materially slowed down the adoption and uptake of the internet - in fact, ipv4 is a victim of its own success! Meanwhile, HTTP is also so widely deployed that it's a relatively slow process to do something like HTTP/1.x->HTTP/2. But, again, it turns out this isn't remotely a showstopping problem - most of the interesting stuff happens layered as applications on top of HTTP - HTTP does one thing, and does it relatively well, so it's a great building block. And it's the basis of the entirely open and interoperable architecture of the web. With Matrix, we're trying to provide a similarly simple and focused base layer: a decentralised pubsub/storage API layered on HTTP. We provide some modules that define additional semantics (messaging, VoIP etc) as layers on top of that core API (http://matrix.org/docs/spec/client_server/r0.1.0.html#module...) which can evolve separately. We believe that having an open and interoperable protocol for securely synchronising data in realtime is as fundamental as the web itself, and this is NOT a function that should be silo'd into any provider. 3. The blog post says: "One of the controversial things we did with Signal early on was to build it as an unfederated service.". This seems a bit strange, given the TextSecure server itself exposes a basic federation API: https://github.com/WhisperSystems/TextSecure-Server/tree/mas... 4. My actual retort wasn't to tell Moxie that he's dumb - he's obviously an incredibly smart guy, even if I disagree with his position here. I actually said: "Okay. The internet wouldn't have got very far without interoperable application-layer protocols defined by 3rd parties, but if you would only ever consider using one for TextSecure that you invented yourself, that's your call :)" So, if anyone's reading this and still believes in the dream of an interoperable and federated internet, feel free to come hang out at https://matrix.to/#/#matrix:matrix.org and live the dream :)