I think end-to-end encryption is currently undergoing a crisis of definition. Within the security and cryptography communities, implementations of secure messaging like Whatsapp and iMessage are considered to be end-to-end encrypted communications. The philosophical intention of end-to-end encryption is to enable communication through infrastructure which you do not trust.
Beyond the technical considerations, different demographics have various expectations about what end-to-end encryption means. Sometimes their position is that end-to-end encryption does not exist without decentralization. Some want to have a fully federated protocol. Others believe that allowing an intermediary to broker key exchange invalidates the end-to-end confidentiality and authenticity assurances.
This often leads to nitpicking about what defines end-to-end encryption which, while a useful exercise in its own right, doesn't capture the heart of the grievances at play. In many cases it would be more productive to talk more directly about expectations regarding the security and privacy of a service or protocol rather than whether or not it fulfills an underspecified set of criteria.
This is to say that you can make a compelling argument that allowing a third party to broker your key exchange is insufficiently secure for you. But if you anchor that critique to whether or not the protocol satisfies end-to-end encryption, you're inviting rebuttals that don't substantially respond to what your critique is. Whether or not something satisfies end-to-end encryption is somewhat less important than whether or not you think it holistically satisfies what you consider to be strong confidentiality and authenticity assurances. If your problem is that you don't want a company like Facebook bootstrapping the key exchange for you, then you should defend that (valid) opinion by choosing a different set of criteria to work with.
Decentralization/federation and the existence of third-party brokers don't really come into play here. What is required is
a. a cryptographically secure protocol
b. an UI that is strict about checking that the keys and signatures match and is loud about notifying the user when they don't
c. an open source client
Open source client doesn't really get you much, since you would need to audit the entire source code, then build it yourself, which you probably won't do. If you aren't doing that, you're implicitly trusting others to have audited the source code, and to provide builds that actually correspond to the source code. Now there are reasons to trust the open source community like this (lots of eyeballs, and people who care about security and privacy can inspect the source code and third party builds), but there is also one advantage to commercial software (including closed source) over open source: you're more likely to have someone to sue if they lie or mess up.
An open source client is not required for end-to-end encryption.
Do you see what I'm getting at? We're quibbling about a technically precise definition instead of what you'd like to see in a secure messaging application.
Yes, this is what I meant. Unless we think of some magical way to verify that e2e is really happening (enter quantum voodoo or something similarly wild), the only way to verify is by actually inspecting the source code. Even this may not be enough, but it is a necessary precondition for now.
Beyond the technical considerations, different demographics have various expectations about what end-to-end encryption means. Sometimes their position is that end-to-end encryption does not exist without decentralization. Some want to have a fully federated protocol. Others believe that allowing an intermediary to broker key exchange invalidates the end-to-end confidentiality and authenticity assurances.
This often leads to nitpicking about what defines end-to-end encryption which, while a useful exercise in its own right, doesn't capture the heart of the grievances at play. In many cases it would be more productive to talk more directly about expectations regarding the security and privacy of a service or protocol rather than whether or not it fulfills an underspecified set of criteria.
This is to say that you can make a compelling argument that allowing a third party to broker your key exchange is insufficiently secure for you. But if you anchor that critique to whether or not the protocol satisfies end-to-end encryption, you're inviting rebuttals that don't substantially respond to what your critique is. Whether or not something satisfies end-to-end encryption is somewhat less important than whether or not you think it holistically satisfies what you consider to be strong confidentiality and authenticity assurances. If your problem is that you don't want a company like Facebook bootstrapping the key exchange for you, then you should defend that (valid) opinion by choosing a different set of criteria to work with.