Reflections: The ecosystem is moving
So: I was the other side of the email conversation that Moxie alludes to in this post, so I&#x27;ll respond to it here given comments are disabled on the OWS blog :)<p>1. Totally agreed that federation slows down evolution of the core protocol.  However, higher level protocols do <i>NOT</i> have to be stuck in time forever in the manner of SMTP if you design them with a migration&#x2F;evolution strategy from the outset.  For instance, with Matrix.org the core premise is decentralising communication between different networks.  <i>This includes different versions of Matrix itself</i>.  We could build an entirely new Matrix 2.0 tomorrow, using (say) a fully p2p WebRTC Datachannel transport or IPFS or whatever rather than today&#x27;s HTTP APIs... and simply bridge it into the existing Matrix network using Matrix&#x27;s existing bridging architecture.  In fact, one of our favourite 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 <a href="http:&#x2F;&#x2F;matrix.org&#x2F;~matthew&#x2F;2015-06-26 Matrix Jardin Entropique.pdf" rel="nofollow">http:&#x2F;&#x2F;matrix.org&#x2F;~matthew&#x2F;2015-06-26 Matrix Jardin En...</a>.  How you protect metadata privacy if locked to a single centralised service like Signal is perhaps questionable.<p>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&#x27;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.<p>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 &#x27;instantly&#x27;, as WhatsApp or whoever can.  However, I am not convinced this is a showstopper.  It&#x27;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&#x27;re vulnerable; encouraging them to move to a provider or app which is <i>not</i> vulnerable.  It&#x27;s not watertight, but it&#x27;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.<p>2. If the federated protocol has well-defined layers, it&#x27;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&#x27;s infamously painful to evolve... but it&#x27;s a relatively simple and well-focused problem domain, so a huge migration like ipv4-&gt;ipv6 happens very rarely.  But it hasn&#x27;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&#x27;s a relatively slow process to do something like HTTP&#x2F;1.x-&gt;HTTP&#x2F;2.  But, again, it turns out this isn&#x27;t remotely a showstopping problem - most of the interesting stuff happens layered as applications <i>on top</i> of HTTP - HTTP does one thing, and does it relatively well, so it&#x27;s a great building block.  And it&#x27;s the basis of the <i>entirely open and interoperable</i> architecture of the web.<p>With Matrix, we&#x27;re trying to provide a similarly simple and focused base layer: a decentralised pubsub&#x2F;storage API layered on HTTP.  We provide some modules that define additional semantics (messaging, VoIP etc) as layers on top of that core API (<a href="http:&#x2F;&#x2F;matrix.org&#x2F;docs&#x2F;spec&#x2F;client_server&#x2F;r0.1.0.html#modules" rel="nofollow">http:&#x2F;&#x2F;matrix.org&#x2F;docs&#x2F;spec&#x2F;client_server&#x2F;r0.1.0.html#module...</a>) which can evolve separately.<p>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 <i>NOT</i> a function that should be silo&#x27;d into any provider.<p>3. The blog post says: &quot;One of the controversial things we did with Signal early on was to build it as an unfederated service.&quot;.  This seems a bit strange, given the TextSecure server itself exposes a basic federation API: <a href="https:&#x2F;&#x2F;github.com&#x2F;WhisperSystems&#x2F;TextSecure-Server&#x2F;tree&#x2F;master&#x2F;src&#x2F;main&#x2F;java&#x2F;org&#x2F;whispersystems&#x2F;textsecuregcm&#x2F;federation" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;WhisperSystems&#x2F;TextSecure-Server&#x2F;tree&#x2F;mas...</a><p>4. My actual retort wasn&#x27;t to tell Moxie that he&#x27;s dumb - he&#x27;s obviously an incredibly smart guy, even if I disagree with his position here.  I actually said: &quot;Okay.  The internet wouldn&#x27;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&#x27;s your call :)&quot;<p>So, if anyone&#x27;s reading this and still believes in the dream of an interoperable and federated internet, feel free to come hang out at <a href="https:&#x2F;&#x2F;matrix.to&#x2F;#&#x2F;#matrix:matrix.org" rel="nofollow">https:&#x2F;&#x2F;matrix.to&#x2F;#&#x2F;#matrix:matrix.org</a> and live the dream :)