RFC - Decentralised Naming System IV - inhibiting domain squatting (happybeing)

Ways To Limit Domain Squatting

I propose the following mechanisms in some combination - for discussion - though not necessarily to be used all at once. There is quite some scope for variations on these ideas but I’m sticking to the basics for now.

Note: I’m assuming the DNS is implemented using Structured Data (SD) items, paid for at registration by the user (a very small network fee, but planned to be 10x the normal PUT rate). Once created, changes to and SD item are free (unlike other data stored on SAFE where every “PUT” must be paid for according to the quantity of data stored.)

I propose the following measures to inhibit domain squatting:

  • an account must have farmed F Safecoin (Sc) per name it is allowed to register (e.g. F=1)
  • there be a network charge of C Sc to register a new domain name (e.g. C=1)
  • a limit of D domain names allowed per user account (e.g. D=10)

We can play with different values for F, C and D. It is obvious there are some problems with this, particularly with the variability in the value of Safecoin, but I think there’s a chance to address these if we put our minds to it. Below I explain the purpose of each limiting factor, and the problems I see with each one.

By all means point out other problems and/or solutions - but keep this topic based on the assumption that inhibiting squatting is desirable. We can discuss whether that is the case elsewhere (please :smile: ).

Farming Requirement (F)

The strongest inhibitor here is the requirement to farm F Sc per domain registered to an account. This is because domain squatting is a numbers game, and is more worthwhile as a business, and has the biggest negative impact, when it is carried out on a large scale. Setting a value for F of 1 effectively forces everyone acquiring a domain to provide significant resources to the network for every domain registered - proof of resource. This could slow considerably, and perhaps limit, the scale and impact of domain squatting without putting a domain name out of the reach of anyone who has at least the means to purchase network storage (which is a prerequisite for anyone who wants a domain name for their own use, rather than squatting).

I’m not sure how feasible it would be to implement this limit. There would need to be a way of tracking the amount of Safecoin farmed per account, which at the very least means that the close group responsible for a farming reward would have an extra task, of incrementing this count, and it would need to be stored somewhere.

Network Charge (C)

Requiring a payment for each domain helps to limit the number of names an individual is likely to register purely for squatting. The impact this has on squatting will depend directly on the size of the fee, but will at the same time impact other users once the fee rises above a fairly low level. The impact of this fee will also depend on the cost or difficulty of acquiring Sc (in resources and fiat). For these reasons, a flexible pricing mechanism might be needed rather than a fixed fee, which could be determined by an algorithm, but I’ve left my thoughts about that out for the time being.

If Safecoin becomes valuable such that C is more than say $10 SAFE domains become relatively expensive compared to the current internet which may have a negative impact on adoption.

If the price of registration rises further, say C above $100, those with little means will face a hard choice about what to do with their Safecoin, effectively pricing them out of access to the DNS. The can be mitigated by keeping C <= F, but if the value of C meant that domain registration rose to $100 or $1,000, the numbers of people able to register with the DNS would drop considerably which is against the values of SAFE (Secure Access For Everyone).

There are though two potentially beneficial side effects of a network charge to register a domain. The network fee would be recycled, which means returning the Sc payment to a pool that can be paid to farmers, and to reward publishers and app developers. It also creates a demand for Sc, creating utility and adding value to Sc.

Domain Name Limit (D)

As noted, squatting is more attractive the easier it is to scale. Limiting the number of domains per account makes large scale squatting harder, and may inhibit this activity.

Note: The network is potentially vulnerable to attackers who can create large numbers of nodes, so it is possible that unrelated measures designed to protect the network might also make it hard for squatters to create and manage the large numbers of accounts needed to manage lots of domains. For example, one defensive proposal is that an account must have 1 Sc deposited in it within a short period of creation or it will become deleted by the network. If that measure were implemented, it would cost an additional 1/D Sc per domain for anyone using multiple accounts to manage large numbers of domain name registrations.

Initially I suggested D=10 because I think it would be more than adequate for a very large number of users. However, we could set the limit much lower if we feel it will have a desirable impact. Even D=1 would not be particularly inconvenient for everyday uses, and for many users having one account per domain might make sense anyway.

Further Measures

The above measures have the side effect of encouraging users of unwanted domains (for whatever reason) to relinquish them. Even disregarding squatting, this is desirable because good domain names are limited in number, and so leaving them permanently unused is a waste of a useful resource, and will tend to make the SAFE network less “efficient” (e.g. harder to use) than it otherwise would be. On the current internet, an annual renewal fee has the same effect, since even though it is quite small for most kinds of domain.

Having an annual fee is stronger than the measures I’ve proposed, because it prompts a review by the user, and requires them to take action to retain the domain as well as to bear an ongoing cost.

