Is having a single Public ID really a good idea?

I remember reading somewhere that the Public IDs will be transferable as well.

Using a public ID implies a loss of privacy, but situation is not as bad as you indicate:

  • An account can have several public IDs

  • An app doesn’t need a public ID

Public ID are used by core services such as www, messaging … for which you are specifically interfaced to public.

1 Like

Unfortunately for some reason David Irvine thinks it’s a good idea to limit the number of public IDs an account can have.
I think this is a terrible awful idea, and we need to be able to make as many public IDs as we want.

5 Likes

I would expect the ability to have multiple IDs but I would also assume they come with an associated cost and that they’re actually leased much more than owned.

The reason being simply that they will end up being a scarce resource on the network and to both discourage squatting and to not lose IDs forever due to inactive accounts it would make sense that holding on to the id comes at some recurring cost.

But I guess we’ll see how it all pans out, a per account limit would simply end up with people creating the number of accounts they need to hold all the ID’s they want. Probably to the detriment of the network as a whole.

2 Likes

Using a public ID implies a loss of privacy

True, but as long as it isn’t too difficult to use multiple IDs simultaneously, I’ll be a happy camper.

And yeah, I figure (and hope) individual apps choose not use Public IDs within them. I sort of imagine a Public ID as a rough analogue to an email address.

To make an account on a third party app on the internet, like Facebook, Youtube, Reddit, this forum, etc, you’d probably use the same email address. But, the individual apps/sites allow you to create a unique display name within them, and usually might keep your email address relatively private.

I hope that sort of mentality persists in SAFE; a Public ID to use for the creation of accounts across apps, like an email address, but then the apps let you hide that Public ID in favor of a custom displayname for that app only.

The only thing is that sort of choice is really up to the developers of the third party app: they can take the time to allow a new unique username on their app, or just take the simpler route of using your Public ID for it.

The only difference is that emails are a dime a dozen to create. If you want to make an account on a website that is a tiny bit harder to trace back to you, its really easy and trivial to set up a throwaway email account and sign up for the service using that.

I hope Public IDs would be just as simple to set up. Overall, I’m really excited to see where this project leads.

No, I don’t think it’s a bad/good idea to limit these … yet. I said perhaps as there have been historic discussions on that. It becomes only a pita of folks want them as they can create many accounts. So there are pros and cons on both sides. So I write a script right now, download a dictionary (like from john the ripper) and claim all known words and derivatives (within reason, but it’s 50Gb of words) and kill DNS usability etc. Then there is petnames also to be considered etc.

Other side is why not let somebody do that? I can see both sides of this, we can charge a lot per name, but what about the folk who have no or little safecoin etc. I think it needs properly discussed really.

So perhaps just means not yet set in code :wink:

1 Like

There are two issues here:

  • restricting the number of public ids is inconvenient
  • allowing unlimited public ids allows someone to squat on every one they can think of which is even worse

So we need a solution that limits abuse without being overly inconvenient.

The reason being simply that they will end up being a scarce resource on the network and to both discourage squatting and to not lose IDs forever due to inactive accounts it would make sense that holding on to the id comes at some recurring cost.

Yeah, the squatting is also an issue. Which is why I also think it would make sense to separate the Public ID like I described in my OP. That could help mitigate URL squatting. That way, using a new and separate “Username ID” would not squat a domain name as well.

So we need a solution that limits abuse without being overly inconvenient.

I just thought of this, but what if we have one primary Public ID that you can keep for as long as you want.

Then, you can create additional Public IDs for a recurring fee. The kicker is that each successive ID gets more expensive.

So, for example, the second Public ID you want would be 10 Safecoin.
The third (if you want one) would be 20 Safecoin.
The fourth would be 30 Safecoin, and so on.

This would make a squatting attack super expensive, super quickly, and the exact prices would change depending on the state of the network economy.

This allows for technically unlimited IDs, but prevents the squatting problem.

Of course, the prices don’t have to be linear. It might be better/more accessible to use some kind of logarithmic pricing as the number of IDs increases, instead of linearly like in my example above.

Or really, they could increase in whatever way is best for network security and ease of use.

Also, preferably each Public ID in a list that you own cannot be linked to any other. So if I have two Public IDs, like jsmith33 and jsmith56, it would be impossible for someone to know jsmith56 and jsmith33 belong to the same SAFE account.

Yes, there are various approaches, but none are perfect. For example, with your scheme what is to stop me creating a new account for every id I want.

The current idea is I think to require you to hold one Safecoin in an account if you want to create any public ids, and then for you to only be able to create a small number per account. So effectively no cost, and little inconvenience to most people.

But a script could still just keep moving Safecoin around from one account to a new account etc.

There are always loopholes so we need to debate this and try to come up with a solid and not too inconvenient solution.

BTW requiring Safecoin (payment or in wallet) isn’t great either, because what if Safecoin becomes very costly to obtain? We could switch to a PUT credit balance, but this too will vary in price over time.

Do you see none of this is easy? :slight_smile:

2 Likes

Yes, there are various approaches, but none are perfect. For example, with your scheme what is to stop me creating a new account for every id I want.

What about a simple captcha? I was thinking about this earlier, and of course people will still want to/need to create more than one SAFE account. When signing up, would it be too difficult to add one of those more modern Captchas, where, instead of typing in letters, you just tick a checkbox and it verifies your humanity? Like this. It’s very convenient and doesn’t get in the way. It also deters people from creating a bunch of different accounts at once, but still easily allows people to make more (for example, if you want a new account for your company, utterly separate from your personal account).

It would also put a stop to automated bots trying to create more accounts on the network.

Do you see none of this is easy? :slight_smile:

Yep, it definintely warrants a lot of discussion! Its definitely hard to find a good way to keep the system balanced from abusers, but still keep it free and flexible enough for well-intentioned users trying to increase their anonymity.

Captcha’s have also been suggested before, but how do you do this without the existing web and its captcha services? :slight_smile:

Unless it is the maidsafe foundation leading the charge on this, I am dead against it. People will profit off the backs of your hard work, with little effort on contribution on their part.

If it is going to be a free for all, at least let the foundation grab the interesting ones for resale first - that money could then be fed back into the making the network better.

However, I do think this is the right approach otherwise. You can then let the market decide there on out, with many new pastures/names to be found with a bit of imagination.

1 Like

I am not so sure about that. It costs Safecoin to squat and it is only worth it if it can be sold for more.

Yes, popular short names will potentially be worth a fortune, but I would support the maidsafe foundation grabbing the top few thousand of those before general release. The profits can then be ploughed into safe net.

I also think that renting names should be a proposition. If a name can be treated like a symbolic link to any data, then this becomes an interesting business case in itself.

The Id’s we now have are already locked id’s right or will they be reset again ?

They will be reset probably until there is a decision on initial creation cost or otherwise.

1 Like

@traktion you are missing the context (no cost).

good to know i was making my project id’s , will we get a update before this happens ?

I was thinking alpha would have the real (chain) already not with another reset

No, he isn’t. Currently creating a public ID cost one PUT because a SD is created. Some people think that it is not enough, but we cannot say it has no cost.