Anti-squatting System for gno.land namespaces

[moul]

We need a generic anti-squatting system for r/sys/users to set up an automatic auction system. This will prevent squatting and ensure fair access. Initially, r/sys/users will remain invite-only.

How to Contribute: Submit a plan in plain English or pseudo code outlining the design of the anti-squatting system. Focus on creating a generic, importable library or realm. We will review the design before moving to full implementation.

XXX: Set a bounty

Related: #2189 #2827

[miguelito766]

Hi,

I'm not sure i got all the points but here's what i propose :

EDIT : I think i totally missunderstood the subject. Can you please detail what kind of behavior you would like to avoid ?

Goals :

• Prevent Squatting
• Ensure Fair access

Almost simplified Plan :

• The user needs to authentificate and sign a noop contract in order to watch the auction #This way you got a timestamp

  • The user got a token for his connection (AuthToken) that match with noop contract

• The system could match the given time (lets say 5min of connection) then disconnect with the user by AuthToken

• The user needs to connect back to the auction and generate another Noop/Token

• The auction site count how many times a wallet has connected and block access according to the fairness.

---

As a user, I want to watch an auction -> I need to sign to get an AuthToken
As the operator i define that the auction site allow X AuthToken for this Auction

My AuthToken could be like "Credits" -> 1 credit = X time of watching the product

Concept :

The concept of this is to implement two things :

• Log authentificate that can be useful in some cases
• A temporary token concept :
  • Matching a TXT/ID by the Log authentificate
    OR
  • Send back a token that burn himself after X time
    • if you don't have the token = NO ACCESS

Generic part :

• Create a no-op contract / Logs contract
• Create a package with the concept of AuthToken
  • ACCESS to something
  • TIME given by the token

To go further more

• Marketing / showcases an app
• Make token that are less volatile (2h of Time, splitted by login/out) by pointing login and logout to count
  • This way could be a SubscribeToken

[moul]

Thanks for your proposal. I think there's a bit of a misunderstanding about the scope of the anti-squatting system we're aiming for. The goal is to keep a potential permissionless system (like an auction system or similar) free from squatting. This involves:

• Preventing Multiple Registrations: Limiting people from registering multiple things (usernames, DAOs, etc) to park them.
• Safeguarding Precious Names: Protecting important names like "system", "admin", ...
• (Not sure) Managing Conflicts: Providing a way for famous brands to recover usernames related to their trademarks.

The solution will likely involve designing processes and having moderation DAOs. While advanced patterns like signing noop messages aren't necessary, a broader approach could include some proof of humanity mechanisms. However, the issue is open to any proposals. I'm more interested in reviewing various ideas than limiting the spectrum of possibilities.

Looking forward to more suggestions!

[thinhnx-var]

anti-squatting system idea - specs

In this proposal, I am thinking about things that possible with our chain, some ideas are inspired by other chains.
Lets start discussion:

Value Attribute:

A good namespace (ns) should have itself value, at least with individual user. Then every namespaces should come with a price attribute. Whenever someone want to register a new ns, an auction session is opened. If there is only 1 participant, then the default price is applied. The default price can be pre-defined by contract r/sys/users, or defined by DAO vote. For determining this price attribute, and prevent spamming coins to get all the ns, I prefer using Auction.

Auction format:

I prefer the sealed bidding auction format:

• 2 phases of commit: in the 1st phase - bidding phase, commit your encoded-price, which required a salt variable. After a duration, lets say about 1 day / week the duration may be flexible, and should be set by something like DAO for famous / important namespace, the session runs to 2nd phase - reveal phase which participants need to commit their salt value, in oder to reveal the price. The argorithm to encode/decode the price from encoded-price will be public. But the salt value is secret, and during the session, only user who submit the bid knows. This way we can mark the joining point of a participant.
• This 2 phases format help us keeping the privacy of sealed bidding, it is simple and transperent.
• I also propose to make an UI DApps - service which helping user a hand on creating the encode-price with their salt, showing the current status of bidding sessions.
• There should be a lock-down mechanism: locking amount of participant's coin till the end, and locking the transferable attribute of a ns after the session ends.

More anti-squatting:

• In the future, when the ecosystem can support, I am thinking about the Decentralize ID (DID) / KYC methodology, which can help us in many fields, and this anti-squatting system is a good usecase.

data-source about sensitive namespaces (DAO + realm):

• In this spec, I think we need a ns-data-source which contains the sensitive namespace, like system, bitcoin, messi ... public by a realms, data is pushed into that realm from govDAO voting, or oracle source. I am still working on oracle in our chain, and believe that this idea is possible and make sense.
• Whenever a registering for these namespaces is triggered, an additional action is required. The action may be voting, restricting, allowing... (can define later)

trademarks and conflictions (DAO + realm):

• In my opinion, we need a realm + DAO that let user registering their trademark, or iconic namespace, with evidences supplied.
• Whenever a confliction comes from sides, a DAO voting is required, depend on trademark is registered or not, we can start a new voting session that decide the owner of namespace.

In the early stage, I think we can try to implement the auction for sealed bidding idea, which required auction package, and service / dapp to interact with bidding session.

Maybe there are something I miss-understood, and I am looking forward to hearing from you, about anything from this proposal.
Lets point out what make sense and what does not.

[moul]

