Hi Victor & Victor,
NameSys has built pretty much exactly the same thing with IPFS & IPNS (see 1 and 2).
We use IPFS content wrapped inside IPNS for infinite upgradeability. Since IPFS is inherently a nearly cost-free solution, we favour it over Arweave or Swarm. We use a similar Signing and Verification algorithm as Makoto pointed out. This prohibits any unauthorised updates to the records (even if the IPNS key is compromised) leaving (D)DOS as the only vulnerability.
Internal content addressing differences between Swarm and IPFS will have their impact during the lookup stage but I don’t know enough to comment on this. On the plus side, it seems like fetching and validating the latest version in Swarm is somewhat easier than in IPNS by construction. With IPNS, we have to rely on an external indexer to track the latest version which is not ideal.
Couple of pain points in Swarm’s implementation are perhaps:
-
Incompatibility with CCIP-Read which requires HTTP interfacing. Is Swarm content fully queryable over HTTP, say for example through BEE API? CCIP-Read in its current form cannot handle JSON-RPC, native
ipfs://,ipns://,bzz://,onion://etc content addressing, due to which we must handle all interfacing across a middleware. Swarm will need its own middleware (probably bootstrapped to BEE API) answering CCIP-Read queries over HTTP. This could be dynamic or static. -
Native payments in
$BZZ? It’s not hard to inject multiple wallets in clients as long as there is some sort of interoperability
Cheers
NameSys