mashedvikings
But I suppose the reason NSA was delaying was they had to develop a workaround for the encryption. Remember, while public key crypto got strong in 1996 when the key lengths ended Tailored Access Operations (NSA's hacking team) was created in 1998, before DES was replaced with AES in 2001.
Now obviously it's not that simple. Phasing out weak standards has taken very long. Personally, I would love to understand what goes on in the heads of developers who still use age old primitives like MD5 and RSA-1280 (iMessage).
Related to this, you should definitely watch Moxie Marlinspike's (lead dev of Signal) talk where he tells about his discussion with Kipp Hickman, a developer of SSL: https://www.youtube.com/watch?v=UawS3_iuHoA#t=13m52s (until 16:33)
All in all, this is a great talk, I highly recommend you watch from start.
"Metadata concern is bogus" yet the linked documentation explicitly says bridges expose metadata, and that home servers expose metadata.
One advantage of Pond-hybrid is "Supports any and all Matrix clients via the existing standard client-server API". This means the issue is desire to remain compatible with insecure clients. This is lack of agility is not needed.
I hope you fix things before it's too late and focus on Pond or other Tor hidden service based communication.
And FFS, it hasn't even got anything to do with protocol, it's something the client can do by itself. Having worked on secure messaging apps, I would never go to federated protocols. Signal's infrastructure allows rapid improvement of protocol and fast elimination of insecure protocol revisions. That's where we need to be at. Just look at the history of TLS and the potential in downgrade attacks. Old revisions die slowly. Signal can easily monitor what versions are still running, push updates to users and ensure codebase isn't bloated by code that merely represents insecure protocols.
Signal succeeds because of it's "closed" ecosystem, it doesn't suffer from the tyranny of the majority that occurs when there's disagreement about e.g. seriousness of some attack, when some feature might be risky. With Matrix, I worry developers of clients can affect choices, and the protocol is already dangerous, to ensure (backwards) compatibility with older clients and (other) protocols, Matrix is not end-to-end encrypted by default. I will eat my hat with mustard the day I see all Matrix clients support only end-to-end encryption for everything.