You’re still blending authority with attribution.

Bridge admins have no authority, agreed. They’re just reposting content. That’s precisely the problem with proxy identity. There is nothing binding the bridged account to the origin user beyond social assumption.

Pubky doesn’t grant bridges authority either. It removes the need for them to have any.

Authority comes from key control. Attribution comes from signatures. Discovery comes from resolving the user’s published endpoints.

If a bridge reposts ActivityPub content, you can verify:

• Did this originate from the user’s key?
• Does it resolve from their declared endpoints?
• Is it mirrored faithfully or modified?

If not, it’s just an unaffiliated repost, exactly as you described. The difference is it becomes trivially provable instead of socially ambiguous.

On your other questions:

DHT = Distributed Hash Table. Think of it as a decentralized key-value store. Instead of DNS mapping domains to IPs via registrars, pubky records map public keys to user-declared resource endpoints via the DHT.

And no, DNS is not limited to IP mapping. It’s a general record system. Pubky uses the same concept, just key-native and registrarless.

Compatibility with ActivityPub wouldn’t be about protocol replacement. It’s about identity resolution. ActivityPub actors could publish pubky (PKARR) records pointing to their canonical data, mirrors, or servers. Apps that resolve those records gain cryptographic attribution instead of trusting instance admins.

If you had a login bug I am happy to provide a free code, and happy to collect your bug report.

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.

Okay, but you will be on Pubky eventually, may as well start now.

Ready when you are!
(well, give me a couple weeks, heading back to Portugal this weekend)