search

gnolang / gno

Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + gno.land: a blockchain for timeless code and fair open-source.
https://gno.land/
Other
895 stars 374 forks source link

Anti-squatting System for gno.land namespaces #2727

Open moul opened 2 months ago

moul commented 2 months ago

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 commented 2 months ago

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 :

Almost simplified Plan :

---

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 :

Generic part :

To go further more

moul commented 2 months ago

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:

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!

thinhnx-var commented 2 months ago

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:

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

trademarks and conflictions (DAO + realm):

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

AnhVAR commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 :

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 :

--

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

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

moul commented 1 month ago

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 commented 1 month ago

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

moul commented 3 weeks ago

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 commented 2 weeks ago

Linked with #3020