For this reason, a similar mechanism could be beneficial on SAFE network, and may further discourage domain squatting as well. I’m not sure how feasible this would be, but it is also worth considering.

4 Likes

What about one domain free + 9 purchasable?
And we can add @dirvine proposal of being non-transferable.
I think all of this together it creates quite a disincentive for squatting.

*Unless someone ends up selling SafeNet credentials with valuable domains, but I think it would be limited to big brand names. The benefit/cost ratio would be positive (it would be worth the pain of creating several accounts and selling them) if they are targeting domains such as Cocacola, Google, etc…
But for the rest of squatters who wants to sit on a list of nouns, it won’t be worth it.

A simple solution, but quite restrictive, would be to only allow domain registration to those with hardware OTP tokens.
This would allow unique user identification and elevate the cost of creating new SafeNet accounts forcing one OTP token per account.

I do not like F. One shouldn’t be required to farm to use the network. Some folks may be good at farming, some folks not. We ought not assume everybody is going to want to do it, nor do we know with certainty that everybody will be able to do it. There may be plenty of folks with 200mb/s up and down that will outfarm most everybody with a DSL line.

C isn’t really a problem.

D isn’t right. One ought to be able to have as many domains as one wishes… If you need permission you are going against the values of the network. Also perfectly gameable… Just create a bunch of accounts.

I still suggest the search engines and registrars be apps within the network rather that embedded in the network itself. That way you can have competing schemes and the winner will emerge by market forces, rather than trying to engineer something that for a network that we really cannot see, feel or know how it will be used.

1 Like

I’m fully supportive of this - however in order to avoid hi-jacking Mark’s topic I’ve created another.

1 Like

I think that the whole squatting problem becomes simpler if we reimagine them as usernames instead of domains. This simple semantic difference can change everything.
We have to wonder why people aren’t registering brand names as usernames?
And why aren’t username squatters out there in forums around the world?

If we see the properties of usernames they are:

  1. Personal
  2. Unique
  3. Permanent
  4. Non-transferable

I think that by keeping it that simple, the disincentives become clear.
What @dirvine proposed would be #3, while @happybeing is adding a 4th factor: expensive, both in time and money.

I would like to focus on #1, to divert from the beginning from the concept of squatting altogether by focusing on subtle semantics and psychology.

There is a free association of domain → squatting. Even if there are safeguards against squatting, people will research ways of doing it anyways… because you are supposed to with domains.
It is like saying kitchen knives vs. butterfly knives, both can cut but only one is perceived as a weapon and related to gangs. It is all about branding and its association is strong enough.
So what about rebranding “domains” as “aliases” or something else to brake with that priming first?

Secondly, a username is personal.
Calling it “alias” or similar would indirectly suggest that it is a friendly way to reach them personally.
This way we divert the people’s attention and steer them towards its proper usage.
It is a costless desincentivizing layer that it is worth applying.

What if unlimited names are allowed per account but each subsequent name purchased becomes exponentially more pricey. Maybe ten domains is priced low enough for the average user but going past ten will start to cost a lot. Also, what if when a domain is purchased, part of the payment is held as a deposit that the user would get back when given up. This may make users actively give up their site when it starts to become unused, freeing up the name again

Hi, this would need measures against creating 20k accounts… linking to hardware seems one way though some some people would probably pay $$ rather than farm.

The easiest way to do this I think would be creating a non-transferable StructuredData (immutable owner field) and call it a DomainCoin or something like that. They wouldn’t be transferable, only destroyable by the network in exchange for a domain name. They would be issued alongside farmed SafeCoins.

That being said, I have my doubts that this would work as intended, as we’ll probably see farmers with a high DNS “allowance” starting DNS registration services in exchange for SafeCoin.

2 Likes

The problem I see with this one is that farming is a Vault-side function and account is a Client side attribute.

I don’t know if it’s been completely nailed down as yet, but as far as I can see, the only thing linking the farming to a Client is the safecoin address to which the Vault assigns successful farming attempts (i.e., the safecoin address registered with the Vault).

There really is no way to have the Vault and Client more closely tied. Otherwise accessing your Client Account from multiple devices would be impossible. Now, I guess there could be some sort of track in the Client account that “colored” safecoin received as having come directly from a successful farming attempt of a Vault farming on behalf of the Client, as opposed to having been sent it from another account, but that would be introducing something that I doubt we want.

1 Like

Do you think so, even with a limit on domains per account? It becomes difficult if the vault farming Safecoin has to be associated with the account which gains domain reg. credit. Farmers would need to be intent on being squatters and set up for this. So just being a big farmer doesn’t help.

