Is having a single Public ID really a good idea?

Features
1

Hey all, I first heard about the MaidSafe project a few months ago, and was super interested in it. When the Alpha came out, I tried it and loved it. The experience was very smooth and I had no problems with creating a small website and uploading it to the network.

However, one thing struck me as strange, and that is the purpose of the Public ID. I don’t know a lot about how this works, so please correct me in the comments if I misunderstood something! It seems like having a single ID, as I understand it, will have major issues relating to privacy and usability.

— The Privacy Issue —
Right now, it seems like your account can only have a single, unchangeable Public ID. Say my name is John Smith and I make my Public ID jsmith33. Now, I can easily host my own website at www.jsmith33.safenet. I can run a blog at blog.jsmith33.safenet. So your Public ID is sort of your main domain name for the websites you create.

It also seems like, from what I’ve read, the apps you use can utilize your Public ID. So on a “Safebook” app, all of your pictures, status updates, and friends are tied to “jsmith33”. On a “Safetube” app, all of your videos and uploads are tied to “jsmith33”. And so on.

However, this worries me. Won’t this type of system severely undermine the privacy and anonymity ideals of the SAFE Network? If everything I make is tied to a single unchangeable username, anyone who knows that name can find me on any app I’m using.

To get a different Public ID, you would have to create an entirely new SAFE account, which has its disadvantages. For one, I read somewhere that when the network is released, it will cost Safecoin to create a new account. Additionally, it seems like it won’t be possible to be logged into multiple accounts at once, which makes the system incredibly inconvenient for those seeking improved privacy.

I mean, suppose John Smith uncovers something like Edward Snowden did. If he leaks the information on MaidSafe using “jmsith33”, which is connected to his “Safebook” and “Safetube” and what have you, it doesn’t matter if the network itself is decentralized: He’d still have the feds knocking at his door for whistleblowing, wouldn’t he?

— The Usability Issue —
Aside from the privacy concerns, I also have usability concerns. For example, what if John Smith creates a video game, named vgame2000, and wants to create a website for it. Should he host it at “vgame2000.jsmith33.safenet”? That’s not a very pretty URL. Preferably he should be able to do something like “www.vgame2000.safenet”, where the main domain name is reserved purely for vgame2000, instead of a subservice for jsmith33.

Admittedly, this is less of an issue, because an alternate account can be created (like I said earlier) to push the new website out. But this still seems like a bit of an inconvenience.

— Summary and Recommendation —
In short, having a “One Username to Rule Them All” approach looks good and convenient on paper, but is it? It sounds like a recipe for centralization of user data under a single ID, which is antiethical to the MaidSafe vision.

If I had any say in it, I would propose breaking up the Public ID into two separate parts: a DNS ID and Username ID. You can have a one “Primary ID” for each parts, for free, when you create your account. The DNS ID would be used for your personal URL, and the Username ID can be used by Apps.

Furthermore, you can purchase/rent, for a Safecoin fee, more IDs of either type. So if you want a new website for your video game, you can purchase/rent a new DNS ID within your account for the game’s website. And if you want stricter anonymity, you can purchase/rent a new throwaway Username ID.

That way you could easily have one website URL, and 5 Username IDs. Or 3 website IDs and 2 different Username IDs, which are all tied to and usable from a single SAFE account.

That’s just my two cents, and I’d love to hear other’s thoughts on this matter!

2

It’s a demo app limitation, we’ll be able to make multiple public ID’s later. It’s actually already possible, if you use a different app or write some code manually.

6 Likes
3

Ah, okay! Thanks for clarifying.

4

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

5

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
6

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
7

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
8

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.

9

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
10

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.

11

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.

12

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.

13

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.

14

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
15

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.

16

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

17

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
18

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.

19

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

20

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

1 Like