Optional Platform Source Parameter for Registrar Controller

[slobo.eth]

Intro

Knowing which website registered a .eth name would be useful, like knowing how many registrations were done via ensfairy.xyz.

We can leverage the existing contract and create a social convention to get visibility into the platform source.

How

The ETH Registrar Controller takes the following input data. Let’s use the registration of loompa.eth as an example.

#	Name	Type	Data
0	name	string	loompa
1	owner	address	0x534631Bcf33BDb069fB20A93d2fdb9e4D4dD42CF
2	duration	uint256	31556952
3	secret	bytes32	0xb7b31b6b95633cbcc635528d3b7196bc89d13566c1be2068af0cad6fb3ecebf0
4	resolver	address	0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41

The secret parameter is random data that obscures the name before the final step of the registration process is complete.

It is 32 bytes of entropy and the ens manager app on app.ens.domains generates it by calling the following:

require('crypto').randomBytes(32)

We can adopt a social convention that generates the secret from a combination of taking the first 10 characters of sha256(‘platform_name’) and combines it with the appropriate number of random bytes.

This way the first 10 char of the secret would be the platform name. So for example if the above was registered via ensfairy the secret would be:

0x1b7f8b612c633cbcc635528d3b7196bc89d13566c1be2068af0cad6fb3ecebf0

The bold part is the first 10 characters of sha256(‘ensfairy’)

With this we can attribute registrations using the first 10 chars of the secret.

Objections

Can’t anyone use someone else’s platform name?

Yep 100%, I don’t see this as an issue.

Given that economic value could accrue to the top platforms there would be an incentive for the major players to play ball.

Request

Feedback is appreciated.

Thanks

@AvsA & @serenae helped formulate this idea and post.

[gregskril]

I think this is a great idea! Opt-in way for developers to get on-chain analytics without adding any cost to the user.

It seems fairly straightforward for devs to implement as well. Just prepend the platform name in hex before (32 - platformBytes) random bytes as you suggest. Not sure if this snippet is optimal, but seems to work after a few minutes of playing around:

const utf8ToHex = (str) => Buffer.from(str, 'utf8').toString('hex');

const platformHex = utf8ToHex('ensfairy')
const platformBytes = platformHex.length / 2
const randomHex = require('crypto').randomBytes(32 - platformBytes).toString('hex')
const secret = '0x' + platformHex + randomHex

console.log(secret)

I think this would then allow anyone to query Dune Analytics and find all registrations where platformHex is included in the secret.

I’m going to play around with this some more to try to get a working Dune query, but cool idea regardless!

---

Update: It’s possible with Dune, but rather slow at my first attempt (the linked demo will be fast because it’s only checking recent blocks).

I’m sure there’s a better way to do it in Dune, but I’ve also been playing around with sort.xyz (an API-first version of Dune) recently and it seems to work much faster for this since they decode all transaction data into strings. Here’s the Sort query with more rich data.

[AvsA]

Since I’ve talked with Slobo about it, naturally I think it’s a very positive idea.

One important point is that the goal of the secret is just to prevent someone from figuring out the name you want by brute forcing it, so the reduced entropy wouldn’t matter that much.

This has basically no downsides I could think of but allows all sort of new features: analytics of registrars, leaderboards of clients, maybe even prizes for the top ones. We should start implementing it today.

[garypalmerjr]

Just to ask:
Are there any privacy concerns, for users or the ENS names, “down the road”?
…ie: negative externalities connecting a name to an origin website?

[zadok7]

This is a really neat “hack” and is a resourceful idea, since the user would not incur any other costs. Genius to use the secret key for this extra functionality. Also agree losing a little entropy doesn’t matter here it seems as @AvsA mentioned.

@garypalmerjr

Are there any privacy concerns, for users or the ENS names, “down the road”?
…ie: negative externalities connecting a name to an origin website?

This is the only possible drawback. I guess just registering a name through the ENS App would be the alternative doing it on some third party origin site.

Another option is for the origin registrar sites to integrate some kind of “opt-out” function, where the secret key will be completely randomized, ie. not give credit to the origin site… Maybe the dApp registrar website has incentive for the user to allow the source platform to be known though. A give away, or whatever way they want to get people to not un-check the platform origin box. This could be done at the application level by the developer I’m pretty sure.

So let’s say your web3domains website integrated a registration function into it. I think you’d be able to have a toggle switch built to tell users that they can opt-out of their registration being associated with web3domains. Also, once a name expires, and gets re-registered, it will of course have a new secret key + platform source.

[5pence.eth]

This is a pretty cool idea. It’s a decoupled and non-destructive way to gather data that the DAO could evaluate for action/funding. It’s fully “opt-in”, and if a site/tool doesn’t want to participate they just simply don’t implement the change.

Am I correct that this wouldn’t really need any DAO approval or TNL involvement? This would be something that the websites/tools could fully implement on their own if they chose to?

@garypalmerjr

