Off-Chain Records Generator/Manager

[0xc0de4c0ffee]

.json generator process

1. User connects ETH wallet with 0xaddr

2. Eth domain :
   a) User inputs their sub/domain.eth
   b) OR select one from a list of names owned/managed by 0xaddr.

3. Resolver Check
   a) if domain.eth's resolver is ENSIP15: offchain records compatible
   b) switch resolver if it's not compatible, <requires on-chain-tx>

4. IPNS Check
   a) if there's NO IPNS contenthash set for domain.eth user have to input valid IPNS key
   b) OR generate ENS specific deterministic IPNS keys using CAIP222 (check NIP-111).
   c) add IPNS hash to resolver, use signed contenthash for extra security. <requires on-chain-tx>

5. Resolve old IPNS
   a) read old records in ../.well-known/... as text/json and load in manager.
   b) ? load all other files and manage with js-ipfs or let users download .well-known directory data as zip.

6. Records manager
   a) ENS App like records manager with <Sign this record> button for each records.
   b) generate json files for all records inside .well-known/eth/domain/<record>.json
   c) add old files/index html profile.
   d) upload to ipfs & pin, wait & resolve over 1+ ipfs gateways (js-ipfs + ipfs service)
   e) publish ipfs hash under IPNS. (ipns services)

[sshmatrix]

I think I should start building this. Our contract only makes sense if it has a client to manage records alongside. ENS + IPNS is small user base, so we have to compensate for that and try to master the UI/UX. ENSIP for off-chain records should feature both the contract and the client for maximum impact.

If/when Tom arrives, we'll ask him the optimal path from his experience. Until then, I am gonna start building something with Node.js + Shell. I have all the pieces for the IPFS + IPNS pinning from indexit.eth

[0xc0de4c0ffee]

we've to use w3name https://github.com/web3-storage/w3name + deterministic keygen?

& 1+ public ipfs node/service to pin records directory..
we can later limit CAR file size to <10 MB during upload so it's easier to run public ipfs nodes/cluster.

Also check #4 for js-ipfs client on browser.

[sshmatrix]

we've to use w3name https://github.com/web3-storage/w3name + deterministic keygen?

I'll have a look at it and post back

& 1+ public ipfs node/service to pin records directory.. we can later limit CAR file size to <10 MB during upload so it's easier to run public ipfs nodes/cluster.

10 MB?! That's a lot; is it because we are letting people upload web content as well?

Also check #4 for js-ipfs client on browser.

Ok, will do 👍

[sshmatrix]

we've to use w3name https://github.com/web3-storage/w3name + deterministic keygen?

Ok, I had a look at w3name. Seems very nice; private key import/export is possible so we can have additional pinning service on the side 🥳 I will have a look at HKDF key export to ed25519.

& 1+ public ipfs node/service to pin records directory.. we can later limit CAR file size to <10 MB during upload so it's easier to run public ipfs nodes/cluster.

If we use the new structuring that you proposed in #6, we only need a few KB...

[sshmatrix]

I have a question about the frontend implementation. I was thinking that we should have a list of names corresponding to an address like the ENS app:

Users can then click on each name and set records for them. Getting all ENS names owned by an address is easy to find with most web3 providers but finding all addresses controlled/managed by an address is harder.

1. Only way to find this info is by querying the ENS subgraph. Issue is obviously that we will need to deploy our own subgraph to achieve this for a proper service. TheGraph's API is only for playing, not for production.

OR,

2. We can skip the list for managed names and instead prompt the user to enter a name to set the records for. It is easier to check whether an address manages a name than getting all names managed by said address preemptively.

2 is easy but bad frontend design. 1 is hard. What do you think? List or no list?

[0xc0de4c0ffee]

go easy & simple with option 2..
we can change frontend in future with some indexer/apis.. like https://api.zora.co/
also check https://github.com/namesys-eth/ethereum-indexer from dear jolly-roger.