How would discovery by pubkey change these bridge problems at all? Would it somehow force 5 bridges to all use the same account for the same external user? Would it somehow prevent bridge operators fr...
You need to isolate the problems you’re describing. You’re mixing impersonation, data integrity, and discovery into one bridge issue.
Your pubky (a public-key-signed DNS record in Mainline DHT) tells anyone where to find the canonical endpoints for your data. Any app can resolve those endpoints and verify it is looking at the user-designated source, even if that source is a trusted third party.
Integrity is a separate layer. If you want verifiable data, you still need explicit mechanisms such as cryptree structures, versioning, snapshots, mirrors, etc. Discovery does not replace integrity, it enables it.
If the complaint is: I trusted a third-party proxy account and now they are censoring or exploiting it, this gives you a way to set the record straight. You can publish canonical endpoints and authentic data. It does not and cannot prevent bad actors from continuing to impersonate you. Protocols cannot stop attempts at impersonation, they can only make authentic identity cryptographically distinguishable.
If the complaint is: impersonators exist, there is no digital way to prevent someone from copying your public data. The enforceable boundary is signature verification and canonical resolution. If an app refuses to verify, that is an application design choice, not a protocol limitation.
If the complaint is: I want trustless bridging inside legacy apps, then those apps must adopt identity resolution and verification models like this, or accept the tradeoffs of custodial bridges.
Not your key, not your account.
Your pubky (a public-key-signed DNS record in Mainline DHT) tells anyone where to find the canonical endpoints for your data. Any app can resolve those endpoints and verify it is looking at the user-designated source, even if that source is a trusted third party.
Integrity is a separate layer. If you want verifiable data, you still need explicit mechanisms such as cryptree structures, versioning, snapshots, mirrors, etc. Discovery does not replace integrity, it enables it.
If the complaint is: I trusted a third-party proxy account and now they are censoring or exploiting it, this gives you a way to set the record straight. You can publish canonical endpoints and authentic data. It does not and cannot prevent bad actors from continuing to impersonate you. Protocols cannot stop attempts at impersonation, they can only make authentic identity cryptographically distinguishable.
If the complaint is: impersonators exist, there is no digital way to prevent someone from copying your public data. The enforceable boundary is signature verification and canonical resolution. If an app refuses to verify, that is an application design choice, not a protocol limitation.
If the complaint is: I want trustless bridging inside legacy apps, then those apps must adopt identity resolution and verification models like this, or accept the tradeoffs of custodial bridges.
Not your key, not your account.