App V3 Subdomains/Subdomain registrar UI: Request for feedback

Hi all,

As V3 stabilises we’d like to add more functionality that helps utilises the NameWrapper. One of the main things that the NameWrapper enables is the ability to create subdomains that have specific traits. E.g.

  • Subnames that are unruggable
  • Subnames that have expiry
  • Subnames that have perks (Given by the parent)

The is almost an infinite amount of permutations that a subdomain registrar could implement and that is why we haven’t settled on what kind of UI would be useful to the community. I have my own thoughts, but rather than poison the well, I’d like to ask for more open feedback on what people think would be useful regarding subdomains in the new V3 UI.

6 Likes

I’d love an option where someone can come along and mint a sub-domain straight from ENS

An example:

John Smith comes along to ENS and wants a name

He types in John.eth and it’s gone, he types in Smith.eth and it’s gone, that is a shame

But, the owner of smith.eth has given permission to ENS to be able to sell subdomains of smith.eth

A pop-up comes up and says that subdomains are available of smith.eth

John looks to see if john.smith.eth is available and it is, so John mints the subdomain from ENS

The $ involved then gets split between ENS and the owner of the mother name

This increases the revenue for ENS

This will mean more people will use the main ENS web page instead of somewhere else and users might even buy their own mother name for projects or other reasons

1 Like

When we’ve discussed this in the past I recall you saying that this kind of functionality would be unlikely to be incorporated in the ENS app so that external builders would have the opportunity to create these subdomain registrars.

I know you created your subdomain registrar originally for “educational purposes”, but why this pivot?

3 Likes

It’s not a pivot. Being able to register subnames has always been something we have wanted to do as it creates an easy way for a user to get an ENS name at a lower cost. And we’ve had it for a long time with now.ens.domains, albeit largely unknown with not many users.

External builders should be able to build subdomain registrars and being able to incorporate these external subdomain registrars into the V3 app could be part of that feedback. The new app could possibly recognise contract interfaces and allow registration to subdomain registrars that have been built and setup by external builders.

This thread specifically is to discuss with the community, including people like yourselves to ask what would be useful to you or your users (if you are building subdomain registrars yourself).

1 Like

Thanks for involving the community in discussing subdomain features for the V3 app. However, as an external builder, I’m concerned about the support provided to those creating smart contracts interacting with the protocol, particularly when an “official” set of contracts is introduced.

Nine months ago, I released esf.tools, a third-party ENS wrapper/sub-domain registrar. Despite its potential value and functionality, it hasn’t gained much traction, mainly because users were waiting for “official” contracts. This preference stifles innovation and limits the adoption of alternative solutions.

Maybe ENS should consider promoting and showcasing external registrars to encourage innovation and provide users with a variety of options. By doing so, we can ensure a thriving ecosystem with diverse solutions instead of restricting users to “official” contracts. Maybe you could even consider adding a UI that can interact with esf.tools to mint 3rd party subs.

For the V3 app, a modular design allowing external registrars to plug in seamlessly could be a step towards creating a more inclusive environment. This would enable the community to collectively decide on integrations based on the unique benefits they offer.

While community input is valuable, it’s essential to support external builders and acknowledge that the presence of “official” contracts may hinder the growth and diversity of the ENS ecosystem.

Also my experience is that you’re happy to take my help and direction for stuff that suits you but unwilling to give me anything in return… This makes me sad.

2 Likes

Yes, @jefflau.eth, I was under the same impression as @hodl.esf.eth. It’s one of the main reasons why we decided to build on ENS. It’s an open avenue for innovation with ENS providing just the tools and infrastructure to build upon, and we get to build and play.

For example, @Theth.eth we’ve already built what you’re asking for :slight_smile: testing it now and wrapping it up before we publicly announce it and open our app for alpha testing with the community. Happy to show you around if you’re interested.

Overall, it would be beneficial to know what are the plans of the ENS team (some roadmap possibly) so we can avoid building something that’ll be included in the main manager app.

3 Likes

I know you have built something, but without some direction nobody will find it, we know it’s there as we are into ENS, newbies won’t find it

A pop up on the ENS App could say “smith.eth isn’t available, but this web page is selling subdomains of it” and then link to it

1 Like

This is an excerpt from a post I made in september.

I want to introduce or explore the idea of implementing a team or process that would authenticate, approve and audit the contracts that will be supplementary to official ENS deployed contracts.

This will act as mechanism to achieve the following:

Evaluating the proper use of contract functions

Ensuring that public view of contracts are verified on chain and accessible and readily available for

  1. viewing and evaluating
  2. establishing an entrusted seal of approval by audit
  3. continuance in practicing the principles of true decentralization by open-source transparency

Prevent any contracts that incorporate ENS namespace functionality from malicious intent. (i.e, exploitation, credential hijacking etc.)

