You are correct - it allows consumers to know the message has not been tampered.
The downside of your trust model is permission. Facebook and Twitter may revoke your permission to use “your” identity at any time, for any reason.
Requiring ID verification for a rented online identity is a terrible trend imo. These companies are not to be trusted - they exploit users and inevitably sell your data or get breached.
A tweet is not a direct message, it's a broadcast message.
Without a centralized 3rd party mapping names to public keys, the identity of the sender can be set to whatever you want.
Your model only works for non-tweets where I'm sending to people I had communication with in the past and was able to verify a public key... at which point you're just providing E2E encryption with worse ergonomics and no new value prop.
—
You cannot cheat the oracle problem. There is no magic bullet that lets you broadcast messages with known identifies without a centralized 3rd party.
- Sharing keys in person
- Sharing keys via other channels like Twitter
- Via DNS using NIP-05
> Without a centralized 3rd party mapping names to public keys
Sharing in person doesn't work for broadcasting
Other channels require falling back to some non-decentralized system.
Again, it's the oracle problem. You can't say it's not true, that's like saying "1+1=2" is not true.