3 ms·
It certainly is for some. You are correct - it allows consumers to know the message has not been tampered. The downside of your trust model is permission. Fac
by unboxingelf 3y ago
It certainly is for some.
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.
- BoorishBears 3y agoYour system is so poorly secured there is no value in tampering with the message: I can just say I'm you and tweet. 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.
- unboxingelf 3y agoThat’s not true. There are methods for proving control of a key, both in the protocol and outside. - Sharing keys in person - Sharing keys via other channels like Twitter - Via DNS using NIP-05
- BoorishBears 3y ago> A tweet is not a direct message, it's a broadcast message. > 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.