Achieving the adoption and consistent utilization of the ENS namespace through current and future technologies, globally.

The most important aspect of decentralization is ensuring the open-source transparency and trust is extended to the subsequent entity that is building on top of the protocol. If we can not ensure the above items are reflecting those transparent decentralized principles, the the standards that shape decentralization will ultimately diminish over time. I think there is a common notion that decentralization will ultimately be 100% autonomous. I honestly don’t think that will be the case with regards to sub-domains.

When the sub-domain wrapper contract is officially put to use on the blockchain, developers will be pushing their own contracts along with it. Realistically, they can do what ever they want with their customized smart contracts. Since we havn’t seen how those contracts will be used with official ENS contracts, we don’t know what to expect. This is truly a critical moment for ENS’s proof to stand true to it’s word and uphold the reputation it has earned.

I believe it is imperative that we implement agency of endorsement. What would happen if some supplemental contacts are exploited from the use of another contract and compromises lets say 10,000 ENS names and their subsequent wallets? Who is to blame? How would we approach that subject ?. Again putting an audit team over larger organizations who plan to or already have achieved hundreds or thousands of sub-domain registrations with a seal of approval might be something to think about. Like I said above, we need to extend the standards ENS is providing in the wrapper contract with their supplemental contracts.

This isn’t about control, being big brother or oversight for the sake of. This is about attempting to prevent any sort of failure points. I’m not saying any contracts or on chain events contain that possibility. There is a lot at risk by many people and we should be doing everything we can continue being one step ahead. I’m confused how you aren’t in favor of this sort of thing. You have have already suggested this mechanism be put in place
[/quote]

Onboarding new users to ENS and retaining them is likely to start here rather than registering a TLD. The most important thing to thing about with all the extra functionality like fuses, emancipation etc, is that it may scare some users away if they don’t feel they can trust the third-party. It’s imperative to acquire that trust immediately or ENS may never see that user interested in ENS again.A visible display of ENS official approval may be an effective way to retain that users trust in third party registrars, just like @hodl.esf.eth was mentioning in a sense.

I think the challenge behind that is: how do you display an approval that corresponds with specific contract addresses without the ability for a malicious party to display a fake / counterfeit approval.

I think this definitely could be a way to do it. My intention for the subdomain registrar I wrote is partially educational, but also to get conversation going on an API/standard that all subdomain registrars could implement. This would make it far easier for our manager app and other apps to integrate subdomain registrars automatically.

There would still be an issue of preventing scam registrars etc as well if it was automated. The only other option off the top of my head would be to whitelist certain known contracts.

Also of the opinion that ENS should remain neutral in expanding a lot of unnecessary functionality and allow community members to implement this stuff to encourage capable builders/developers to stay developing with ENS vs going elsewhere that doesn’t feel like the devs are competing with the protocol they are building on.

Personally think just allowing it as a template for people to build off of and deploy them selves is better than ENS expanding V3 apps functionality … V3 app still has plenty of other issues. ENS still has plenty of other issues (branding, adoption, promotion) that should be focused on that the community CANT fix or do anything to really help … except shill ENS daily how they do.

As mentioned in this thread not only is it ENSVision that has developed similar code already but other community members.

It is much more difficult for an external/smaller projects to gain traction over an “official” implementation. Vision has fairly large community support but new and upcoming projects would be almost invisible imo.

That being said. Some kind of modular design as mentioned so maybe those smaller apps/teams have a chance of getting usage through the official app isn’t terrible but also seems to get messy with the introduction of black/white lists and managing registrars.

Flip side argument also - If there is an “official” implementation it becomes much less likely that other sub registrars would even get used even if there is a common interface. Why would someone use any of these if there is an official version ?

It probably completely removes the possibility for the devs who built these things to really make any $ with their own protocols fees on top of the users set sub fees. As we could assume ENS wouldnt charge fees on the “official” one ?

3 Likes

There don’t have to be any “black/white lists” or “managing registrars” I don’t think. It could just be an agreed-upon API of some sort. So if a contract supports these standard methods, then it could easily be exposed in the official manager app. So the name owner wouldn’t necessarily need to build their own UI if they didn’t want to (of course, maybe they still want to).

ENS can’t charge fees for your subnames, neither can ENS Labs. It’s not their name, it’s your name. So only you have the power to issue subnames, using whatever contract / fees / rules you want.

ENS Labs may have basic subname registrar contracts that anyone can use, similar to the default Public Resolver. (Incidentally, those contracts will allow the owner to decide between rental or “forever” subs, and what fees to charge, if any.) But just like resolvers, you don’t have to use those contracts, it’s up to you. Maybe you want to have a more complex fee structure based on the length of the name (which the basic ENS Labs contracts do not support currently).

