Issues with SAFE primer

Features
1

I read the SAFE Network primer but didn’t get one thing.

WHY USE A CENTRALISED PROXY SERVER RATHER THAN EXISTING P2P ANONYMITY PROJECTS LIKE TOR OR I2P???

Don’t say that this too has already been discussed.

2

What do you mean by centralised proxy server? That’s not how it works.

Its built in decentralised routing ensures anonymity.

4 Likes
3

Any visitors requesting resources from the SAFE Network needs to access the network through a proxy server. These were clearly written in the primer

4

A proxy node, not a server. It’s just a way of connecting to the network through a random point of contact. It’s not centralised, and is where your IP address is stripped.

If you can indicate the relevant text we can see if it needs clarifying.

EDIT: @JPL see below.

2 Likes
5

It is better referred to as a bootstrap node. Any node that can give you other nodes to connect to. We recently made this more clear in the code. So the process is

  1. You connect to any node.
  2. Ask for the nodes you should connect to
  3. It gives you closer nodes it knows of - recurse until the response is Join these nodes.

When joined client or vault can confirm the correct network via the chain of section authorities. It can go all the way back to genesis section if required.

The word proxy was confusing, it was valid in Alpha II but now it’s just a dumb bootstrap node and any vault can do it.

6 Likes
6

Clients connect via a Proxy Node

To ensure anonymity, the identity of a Client connecting to the Network must be hidden from the nodes (Vaults) that comprise it. For this reason, the initial connection between a Client and a Vault always occurs via a Proxy Node. The Proxy Node knows the Client’s IP address and will allow it to connect to a Section. The Vaults cannot see the Client’s IP address but they know its public key and XOR address. All connections between the Client and the Group(s) are fully encrypted.

The Proxy Node provides a service to the user, connecting him or her to the Network without having any knowledge of activity thereafter. The Group of Vaults to which the user is connected might know a little about what the user is doing on the Network but they can only identify the user by their XOR address and not their IP. In this way, complete anonymity is assured.

Taken from SAFE Primer

1 Like
7

It will be updated with Fleming.

8

What’s a Fleming???

9

Fleming will be the first working Beta release (named after Alexander Fleming). Thanks for bringing up the ‘proxy’ issue. I’ll amend the Primer in due course since we’re no longer using that term. I agree it has misleading connotations.

8 Likes
10

Also from the primer:

Bootstrap node – a node to which a new node (Vault) initially connects (via a proxy). Any node can potentially be a bootstrap node, so long as its IP address is written in the Vault’s configuration file

  • I assume this ‘via a proxy’ has to go?
  • Is the answer to the following question clear after replacing the ‘proxy node’ when reading the Primer?: Is there is a (relevant) difference between an Client and a Vault node initial connection or not?
11

Good point - would appreciate some clarification from MaidSafe.

1 Like
12

Any Vault can be bootstrapped off of. As long as you have it’s contact details you can ask it for more nodes to connect to until you find your real section. These vaults will not speak to you beyond that as they have nothing to do with your address (you are from another section).

To join the network

send BootrapRequest to any vault. You get back either
BoostrapNodes A set of nodes (Elders) closer to our address than the boostrap vault. To these nodes you again do a BootstrapRequest
OR
JoinNodes The actual nodes you should send a JoinRequest to. these are your section Elders and you are then in the section corresponding to your address.

4 Likes
13
  • Is this bootstrap procedure also (at some point) applicable for (new) Vault (<->Client) nodes?

Because from primer:

Bootstrap node – a node to which a new node (Vault) initially connects (via a proxy). Any node can potentially be a bootstrap node, so long as its IP address is written in the Vault’s configuration file

  • This is maybe already too much detail for in the primer: but the node that will eventually be able to respond with ‘JoinNodes’: how close is it to your real, requested section? Always in a neighboring section or is the ‘distance’ variable (and from what does it depend)?
14

Yes, for all nodes, new/old client/vault.

1 Like
15

If the node replying to you knows the section Elders you should connect to then you are good. These will at least be neighbors (i.e. Elders in a section that differs in it’s prefix (section address) by exactly 1 bit)

1 Like
16

Thank you for the answers until now.
To be clear:

  • That bootstrap node is always one of the IP list in your local, manual editable, configuration file?
  • The ‘BootstrapRequests(Xor address)’-messages are all sent from that bootstrap node to the rest of the SAFE Network:
    client <-IP-> bootstrap node <-XOR-> the rest of the SAFE Network.
    And also all other client node SAFE communication passes through this bootstrap node? If not: shouldn’t there be other Nodes who know the client’s IP address?
  • From the primer:

…that initial connection is dropped immediately after the first hop once the new Vault has connected to others in the Network.

–>This is only applicable for a Vault node as part of the relocation process, or is there another step (also for Client nodes) to get a ‘random’ bootstrap node, to prevent overusage of the ones in the distributed configuration file.

1 Like
17

Or in the bootstrap cache that is collected as a node works. Any connection that can be used is kept in a cache file. The cache nodes are preferred and only in failure of each of these would a node use the hardcoded endpoints.

No, this is all local to only the boostraping node and the vault it connects to, no network traffic.

The client connects to its section. This is how we cab do push notifications etc. So the clients section elders will know the client IP address, but only them and any node they tried to bootstrap from.

2 Likes
18

Thanks again for the answers!

  • Concerning cache: that is on the node client I assume. So the first time, when the cache file doesn’t exit yet, it has to be an entry from the configuration file.
  • I already thought that the client section (elders) know the client IP address. I should have started that the following in the primer was confusing (for me):

The Client Managers know the account balance of a Client but to them it’s just an address in the Network. They don’t know the IP address of the Client nor do they have any knowledge of a username, public identity or anything else that could link the Client to an individual.

What is meant there is that the IP adress is not stored on the network (the Xor address is stored) in the ‘account data’. But the elders of the Client Managers (=elders of Client Section?) know its IP address when the client is connected. That is of course much less of a problem, but was the cause of my confusion.

1 Like
19

Yes that is correct. :+1:

Yes it is a bit tricky, but we are OK now I think. Primer is amazing, it covers so much and as we launch we will need to tweak it, but it is gold.

5 Likes