I think this is a great question, I would love to see such a write up.
Here's my limited understanding of how each of these stack up. Maybe someone who knows better can help fill in the gaps or correct my mistakes:
Nostr
  • Identification - public/private key pair: npub and nsec
  • Identity validation (tying your key to some real world identity) - NIP-05 (DNS)
  • Data exchange protocol - Nostr protocol - clients send signed messages to relays
  • Data storage and metadata - relays store user data (I think??)
Synonym
  • Identification - public/private key pair: Slashtags
  • Identify validation - ?
  • Data exchange protocol - Hypercore - users send signed messages or data to append only logs
  • Data storage and metadata - Hyperdrive (I think??)
Bluesky/TBD
  • Identification - public/private key pair: DIDs (Decentralized Identifiers)
  • Identify validation - I believe the spec stores some info on the blockchain. They seem to also be focusing on allowing individuals to verify their DID with some organization (eg. a government, a company, an educational institution)
  • Data exchange protocol - Decentralized Web Nodes (???)
  • Data storage and metadata - Decentralized Web Nodes (???)
The obvious (at least to me) step, in terms of compatibility or interoperability, would be for the projects to agree on the nature of the public/private key pair. I'm not sure if they all use the same spec currently, but if they did, I would think it would be trivial to move from one protocol to the next because the public key can be used as a bridge.
AFIAK
Nostr uses bitcoin taproot keys and schnorr signatures
Slashtags use ed25519 private keys and a custom derivation of public key
DIDs ("web5", bluesky) use did methods to define identity (there's 100+), verifiable claims for signatures (ongoing work in progress)
Nostr benefits from being finished and easy to implement.
There are over 100 nostr projects on github alone. With more than one new project daily:
reply
worse is better?
reply
My guess is someone will create tools to translate keys to other protocols. The private key will be the same, but the public keys will have different values due to the differing EC groups, and then they can add support for providing public keys from other protocols and the apps can bridge them. It's just a matter of adding fields to the user information packet.
reply