Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Anti-squatting System for gno.land namespaces #2727

Open
moul opened this issue Aug 24, 2024 · 13 comments
Open

Anti-squatting System for gno.land namespaces #2727

moul opened this issue Aug 24, 2024 · 13 comments
Labels
bounty/XXL XXL bounties: $16000 bounty

Comments

@moul
Copy link
Member

moul commented Aug 24, 2024

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

@miguelito766
Copy link

miguelito766 commented Aug 25, 2024

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
Copy link
Member Author

moul commented Aug 27, 2024

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!

@leohhhn leohhhn changed the title anti-squatting system Anti-squatting System for gno.land namespaces Aug 28, 2024
@thinhnx-var
Copy link
Contributor

thinhnx-var commented Aug 30, 2024

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
Copy link
Member Author

moul commented Aug 31, 2024

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
Copy link

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
Copy link
Member Author

moul commented Sep 3, 2024

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
Copy link

AnhVAR commented Sep 4, 2024

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.

  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.

@thinhnx-var
Copy link
Contributor

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
Copy link

miguelito766 commented Sep 6, 2024

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
Copy link
Member Author

moul commented Sep 21, 2024

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.

@thehowl thehowl added the bounty/XXL XXL bounties: $16000 label Oct 4, 2024
@thehowl
Copy link
Member

thehowl commented Oct 4, 2024

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

@moul
Copy link
Member Author

moul commented Oct 15, 2024

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

@Kouteki Kouteki added this to the ⏭️Next after mainnet milestone Oct 16, 2024
@moul
Copy link
Member Author

moul commented Oct 24, 2024

Linked with #3020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bounty/XXL XXL bounties: $16000 bounty
Projects
Status: 🎯 Current Topics
Status: Triage
Development

No branches or pull requests

7 participants