I watched that at the time. I found his insistence on comparing his 7-year-old centralised protocol to a 60-year-old federated protocol uncompelling: his point that "nothing changes with federated protocols" was slightly undermined by that gargantuan gap of inception.

Couple that with the highly conspicuous skipping over of XMPP (much more comparable, only the briefest of mentions, no mention of things like OMEMO), and ignoring of Matrix (the most comparable, and not a single mention). Overall it's a pretty ridiculous talk in this context.

He goes on to describe some challenges for federated protocols in their solutions to censorship, availability & control. On censorship, the challenges are real and it's QUITE EASY to reason about possible solutions. Many of which already exist or are in development. It's clear he hasn't spent much time thinking about this. On availability, his entire argument is "Yahoo mail exists"; his discussion here is just straight-up disingenuous. Finally, on control, he segues into unrelated areas around XMPP extensibility and seems to think extensions have no value without ubiquity (though fails to expand on his reasons for this conclusion). I'd agree XMPP's XEPs are highly flawed architecturally, but again... there's newer protocols, we've learned and evolved this already.

Leaving aside that the bulk of the middle of the talk is exclusively selling new features ("new techniques") of Signal that have no direct connection to the talk's stated topic ("distributed and decentralized technology"), there are a few salient points he made that I'd agree with:

1. Federated & decentralised protocols are by their nature harder to do, and harder/slower to change. This is true, but is by no means an absolute; it's a trade-off against other benefits.

2. E2E encrypted email is too hard and probably not worth doing. Yes, PGP is highly flawed, and in general layering encryption on top of a 60-year-old protocol is hard. (Though as above, his insistence on focusing only on email for comparison rather than Signal's direct viable competitors is telling).

3. Signal's E2E/crypto-specific innovations are cool, and current federated state-of-the-art is behind on many of them.

I think it makes more sense to use federated protocols after you've reached a certain critical mass of features and usability. Look how much Signal has improved in the last 6 months. That would be harder with a federated system as people just don't update apps. I'll buy a push for Signal to become federated when it is fully featured (which may be pretty soon). Also at that point, what is to stop people from making a federated Signal? Or creating a fork that allows contact with the centralized server AND a federated space? Is it impossible to have a mixture?

> I think it makes more sense to use federated protocols after you've reached a certain critical mass of features and usability. Look how much Signal has improved in the last 6 months.

I agree with this, but I’m starting to worry if that time will ever come. I thought messaging apps had basically all the features they’d ever need years ago. But I was wrong. I use voice messages in signal and WhatsApp daily now. If it were up to me, we would have made a federation protocol years ago and these features would have to have been figured out through endless meetings in a standards process.

I don't think federation solves that, in fact I think it makes it more difficult. Signal is open source and we're constantly seeing people complain on here about its lack of features or whatever. If we can't convince the most populous location for programmers to help in that respect then how could we do it for a federated network? And even the server is open sources. So I don't see why you couldn't have a fork that is federated. Or an app that is able to talk to both the centralized server and federated servers. It seems more a will problem than anything else and I don't see why Moxie and the Signal team would focus on these features above other features that are actually helping get people on the platform (arguably more important than any aspect).

You have to include an update mechanism in the core of distributed software?