Simplifying & Rebranding as NameSys.eth Client

[0xc0de4c0ffee]

Our stack of ENS service resolvers.
a) *.IPFS2.eth.limo is helper IPFS gateway with standalone resolver contract at "ipfs2.eth".
b) CCIP2.eth is more technical term for our offchain ccip to eth standalone resolver contract at "ccip2.eth".

Idea : Rename current ccip2.eth client as "namesys.eth" and simplify whole UX process starting with basic info/about/terms & wallet/connect feature only. we already have all required parts so simplifying whole process as full standalone ENS records viewer and manager. It's same as our current ccip2.eth client "rebranded" with some basic changes in how we display records manager/viewer from start to finish line.

Big Why? ;)
Branding 🌈 & simplifying frontend so we don't have to teach/explain anything to our dear normal web2+3 users about advanced off-chain records manger UI/X..

1. logo+ NameSys/.eth brand, same as current client with extra big domain input box similar to google search
   -? full address/ENS/records/keywords search engine & market mode for future
2. display full page ENS records viewer for single domain.eth, support on-chain / off-chain reads
3. if wallet is connected & address is owner of domain.eth OR claims to be manager,
   • activate full records management feature for that domain.eth, (?NO on-chain records manager support for now)
   • ?migrate ccip2.eth resolver process
   • generate & setup ipns & manager keys, update off-chain records
   • delete keys / store keys encrypted temporarily on client/session.
4. Update market feature with full buy/sell offer/accept features from open ENS/NFT markets/APIs.
   • future stack, we can add those signed data as text records & also propagate/store/transmit that over Nostr/messaging protocols
5. Like ❤️ button to add domain.eth in a side "fav-list" of domains owned/managed/liked by current user.
   Save fav list to text records "favourite".json

We're already trying hard to pin latest IPFS/IPLD data and republish IPNS services.. so our next big move is to index and search all records. Not going full dweb search/indexer like our dear frens on Esteroids :p. Full search is for future stack, indexing/searching on/off-chain ens records will take more IPLD/db storage and processing $.

[sshmatrix]

Idea : Rename current ccip2.eth client as "namesys.eth" and simplify whole UX process starting with basic info/about/terms & wallet/connect feature only. we already have all required parts so simplifying whole process as full standalone ENS records viewer and manager. It's same as our current ccip2.eth client "rebranded" with some basic changes in how we display records manager/viewer from start to finish line.

I am on board with this 💯

1. logo+ NameSys/.eth brand, same as current client with extra big domain input box similar to google search

That's fine. We can re-design the landing page to start with a Search Box. Once user connects, additional 'My Names' appears, which takes them to the same flow as it is now; similar to the ENS App with a list view. Basically move the current landing page to 'My Names' which appears only upon connection and the new landing page will be a big Search Bar.

-? full address/ENS/records/keywords search engine & market mode for future

Need to deploy our own subgraph for this. Or another indexer. Otherwise it is not doable feature-wise. I think we should do the subgraph once and for all. It is practically forking ENS subgraph and redeploying?

2. display full page ENS records viewer for single domain.eth, support on-chain / off-chain reads

We already have this. I guess you want to move it from a limited modal view to a full page view? Unless there is a very good reason for it, I'll prefer to keep the modal for now since it involves decent amount of code re-factoring. But I can enlarge the area to make it appear like a page. It is also only worth doing if we have the subgraph/indexer (sufficient data pulled with sufficient ease and speed to populate the page with). A better idea would be to push for ENSIP and then I open a PR for our record manager integration with the ENS Manager App 😋 I am dreaming now 😆 🤣

3. if wallet is connected & address is owner of domain.eth OR claims to be manager,

   • activate full records management feature for that domain.eth, (?NO on-chain records manager support for now)
   • ?migrate ccip2.eth resolver process
   • generate & setup ipns & manager keys, update off-chain records
   • delete keys / store keys encrypted temporarily on client/session.

Same as now. Apart from adding encrypted keys to session storage.

4. Update market feature with full buy/sell offer/accept features from open ENS/NFT markets/APIs.

That is a lot of work and I wouldn't want to do it unless we get financially supported somehow for the off-chain records at least.

5. Like ❤️ button to add domain.eth in a side "fav-list" of domains owned/managed/liked by current user.
Save fav list to text records "favourite".json

I like this. I will implement this right away!

I like all the ideas but we risk prolonging this sub-project if we go into market stuffs for now. Market stuff should be in Dostr anyway. BRC-20 is starting to pick some steam and there is word on the street about moving it to a Bitcoin L2.

[0xc0de4c0ffee]

Need to deploy our own subgraph for this. Or another indexer. Otherwise it is not doable feature-wise. I think we should do the subgraph once and for all. It is practically forking ENS subgraph and redeploying?

I was discussing around that on https://discuss.ens.domains/t/draft-ensip-off-chain-name-meta-resolution/17019/7

matoken.eth : You don’t necessarily have to have on chain event, as long as your solution has a capability to list name of domains/subdomains

we've to run proper graphql endpoints or plain json API if matoken.eth's ENSIP supports that.. graphql would be nice but it's too centralized & $ computing hungry with fully off-chain records. We already have IPNS, IPFS/IPLD data stored, indexing all in OUR centralized servers is good feature but big still No-go web2 region for now. serenae's ENSIP is bit easier to manage in our current IPFS/IPLD storage, so that's enough for basic meta/index.. if we want full records search in future we've to move into graph/web2 servers.

We already have this. I guess you want to move it from a limited modal view to a full page view?..

Yup, it's about changing interface to be simple standalone records viewer 1st, and activate manager mode for owner/managers only.
we can use same records viewer html as default content/profile page for domain.eth set in contenthash.json..

That is a lot of work and I wouldn't want to do it unless we get financially supported somehow for the off-chain records at least.

Basic links to market is good enough for now, future version can use some Market/APIs like (https://api.zora.co/) to pull data.

I like all the ideas but we risk prolonging this sub-project if we go into market stuffs for now. Market stuff should be in Dostr anyway.

We can skip heavy changes and only do renaming/branding with simple full/big interface for now.. leave ENS market to future namesys.. Dostr/clients can do ENS/nft and any defi market integration easily.

& last thing, we shouldn't focus on dumping json on btc chain and follow same old ETH/nft shills now jumping & pumping in btc land as new maxis. BTC+data looks good for winter, it's too big tx cost in summer, similar to ETH gas fees.
There's LN as L2 so better L2/L3 designs will have minimum L1 footprints.

[sshmatrix]

Frontend refactoring is done: https://namesys-eth.github.io/ccip2-eth-client/

I am going to deploy our own ENS Subgraph on our backend server. We need it. I cannot do without it. Basic data is standing in the way of any cool feature. It won't take long

[sshmatrix]

5. Like ❤️ button to add domain.eth in a side "fav-list" of domains owned/managed/liked by current user.
Save fav list to text records "favourite".json

I started implementing it and realised that we don't save any current user data. We only assign records to names. So, it doesn't make sense to start a new pipeline to save user-specific data. On second thoughts, favourite list is probably not our kinda thing?