I only see one issue: authority. Bridge administrators have no authority to share ActivityPub posts. They are just random Joes reposting somebody else's content with no associated responsibility or re...
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.
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.