You have to want to be a large scale squatter, and the price of this is farming a lot of coin. This helps to inhibit squatting compared to not having this requirement, which is the aim.

Some would no doubt be able to combine the two, but still less than would otherwise happen, I suggest.

Whatever number you assign to this will be a “magic number”. I’m not sure what place magic numbers have in this network.

1 Like

Again, here you come with potential solutions as opposed to finger wagging and derisive commentary. My respect continues to grow for you friend. :smile:

Here I thought janitors were supposed to clean the mess not add to it. :wink:

I been thinking and it has probably been said before, A general subscription of having a domain name expire every 3 months and having to pay a small amount of safe coin to renew it to increase safe coin circulation and farming rewards. This would cause a lot hassle for the squatter and deal with copied content.

I was an early adopter of the NXT network in it was in it hay day, they had alias names, many people register thousand of names, and then could resell the names on there nxt market. The only problem no one was interested buying the alias names and there was no market.

Maybe solve this with Farming or PUTting

If you are going to put up a site then its expected that you are going to put content up too. So either will suffice.

Could 1 PUT equals 5 x F. So if F=10 then 2 puts suffices.

Of course farming is separate/unrelated to accounts so that in fact Farming is not usable in this calculation. Farming vaults have a SAFEcoin address to pay into but otherwise unrelated. Many accounts can use the same SAFEcoin address. So even if one tried to backtrack its not a 1-1 relation, but many-to-many

F seems like a small price to pay for name registration in an otherwise chaotic system. I agree that it creates a greater barrier for entry but it would only be required from those who desire a domain name. Farming is designed to be feasible for even the smallest computers. Proficiency shouldn’t be a problem as

1 Like

No guarantee that design and practice line up in the long run though…

The problem with decentralized systems like SAFE is that they are very hard to fix afterwords… If somebody is making big business farming you will probably need their support to fork onto something less profitable and more egalitarian.

Nobody has built SAFE before, so we ought not expect it’s economics to flow according to plan…

Agreed. We need to be cautious and plan for adjustment - this applies to every aspect of the network though. With regard to DNS, it suggests we’re better following something known where we can, so a solution that it’s similar to the existing model is implied rather than something untried unless there are good reasons for this.

I do agree that domain names should be paid in any form of safecoins.
Example: 1SC / 1 domain name.

Not sure if anybody have proposed it but one small idea from me :).

Why not to allow anybody to register any domain name he/she likes?
During the registration the network should assign order number to the domain name person is registering and should store it on the network.

Example:
I do want amazon.
I am the first to register amazon I pay 1 SC and I receive my amazon0.

The second person pays 1 SC and receives amazon1.
The third person pays 1 SC and receives amazon2.
Etc…

If I want to refer to these domain names and resources pointed to these domains via any app I could do in such way:

Example:

safe:www.amazon:0/pictures/1.png
safe:www.amazon:1/index.html
safe:www.amazon:2/robots.txt
Etc…

So we have lots of amazon domain names with www services.
I have used the second “:” just for usability to represent the number of domain name in visually pleasant way.
We also can create associations to the people that order number matters equally as domain name to receive the recourse.
One getting wrong you will not be able to access resource from the network without third party help.

Because this network will be new, from the beginning we can start teaching people to refer to resources by domain name and by domain number. Domain number to the person will not be meaningless.

For example we have charityorg with its real members. A lot of scammers will register

charityorg:0
chartiyorg:1

charityorg:1289466
Etc… (total 1289466 SC paid :slight_smile: )

to scam people. But the real charityorg organization from the start of its activity on the safe network should represent to its current donators its new safe domain name and number via different communication channels.

For example on the thank you card organization could announce their new website for example:

safe:www.charityorg:6
(we are accessed - only via number 6 )

(I guess when network evolves there will be directories, SE’s, trust centers, automated assistant services that will address this issue so it could be harder to impersonate the real business or service).

Should there never be - safe:www.amazon/index.html?

For branding purposes I do agree that huge business and big brands owners should buy their brands on the network by putting lots of SC’s :slight_smile: on the network :). Actually they should be able to buy safe pointer to their safe domain name.

For example:

Amazon got 1 year later to the game and purchased domain name - amazon2011 which www service could be accessed via safe:www.amazon:2011

Amazon for obvious reasons :slight_smile: still wants to operate safe:www.amazon

All Amazon needs to do is to put the +1 more SC’s on the network than competing agent on the network to get the pointer

amazon → amazon2011

Now when people hits for safe:www.amazon they do receive safe:www.amazon:2011 content. Amazon can operate its business but to secure from any pointer overtaking attack should put lots of SC’s on the network.

I guess there would be needed smart contracts within the network to manage competition for the pointers.

Hope my thoughts will help :). Sorry for my English!