DanConwayDev on Nostr: summary comparison of Radicle and nip34: Radicle characteristics: * permissionless ...
summary comparison of Radicle and nip34:
Radicle characteristics:
* permissionless account creation. all messages signed with ed5519 key pair
* custom p2p gossip protocol similar to lightning to identify repository peers and peer state
* git protocol use for syncing with peers
* seed nodes (essentially relays) used to addresses reliability issues of p2p
* issues, patches and comments stored in git objects
benefits over nip34:
* p2p (works without seed nodes)
* v1 nearly complete, with IDE plugins and web ui
* more momentum, contributors and interest
issues:
* complex, making it potentially difficult to integrate and impractical for other implementations
* centralised development team funded via a Etherium DAO utility token
* learning curve - different mental model required than GitHub PRs which may be an adoption barrier
* custom protocol, not part of an ecosystem
* big maintenance burden
* does not benefit from developments in ecosystem
* no web of trust for spam prevention mechanisms
nip34 benefits over Radicle:
* simple
* multiple implementations
* part of ecosystem (nostr):
* maintained protocols, libraries and tools for issues like transport, spam prevention, etc
* account reuse across use cases
* notifications accessible from other social clients
* doesn't rely on infrastructure bespoke to nip34 protocol
* can be adopted alongside GitHub repositories
nip34 issues:
* no momentum or usage
* tooling is immature and with bare bones feature
Radicle characteristics:
* permissionless account creation. all messages signed with ed5519 key pair
* custom p2p gossip protocol similar to lightning to identify repository peers and peer state
* git protocol use for syncing with peers
* seed nodes (essentially relays) used to addresses reliability issues of p2p
* issues, patches and comments stored in git objects
benefits over nip34:
* p2p (works without seed nodes)
* v1 nearly complete, with IDE plugins and web ui
* more momentum, contributors and interest
issues:
* complex, making it potentially difficult to integrate and impractical for other implementations
* centralised development team funded via a Etherium DAO utility token
* learning curve - different mental model required than GitHub PRs which may be an adoption barrier
* custom protocol, not part of an ecosystem
* big maintenance burden
* does not benefit from developments in ecosystem
* no web of trust for spam prevention mechanisms
nip34 benefits over Radicle:
* simple
* multiple implementations
* part of ecosystem (nostr):
* maintained protocols, libraries and tools for issues like transport, spam prevention, etc
* account reuse across use cases
* notifications accessible from other social clients
* doesn't rely on infrastructure bespoke to nip34 protocol
* can be adopted alongside GitHub repositories
nip34 issues:
* no momentum or usage
* tooling is immature and with bare bones feature