Changes in Records Data Storage Format

[0xc0de4c0ffee]

Current design is to handle records.json as domain.eth.limo/.well-known/eth/domain/records.json and internally route contenthash so domain will resolve for other records.

I was testing possible new format to handle records.json, with some big upsides and small down side.
Update :

1. use <ipns-hash>.ipns.dweb.link/eth/domain/records.json and dweb.link/ipns/<hash>/eth/domain/<records>.json format
2. contenthash is handled at ../eth/domain/contenthash.json for domain.eth.limo
3. if there's non-ens .well-known records, it'll will be in domain.eth.limo/.well-known/..

+ve side: easy to manage records.

1. we can add and randomize public gateways instead of sending all req to eth.limo and expect fix to fallback bug soon.
2. we get clean IPNS and don't have to handle "IPFS" directory structures in IPNS publish as it's standalone now.
3. we can run IPFS + IPNS services to manage all records easily as we don't have to directly deal with html/js inside IPFS directory.
4. we don't break anything in IPNS+IPLD or ?require future changes to handle IPLD+IPNS+ENS.

-ve side: same as current design problem.

1. web pages and other content and LN/Nostr related .well-known records have to go inside contenthash. we don't manage that directly, only keep that hash in json.
2. .. * have to finish build & test to find more

domain.eth >> IPNS >> CCIP read >> resolve record

Still WIP idea so we've to build both to compare full differences.

[sshmatrix]

1. use <ipns-hash>.ipns.dweb.link/eth/domain/records.json and dweb.link/ipns/<hash>/eth/domain/<records>.json format

Ok, so not .well-known directory for ENS stuff.

2. contenthash is handled at ../eth/domain/contenthash.json for domain.eth.limo

Ok, but I thought contenthash was on-chain? Or, you are proposing that the contenthash is also kept off-chain and then queried by CCIP-Read?

2. we get clean IPNS and don't have to handle "IPFS" directory structures in IPNS publish as it's standalone now.
3. we can run IPFS + IPNS services to manage all records easily as we don't have to directly deal with html/js inside IPFS directory.

I didn't understand how we are bypassing "IPFS". Is it possible to add content to an IPNS key directly?

[sshmatrix]

Okay, I think I got the gist of what you are saying, although I am still slightly lost on the specific sub-points related to implementation. I will try to re-read/process it. In the end, we don't want people to worry about remembering to keep their records in their web content whenever they want to update their contenthash. Basically separate the records from the web content. Correct me if I am wrong

[sshmatrix]

Ok, I got what you mean. We should implement this. It makes total sense to separate the web content (eth.limo/) and the records (.ipns.dweb.link) with two independent gateways. Only one issue: this means that we will need to keep a separate IPNS key record in CCIP2 Resolver for the records.json. In other words, when changing the Resolver to ours, users will also be keygen + deploying a new IPNS record inside the new Resolver, correct?

[sshmatrix]

3. if there's non-ens .well-known records, it'll will be in domain.eth.limo/.well-known/..

Why not also <ipns-hash>.ipns.dweb.link/.well-known/..? I know it is less useful since users will surely prefer the cleaner gateway for real-world use but doesn't hurt to provide the feature? Or feature-creeping? 😝

[0xc0de4c0ffee]

Users have one IPNS contenthash set on-chain resolver:
a) default : add same ipns in .../contenthash.json, it'll be used for webcontent + /.well-known/..
b) if they use different IPNS/IPFS contenthash in json, on-chain CH is used for ENS records only & new CH is used for dweb including /.well-known/..

Most users won't need 2nd CH, it's for advance users/dapps, & all future safe for IPLD/.../records.json as we don't want to add html/js/.. in ipld then work on more specs to resolve those plaintext/datauris.

[sshmatrix]

Ok, I see. That sounds good 👌🏻

[0xc0de4c0ffee]

I've updated namesys-eth/ccip2-eth-resolver#3
It's still missing few functions to manage stuffs around, >80% ready + missing full test.

@sshmatrix / @tomlightning / @eth-limo 🙏 if you've suggestions/ questions tag me on PR or here.

[sshmatrix]

Looks like the client (protoype: https://namesys-eth.github.io/ccip2-eth-client/) and contracts will be ready simultaneously 🍾