Anonymity and Proxy Nodes

I’ve been trying to figure out how anonymity is guaranteed in the network, as it is listed as a feature in the fundamentals and a the faqs state that the client managers will never know the IP-address of a client. So I thought this was achieved by using prox nodes. However, I’ve read some contradicting posts, like this one New data type: Free Data with PoW signature or this one All the encryption layers for SAFEnet, which suggest that proxy’s are just used for initial connections to the network, but then I will connect to nodes that are close to my XOR address, which would be my client managers and they do know my IP address then. Moreover the Primer mentions Proxy Nodes in chapter 12 and refers the reader to learn more about them in chapter 4, but I couldn’t find any information about them in chapter 4. So wasn’t really able to find coherent information about how this works, what Proxy Nodes do, and how anonymity is guaranteed, can somebody help me here?

Also, in my head somewhat related to this topic are identities and how a client can use different identities for each request as stated in All the encryption layers for SAFEnet. How are they managed by vaults, like, can a client manager differentiate whether it is dealing with an actual client or just some “session identity”, which might be relevant in so far, as client managers would have to hold data for each session identity, if they cannot know if its an actual client.

3 Likes

Well can’t really guarantee absolutely anonymity. For instance a network with one section only then all nodes would be able to know your IP address since their is no hops between the section and you.

Apparently the proxies are being phased out. The first node in the particular transfer will be removing your IP address when it passes the packet on.

As the network grows the ability to provide good anonymity increases and for a large network the anonymity is close to guaranteed. But there is never a point where its actually guaranteed since that is an absolute statement.

5 Likes

But isn’t a client manager the first node that passes the packet on? Because Client Managers are the ones that should be closest to me, aren’t they?

That is a node. Every node operates different personas including managers.

Sorry, but you’re rather confusing than helping :sweat_smile:
Isn’t the node that operates one of the client managers that are responsible for me the first node that passes on my packet, or am I getting something wrong here?

So do you imply that a persona does not know what the node is doing? Or do we hope or know somehow that the first node, which (in my understanding) is one of my close nodes, does not operate a client manager persona?

can you please be more specific, because I think this is exactly the point I am trying to figure out.

2 Likes

TBH I never quite understood how this works either :blush:

4 Likes

A Client will connect the elders cosset to the public address the client is using (clients have unlimited identities (public keys)). Those Elders will see the IP of the client, but will not use that info when passing the network request on to its destination. So the address of the client on the network is this public key (identity) and not the IP. As the network is recursive and not iterative we can do this easily. This is what we mean when we say the IP is scrubbed at hop1.

Hope that helps

9 Likes

Thanks, I think I might have got it now, if Im piecing this with information from other posts together correctly. So let’s say a client wants to store data on the network:

  1. The client connects to a bootstrap node to have a secure entry point to the network.
  2. The client requests its account packet, via the bootstrap node.The packet ID is derived from the clients login credentials, which are only stored locally by the client. The request is signed using the key pair that identifies the client, that is the one from which its XOR address is derived, and which is also stored locally. The account packet is stored like regular (mutable) data.
  3. The client creates a session identy (which could be added to the account packet and possibly reused?), which determines its public XOR address for the session
  4. The bootstrap node connects the client to Elders that are close to the session XOR address.
  5. The client sends a request to put data to his (original) client XOR address. The request is again signed by the “original” public key of the client, so the managers will know the request is made by the client. The Elders that are close to the clients session XOR address forward the request. From that poin on, the IP is not retraceable anymore.
  6. The client manager close to the clients original XOR address pick up the request, verify it and then forward the data to the data managers responsible for that chunk ID.

and so on.
Is this correct?

5 Likes

So a client is also part of the DHT (i the sens that it needs to “find it’s place in the network”)? And maybe even a section?

More like accesses the DHT, but only from a fixed part of the address space. It is lost after that really and holds no DHT routing data etc. The clients close group (Elders) have all the DHT knowledge and allow the client to speak though them and (some time in the future) vice versa (push notifications) If that makes sense.

3 Likes