If you meant that your contract is going to have fees that kickback to ENS.Vision, on top of the fees that owners may want for themselves, well that’s certainly your choice as a developer of said contract. If it’s so incredibly awesome that everyone wants to use it despite the extra fees, then wonderful, win-win for everybody! But of course every name owner will have the freedom to choose what subname registrar they want to use.

We’ll also need some way for the UI to “discover” that contract, since it’s likely going to be an approved operator for the name, not the owner itself. Could just be a special text record?

1 Like

I think the maybe the intention is more geared towards a quick and obvious code verification --that would prevent a non technical person from accidentally allowing their wallets to be drained completely unsuspected.

I think that a whitelist/blacklist would play a different role in the sense of the usual use of permissions where as it wouldn’t restrict, block, permit or allow interaction…Would be a contract that you could query to see if the contract to be interacted with is or is not on a list.

Here’s just one example of a piece of the API we’d want to decide on:

Setup Domain

Current method in the example code:

function setupDomain(bytes32 node, address token, uint256 fee, address beneficiary, bool active)

The owner of a name uses this to activate, update, or deactivate their name in the subname registrar. The token is the ERC-20 token used for fees, and fee is the per-second registration fee for a name (or just the one-time registration fee, if it’s a “forever” registrar).

As you can see it doesn’t currently allow ETH to be used for fees (can use WETH though). Also nothing for more complex fee structures. What would that look like / what do prospective subname issuers want?

I had several ideas here, but probably the most common ones would be:

  • Min/max length restrictions
  • Length-based fee structure

If we take those into account, maybe the general API for activating a new name could be like:

struct Rule {
    uint256 minLength; // If zero, no minimum for this rule
    uint256 maxLength; // If zero, no maximum for this rule
    uint256 fee; // If zero, no fees for this rule
}

struct Mode {
    bool active;
    Rule[] rules; // If none, then no fees or restrictions
}

struct Name {
    // Both modes can be active at the same time
    Mode rentalMode; // Fee is per-second
    Mode foreverMode; // Fee is one-time for "forever" registration

    address token; // ERC20 token for fees, or use ETH if address(0)
    address beneficiary; // Where fees, if any, get sent to
}

function setupDomain(
    bytes32 node,
    Mode rentalMode,
    Mode foreverMode,
    address token,
    address beneficiary
)

Using this, name owners would be able to:

  • Have both rental and “forever” options active at the same time, with different rules
    • Example: $5/year, or $100 up-front and own permanently
  • For each mode, specify length-based rules
    • Example: 1-3char: $20, 4-6char: $10, 7-19char: $5, 20+char: free, etc.
  • For each mode, specify length-based restrictions
    • Min and max length for rentals
    • Separate min and max length for permanent registrations
  • Be able to use either ETH or an ERC-20 token of their choosing for the fees
  • Easily setup free subname registrations (no rules)
    • Can still have length restrictions though (use a single rule with fee=0)

Would this satisfy most use-cases?

2 Likes

To confirm, that’s not an API for the actual subname registrar, that’s your proposal for a white/blacklist for approved registrars, right?

Does that even need to be on-chain? There’s no way to enforce that, as any UI can choose to integrate any list of subname registrars that they want.

If we want such a list, I think we would just have DAO social votes for it. And ENS Labs could abide by those results and integrate those into the official manager app.

1 Like

I’m totally onboard with third-parties building subdomain registrars and interfaces for them. Delighted, in fact, since it allows us to spend time on other things that are less easily built independently!

I think that being able to register a subdomain inside the ENS App will be essential, though - and hopefully, mutually beneficial to ENS and the creators of these registrars. With that in mind we will definitely need an API, and I see people have already started discussing what that looks like.

Can I suggest starting a sub-WG for this and setting up a regular meeting to work on a standard?

8 Likes

On top of that as a possible user, I would love to see a function that automatically can extend the mother names registration with any sub purchased up to a certain amount of years selected, this is before any cut of the sale is paid to the owner

This reduces tax implications if the extension of the registration is made before the owners cut is given to the owner

Hopefully, that is understandable, not sure if it could work or how it could work, but would save on tax

I’m not sure I’m following that, can you explain with an example?

As an owner if there is a split of sales of a sub then the owner gets $$$

This creates a taxable event

Not every country calculates tax on end of year position if you are not a business, some you need to pay per taxable event

If you can use your cut to extend your name before it is due to you, then you do not create a taxable event, it’s an expense before payment, thus you don’t need to pay tax

If this wasn’t in place, you are paid the cut, this creates a taxable event, you need to pay tax on the income, then you need to use your $$$ after you have paid tax to then extend the name which in some countries or status might not be eligible for a tax reduction/expense

So you are saying just have an option to not send the fees to the parent owner, but instead use those fees to extend the parent name?

Yes, but something you could switch off after a certain amount of years registered if you wanted