I’ve add some more details on the NSL solution.
I address some of the issues you raised.
Thanks for to all who addressed my previous questions, very much appreciated helped me a lot to understand things better.
I have another doubt/question also somewhat related to POH: As MaidSafe network aims to is be an alternative internet, then I assume it will be used similarly. In our current internet only a smaller fraction of people run servers/websites with sizable amounts of data even when including those that, say, upload big youtube videos etc. The majority of people just consume the information without storing it other than temporary caches.
How is it envisaged that the Safe network handle the vast horde of data consumers, those that just want to fire up the “SafeBrowser” (benjaminbollen cool idea from this other thread) and surf to some information available on the Safe network - watch videos, read some safe-webpages etc? If they have to jump through POH and account setup procedures it may be a impediment to adoption compared with the current model: where all you do is choose a browser, start it and start searching/clicking.
1 Like
If people are pure consumers they do not even need to login at all. So in that case you are like a TOR browser person. There is no cost and no pain involved in consumption only.
The difference would be though, if you engaged with a site then it’s best to have your session and keys. Then you can login to any site and even make orders and purchases (note login is click login and that’s it, your keys will authenticate you automatically, so site passwords ever again).
3 Likes
Like David Irvine has mentioned, we will have 2 modes when connecting to the Network.
I’ve nicknamed them to express their function.
Browser Mode: used by anyone who only wants to view data. Most likely, these will be mobile devices: tablets, cell phones, laptops. No Network login required.
Farm Mode: used by anyone who wants to upload public/private data, and provide storage space for the Network. These connections will have a login account and can earn safecoin while they are connected.
1 Like
This is important and even if we cannot make these people farmers right away. They will be as we progress so yes a clear distinction. Good point @dyamanaka
I read there is a clear intent to make phones farmers too (edit added: way down the road). I get that browser mode allows you to view public data. But at anytime I want to view private data, or write (public or private) data, I should login clearly. That doesn’t make me a farmer at that point.
A farmer needs to login to the PMID, the vault identities, right? so that seems like a separate ‘login’. Im a bit confused by this division.
So maybe browser mode, connected mode and farming mode?
Good point,
I was only aware of 2 modes, but yeah, there should be a distinction specifically for farming.
- Browser Mode = Read only public data
- Login Mode = Read/Write public and private data.
- Farm Mode = Actively contributing POR to the Network.
4 Likes
Suggested user oriented terminology:
Visitor: 1. Browser Mode = Read only public data
User: 2. Login Mode = Read/Write public and private data.
Farmer: 3. Farm Mode = Actively contributing POR to the Network.
Note: Farmer is also User is also Visitor
1 Like
We are currently discussing a vending machine style setup. If we can do this successfully, there will only be 2 modes. Visitor and User.
1 Like
In the pure consumer “Browser”/Read only public data mode (no logins) - will the client cache the data downloaded and more importantly from a performance point of view - will those browse-only clients forward data to anyone else that requests the same thing from the network. Effectively even in browser mode help contributing to delivering the data smoothly.
I ask as I am wondering what would happen if for example some region of the world cracks down on “full” MaidSafe installs/accounts which serve data - makes them illegal or whatnot - would the data consumers still help the network perform well through cache and forward, or could it create a bottleneck if consumers far out-way clients that serve data in the region (assuming the region has poor overseas connections as they always seem to).
Mostly off-topic idea you guys have probably already covered: I could envisage the case where a user would never want a local IP address in their routing table. Options like “connect to MaidSafe network but never directly with IP addresses in [Insert Repressive Country Here]”.
Think it has to be (I cannot think of a way around it yet, without specialised hardware). The issue will be that it is only known to it and the connected manager group. The IP disappears on the first hop.
In the other parts of the questions, I am really holding out a lot of hope for off earth connections, but for later. In terms of oppressive regimes the network uses what looks like pure UDP and on different ports each time. This should be as hard as TOR to break and we need to make sure this always improves. I know some of the TOR guys can provide great experience here and hopefully they will.
So yes a weather eye needs to be kept open here at all times. 
1 Like
There is always the option of encrypted vpn to a node that is running maidsafe. This would be very easy to set up as a service for those that really need it.
I suggest only one type of user. Everyone needs to create an account to use SAFE network. And with that you can use all available public/free resources. If you need extra resources, or other you will need safecoins. To get them you can mine(available option once you have account), you can buy on exchange, you can make an app, or in the beginning you can get some for free (promotions, donation).
Other non SAFE users will use MAIDSafe through third party apps.
Does it make any sense?
I’m confused by the usage of “burned” on the MaidSafe forums. I think it is routinely being used in place of “recycled” which is not the same.
I think:
burned: destroyed
recycled: returned to the network as not owned/issued, so can be issued again
Anyone who is sure of the definitions, please either confirm or correct.
Thanks,
Mark (picky) happybeing 
4 Likes
The correct term should be “recycled.”
When we were formulating this strategy, I originally used burned but should have used recycled.
Blame it on the asian guy, lol!
2 Likes
Blame is a totally useless activity.
Thanks for confirming.
Your contributions continue to be magnificent and very useful to me. Thanks! 
3 Likes
Avatar captcha grid. The perennial problem with authentication divides into two paradigms:
- something you know (e.g. password, passphrase, security question) These are bad because they can be easily guessed or compromised.
- something you are (typically biometrics - facial recognition, fingerprint, voiceprint) these are bad because they are inexact, depend on special hardware (working sound recorder, camera, scanner) and the biometric data can be captured and copied.
What is needed is something that has the benefits of both and none of the drawbacks of either. The following idea would not work for the visually impaired, for reasons that shall soon be obvious:
It is well known that humans are able to remember a face after only one meeting, and recognize that face many years later without reinforcement. This ability to recognize a face - even of unknown persons - can be the basis of a login proxy service that resides in the DHT space that has two parts: a large database of validated but anonymized face images, and a hash store that authenticates on a correct selection of a random sequence of user responses to the challenge of being able to correctly identify a series of faces out of a large number of candidates. 100% correct, and not iffy or messy like biometrics can be.
Suppose, for example, upon registering for the proxy, one must undergo a fairly light training phase, where the user is introduced to a series of six faces, chosen randomly from a large database of nameless faces. These faces could be harvested from various openID avatar services and are continuously rated by users for validity when they are added. Validity means they are not cartoons or other non-human images, and not obvious celebrities.
After the introduction, the faces are replayed with other faces that are not members of the user’s login set, presented in a series of six, 6x6 matrices, only one of which belongs to his set, and the other 35 are random, until it is confidently demonstrated that the user has learned all six faces of his set without error. The order that the the 6 are presented is also random. This set of six faces is indexed in such a way as to form a key that can be matched. Simply, the key is composed of six factors which are hashes of each unique face in the database, probably just by hashing the raw stored image).
Again, only one face in a 6x6 matrix, which is 36 possibilities, is correct. A sequence of six matrices consists of 216 faces presented per login attempt, the total number of possible combinations out of the database is astronomically large, making it possible to have a very robust key. I am using the combinatoric reference function:
Combinations[1]: Picking a team of 3 people from a group of 10. C(10,3) = 10!/(7! x 3!) = 10 x 9 x 8 / (3 x 2 x 1) = 120.
and we plug in 6 of (6*36) choices: C(216, 6) , we get[2]:
a possibility of 1 in 1.31513824548 × 10^11
certain precautions are necessary to prevent analysis and exploitation of correct face selections:
the connection must be SSL
the "face base"will have to be supplemented by another large database of faces from the public domain (using only faces submitted by users as a condition of membership gives only n*n possible combinations, where n is the number of registered users - even 10,000 users gives 100 million permutations, which probably isn’t robust enough)
the face images should never be presented in the same binary form twice, that is, they should undergo various random transformations to modify the size, hue, bit resolution and color depth, noise and distortion, etc. Captchas already do this to a certain extent. individual images should be merged into one large image to make analysis and scripting more difficult.
the users own face shall not become part of his key; therefore if asked to submit his face to the database, it shall be done after the registration process.
a feedback alert should be presented to identify bogus images (since there should be millions of them) and with some consensus, flag them for permanent removal from the database, during the registration learning process and at every login.
there are two possible ways to select images:
- the user clicks on the face, returning imagemap coordinates that can be mapped to the image’s hash.
- the user selects by row and column labels of alphanumeric characters, using the keyboard. this method is preferable, since it is more difficult for someone standing over the user’s shoulder to identify which faces are chosen
feedback to the authentication server:
the hash of each selected image is securely sent during the challenge or all six at the end of the challenge.
the imperative is the feedback sent to the server has an infinitesimal possibility of being the same, twice. coordinates, if sent to the server, will simply be a set of integers with no meaning outside the authentication session. perhaps a better scheme could be done with encrypted hashes that are readable only to the authenticator bot.
So now we have a kind of “password” that is nearly impossible to be forgotten and is impossible to write down or conveyed verbally. the only risk is for a user to actively teach another person his login series - but why would he do that?
2 Likes
I should add regarding the question of people creating multiple accounts, I think it’s easy to see that it should become very difficult to manage more than probably two or three unique sequences of faces. Humans are not very good at that.
1 Like
8 Likes
lol…
2 Likes