gno icon indicating copy to clipboard operation
gno copied to clipboard

Anti-squatting System for gno.land namespaces

Open moul opened this issue 1 year ago • 15 comments

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.

Related: #2189 #2827


Bounty Size: XXL; expected maximum reward: $16,000.

Find out more on the bounty program. If you participate with intention of receiving the bounty, you must agree to the Bounty Terms and Conditions.

More bounties | Contributing guidelines

moul avatar Aug 24 '24 09:08 moul

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

miguelito766 avatar Aug 25 '24 21:08 miguelito766

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 (#3020). 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!

moul avatar Aug 27 '24 15:08 moul

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.

thinhnx-var avatar Aug 30 '24 07:08 thinhnx-var

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.

moul avatar Aug 31 '24 17:08 moul

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

miguelito766 avatar Aug 31 '24 19:08 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: https://github.com/gnolang/gno/pull/2486

moul avatar Sep 03 '24 13:09 moul

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: <User namespace>-<RandomString>.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.

  1. 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.

AnhVAR avatar Sep 04 '24 13:09 AnhVAR

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

thinhnx-var avatar Sep 04 '24 14:09 thinhnx-var

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)

miguelito766 avatar Sep 06 '24 10:09 miguelito766

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.

moul avatar Sep 21 '24 14:09 moul

@moul I set an XXL bounty on this one; if you think it's insufficient, we can bump it to the next level.

thehowl avatar Oct 04 '24 10:10 thehowl

This is a must-have for r/sys/users/v2, after the launch, but not for the first launch. In the meantime, we can postpone it.

Must have issue: #2827

moul avatar Oct 15 '24 14:10 moul

Linked with #3020

moul avatar Oct 24 '24 21:10 moul

review my changes @moul

sudhanshu112233shukla avatar Jul 28 '25 08:07 sudhanshu112233shukla

Related to https://github.com/gnolang/gno/issues/4937

Kouteki avatar Dec 03 '25 17:12 Kouteki