Are there any privacy concerns, for users or the ENS names, “down the road”

Good thought. If this was implemented, a subset of ENS records would have an on-chain reference to the website or tool used to register the domain. It’s tough to know if that could be significant down the road or not. It’d be good to hear more thoughts on this.

@zadok7

a toggle switch built to tell users that they can opt-out of their registration being associated with web3domains

Interesting idea that a participating website could allow “opt-out” on a per registration basis. I’m guessing this would ultimately be up the individual website as to if they wanted to implement the choice?

[zadok7]

@5pence.eth

Interesting idea that a participating website could allow “opt-out” on a per registration basis. I’m guessing this would ultimately be up the individual website as to if they wanted to implement the choice?

Pretty sure yes, because it’s generated by the app itself and sent to the Registrar Controller.

This brings up a question though, @slobo.eth would the ENS App prepend its own platform id into the secret parameter? Or would this just be some kind of optional flag that devs could decide to use or not use if they were building their own registrar dApp?

[slobo.eth]

@zadok7

This brings up a question though, @slobo.eth would the ENS App prepend its own platform id into the secret parameter ? Or would this just be some kind of optional flag that devs could decide to use or not use if they were building their own registrar dApp?

I can see it both ways, you can even make an argument that they should not use this.

@garypalmerjr

Are there any privacy concerns, for users or the ENS names, “down the road”?

There are always privacy concerns with any additional data. They are addressable and tractable though.

This has already been implemented on ensfairy.xyz. @gregskril

I’ll see how this thread evolves but I’m leaning towards encouraging folks to give it a try on third party front ends.

[AvsA]

@zadok7

would the ENS App prepend its own platform id into the secret parameter ? Or would this just be some kind of optional flag that devs could decide to use or not use if they were building their own registrar dApp?

I would argue for large platforms, like the ENS app, to use a mixed solution: perhaps using the first 4 chars to denote it’s own ID and then prepend it with 6 other chars to identify a referral code, set by clicking a link with the referral. This way we can still have the data of who referred to the website but also we can aggregate data on how much the app itself is being used.

[zadok7]

@AvsA

I would argue for large platforms, like the ENS app, to use a mixed solution: perhaps using the first 4 chars to denote it’s own ID and then prepend it with 6 other chars to identify a referral code

So then as an example, Rainbow wallet that allows registration of ENS names would be considered a “large platform”. So the first 4 characters would be a Rainbow wallet id. Then the next 6 characters would be for referral codes for Rainbow to use? That way a referral could be tracked upstream.

Rainbow is just an example I’m using of course. I have no idea if they will use referral codes or have a referral program, etc. One last thing though, I think I’m right on this math… but if we use 6 places for the referral code, then that is 6^16 = 16.7M combinations

Maybe the referral codes should be 7 length instead. 7 is a neat number, plus you then have 268M available referral codes.

Or does that mess up the entropy of the secret parameter?

[serenae]

There’s probably plenty of room there given that the secret parameter is only used short-term to prevent others from guessing what name you’re registering. But probably best to keep it to whole bytes so that various implementations don’t have to write awkward code.

Platform ID: 2 bytes (65536 values)
Referral Code: 3 bytes (16.7 million values)
Remainder: 27 bytes (1e65 values)

Or maybe

Platform ID: 2 bytes (65536 values)
Referral Code: 4 bytes (4.3 billion values)
Remainder: 26 bytes (4e62 values)

[AvsA]

We should then simply increase the field for 6 bytes. It’s more space for both and since it’s expressed in 12 hex letters, it can be represented by two colors on the UI.

655536 values might not be enough for platforms thou, because of the birthday paradox. If there were just 256 creators of codes then the chances that 2 of them will randomly have the same hash code is about 39%.

We could also ask, instead of being a sha256(name) that it should instead be the first nth digits of their name hash, so it’s easier to know who to talk or send grants to (although it should be relatively easy to figure out a valid ens name with a colliding hash prefix).

[serenae]

Makes sense, so 3 bytes for the platform ID and 3 bytes for the referral code then?

[nick.eth]

@AvsA

655536 values might not be enough for platforms thou, because of the birthday paradox. If there were just 256 creators of codes then the chances that 2 of them will randomly have the same hash code is about 39%.

Why not issue platform IDs sequentially? Then just one byte should be enough.

[AvsA]

We are having the same discussion in two links now: ENS Improvement Proposal: Platform Source Parameter - #4 by AvsA

[garypalmerjr]

Three?

ENS Affiliate Marketing - Affiliate Program

Hello, I am interested in chatting about referral systems with ENS protocol. In America, Referral systems are legal IF the referral system is only one (1) level. …after one (1) level, it becomes a pyramid/MLM, …so only the direct referral is rewarded. For ENS, I want to discuss the opportunity of a single-level referral system, …so any 3rd art site/dApp that sends users to buy an ENS name is rewarded with referral. ( This is a very tempered, very common, very reasonable mechanism in digital…