The anti-squatting system should be implemented at the same time or before the auction system, not after. If a robust anti-squatting system is not in place, we should use an invite-only system instead of an auction.

The anti-squatting system, once developed, can open the door to the next need: an auction system or a similar permissionless system.

[miguelito766]

Hello,

My attention have been caught by this sentence :

• (Not sure) Managing Conflicts: Providing a way for famous brands to recover usernames related to their trademarks.

---

In that situation, maybe we could link the NS registration with the public DNS registrar that will act like a source of truth.
The owner of the domain needs to add a TXT record to his DNS Zone in order to verify his domain name.

This might come with limitation (or solution ?) because the NS will be "famousbrand.com, famousbrand.net...." instead of just "Famousbrand".

This way you can't avoid scam domains like "gno.xyz, gno.net..." but at least you can certify that you are "gno.land".

---

• Preventing Multiple Registrations: Limiting people from registering multiple things (usernames, DAOs, etc) to park them.

Resolved by the way above. If your reserved domain haven't been claimed then its remain open to claim.

• Safeguarding Precious Names: Protecting important names like "system", "admin", ...

First you'll have a full name "gno.land" then you might reserve and attribute "shorter name" by proof-of-humanity system, moderation DAO etc...

Exemple : If i certified Famousbrand.com and i'm the actual owner i can ask a "shorter name" to get second check verification and get my final name "Famousbrand".

---

So the process could be :

1. Registration with a DNS name
2. Certify that you own the DNS name (First verify level) -> Permissionless
3. Ask for shorter name (Second verify level) -> Proof-of-humanity

Thanks for reading

[moul]

I like the idea of having a longer name easily, and then a shorter one (+ alias?) after more verification.

When working on this PR, I had this idea in mind: #2486

[AnhVAR]

I think we can mix the following ideas:
There will be two types of namespaces.

1. The first type is an unverified namespace, where users can register for free.

This namespace must follow the format: -.gno. This ensures that any user can register their own namespace, and anyone looking at it can recognize it as unverified due to the RandomString at the end.

2. The second type is a verified namespace managed by the core team.

After users register the first type mentioned above, if they have good activities, a strong community, regular users, and can complete KYC (Know Your Customer) or KYB (Know Your Business) processes, the core team will provide an alias short namespace by removing the RandomString for the registered and qualified namespace of the first type.

[thinhnx-var]

After reading your comments, I am now thinking about the idea that we have a longer namespace easily, and have a verified shorter namespace which will be managed by invite-only approach.
In summary, my idea is:

1. Having a type of longer namespace in a format like: yourbrand + random-fixed-length string. The random-fixed-length will be used as Unique-ID to specific the namespace. ( e.g.: gno-123abc, gno-abc321...)
2. Having a type of shorter namespace. Lets say yourbrand. This namespace is invited by admin - voted by DAO ... (humanity-proof). (e.g.: gno)

Users can start develope their contracts in type-1 namespace. And when they have enough users, have marketplace..., they will want to own their type-2 namespace. We will find the way to support porting from type-2 to type-1 namespace. This will helps them in save current status of their contracts, users, data...

In this way, we can help people know which namespace is trusted (type 2), and which namespace is in untrusted state ( type 1). And the squatting problem will also no longer exist, because the squatting does not make sense anymore.

What do you think @moul @AnhVAR

[miguelito766]

I like the idea of having a longer name easily, and then a shorter one (+ alias?) after more verification.

When working on this PR, I had this idea in mind: #2486

If you go on the domain verification solution, some questions will remain :

What happen when you loose your domain name ?
What happen if you delete the TXT verification ?

When you make a TXT verification, you want to check (every 24h for example) if the record is still alive, than delete the "certify/validation" if record is not here.

Possible solution :

• You might Auto-burn or Transfer the NS in order to put it again in "Open-to-claim" state ? -> Then the namespace will take back the wallet address ( gno.land/{p,r}/g1xxxx/ )

---

Regarding Alias, maybe you could link users wallets to a main wallet , when it comes to the the link process, you ask for your Alias ("Moul") to be linked : gno.land/{p,r}/gno.land/moul

---

Process for antisquatting :

Situation :
I am the owner of gno.land domain name and i want to bring my team on gno.

Permisionless Process :

• I create a wallet for my domain # g1xxx
• I register my domain (DNS) on gnoland -> gno.land
• I receive a token wich i need to put on my domain records -> I create a new TXT record with that token on my DNS registrar
• After an auto-check i claimed the NS to my wallet # Link between g1xxx and gno.land

--

• My teammates create there wallet # g1mmm - One wallet per user
• They send an approval to the main wallet with the alias name desired # Link between g1xxx and g1mmm

Proof-of-humanity Process :
(- I've done the permissionless process) # ? TBD - but could be a 1st step in order to open a request

• I'm now able to ask for a shorter NS
  - PROCESS TO BE DEFINE -
• I finally got my final shortname : gno.land/{p,r}/gno
• The Alias linked to my main wallet are child of my NS : gno.land/{p,r}/gno/moul

Warning with this solution : the gas used could be important if nobody has NS # gno.land/{p,r}/g1xxxx/g1mmm (longer path)

[moul]

I opened an issue on r/sys/users (#2827) to focus the discussion exclusively on an anti-squatting system. Ideally, this system should be pluggable as a p/ and not limited to r/sys/users.

The anti-squatting system should (probably) not rely on DNS verification.