What next?

[sshmatrix]

We have several avenues to explore but only limited manpower and manhours. Here are our options in no specific order:

1

Default subdomain page for each record holder on *.user.namesys.eth where they can see their records and edit them

2

dApp Store: dapp.domain.eth

3

Deploy w3name

4

Build a usecase to drive adoption

5

Integrate GoDID

6

Build for Swarm

[0xc0de4c0ffee]

1. Default subdomain page for each record holder on *.user.namesys.eth where they can see their records and edit them
   This topic should include @serenae-fansubs' meta indexer/ resolution ENSIP-##
   Discussion : [Draft] ENSIP-##: Off-chain Name Meta-Resolution
   Draft ENSIP link : https://github.com/serenae-fansubs/docs/blob/3f3f06ef7ad46fce338daa7f2afbd91b18daf342/ens-improvement-proposals/ensip-16-off-chain-name-meta-resolution.md

it can be sub-divided into 3 parts,

• a) default profile : frontend profile page for .eth to display ENS records
• b) records updater : same as namesys.eth records manager, could be simpler for standalone .eth stored at namesys..eth or ?redirect to namesys.xyz
• c) meta records storage in text/"key" = json value
  • subLabels: List of subnames under .eth
  • texts: list of resolvable text record keys
  • coinTypes: list of resolvable coin types
  • metaText: list of all other custom meta-information
    There's also alternative eth.ens.meta text records with all of above records in single json. For latest records lookup we could use web2 endpoint like records.namesys.xyz/eth/<domain>/meta.json & save ourself from *.namesys.xyz wildcard setup headache.. storing meta records and version data on .eth will simplify profile display and updating process.

[0xc0de4c0ffee]

2. DAPP Store :
   we should display all/public "installed" dapps on default profile page at .eth as dashboard for owner/visitor, similar to (1), .. full dapp store interface can also be hooked in <store/dapp>..eth itself. All dapps are on subdomain mapping so it'll also fit in sublabels but we should also make a new meta "dapp" text records to filter list of installed dapps from normal subdomains.

3. w3name/IPNS republishing services :
   We're already in contact with @eth-limo to deploy a parallel ipns republisher. It's better to team up with eth.limo again for this instead of deploying our own service. It's possible to send same signed IPNS records to multiple republishing services for better/faster propagation but in wild case scenarios* if republishers are on fragmented DHT/network and don't get proper latest n+1 updates, they might be republishing/propagating stale records <n.. similar to our last issue with two different eth.limo nodes. At core it's IPFS/NS problem, & there are few more upcoming solutions like IPNI, IROH & AMINO public DHT. So our easy option is to redeploy w3name's codes, or go hard full rebuilding dht put/routing put API for IPNS republishing/manager service.

[0xc0de4c0ffee]

4. Build a usecase to drive adoption
   this is directly related to (2) DApp store, we're skipping tiny feature upgrades at core so we can make it all open dapp feature.

few ideas for future dapp/features,

• default profile page/dashboard for *.eth
• <blog>.domain.eth dapp
• <nostr>.domain.eth standalone dapp, open for any d-social apps
• <social>.domain.eth dapp, list followers/following, encrypted offhchain DM.
• <stealth/pay>.domain.eth dapp, dark wallet pattern to manage/generate 1:1 EOA between sender and owner of domain.eth
• <shop>.domain.eth dapp, marketplace interface managed by owner
  *tiny list for initial setup, dapp store will open all possible future feature/dapps ideas.

5. GODID/Integration
   it'll be easier to integrate anywhere if we build standalone namesys.js to read/update offfchain records..

6. Swarm
   this will require some minor changes in gateway contract to include swarm prefixes.. Also have to check if current ipfs2.eth contract can handle swarm to read data over *.ipfs2.eth.limo. https://github.com/multiformats/multicodec/blob/master/table.csv