Can a node receive data from a node that it can't connect to?

If a node wants to receive a chunk, but that node is relying on a meshnet and there are no nodes in range that host that chunk, or there’s another problem accessing any nodes that have the chunk, what happens? Maybe of all the nodes in range, the ones with the shortest XOR distance to the chunk (if I understand this bit vaguely right) request the chunk from their neighbours, this process continues recursively until the chunk is successfully passed along?

There is no meshnet, the safenetwork is dependent on the normal internet protocol. You might be confusing it with a Distributed Hash Table.

1 Like

I remember David saying the network should be able to work with meshnets, many years ago.

Also I think you have a basic misunderstanding here, and apologies if I read you wrong.

The nodes do not request the chunk directly from the nodes holding that chunk.

There is hopping through the XOR space (section to section) until the request reaches the section with nodes holding the chunk. And reverse happens to get the chunk back to the request client and may not be same path in reverse.

Thus it is expected that if your client can connect to a node on the safe network then you can get the chunk. Be it a mesh or normal routing.


EDIT: This text has been crossed over because it’s false.

Someone correct me if I’m wrong, but I believe this was changed pretty recently.

The way it works now as I understand it is that every section can contact every other section. So the data request does not need to hop around anymore to reach its destination, but can instead be sent straight to the destination in a single hop.

However, the same expectation you write about is true regardless. That if you can connect to the network you can get the chunk.

I think maybe to7m is misunderstanding how mesh nets for Internet access work, or I’m the one who’s misunderstanding :slight_smile: . A mesh net “works” when you can use it to connect to the Internet. So either you’d be online and it’d work, or you’d be offline and it wouldn’t work.

So in essence this hasn’t got anything to do with mesh networks. Or to answer the original question:

This would mean the node is offline and it would get punished by the network through a reduced age once it gets back online. It would probably be replaced by another node pretty quickly.

1 Like

A mesh net “works” when you can use it to connect to the Internet.

As far as I can see, meshnets are not intrinsically related to the internet. They can exist independently.

This would mean the node is offline and it would get punished by the network

How can a node get punished if it’s just requesting a chunk? What would that punishment entail?

1 Like

This sounds useful in some ways (like with meshnets), but doesn’t that mean that downloading a XOR-distant chunk would take like 10x longer than if there were an option to pass along the holding vault’s address?

It is logarithmic time. O(lon n), where n is number of sections. If each section is connected only to its XOR neighbours then, it means in N hopes you have access to 2^N sections. Having dirret connection befween each section is overkill for big network. I have no idea what is currently implemented, but Having access to not only neigburs but also to some very distant sections would speed the worst case scenario. It is not going to take 10x more time, because any request that does not belong to the section can be rerouted instantly to other sections on network layer. There is not need for any consensus or any aditional work, so it should be without delays.

1 Like

It sounded a lot like the actual chunk would be bounced between sections though. That would mean
O(log(n) * GET_time + log(n) * chunk_transfer_time)
, rather than
O(log(n) * GET_time + chunk_transfer_time)
, unless I’m misunderstanding.

If you want to run a node on a global network running on the Internet, then it has to be. Whenever the node loses its connection to the network, it won’t be able to do its job.

It wouldn’t get punished for requesting a chunk. After all, the idea here is that it can’t even reach the other node. It would get punished when elders in the section soon realise they are unable to contact it. The form of punishment is reduced age, which results in less rewards and less responsibilities for the node.

The form of punishment is reduced age, which results in less rewards and less responsibilities for the node.

Why would there be any rewards or responsibilities for this node in the first place though? It’s not necessarily trying to earn anything.

Because that’s now the network is programmed.

Nodes have functions to fill (responsibilities), and they get rewarded with Safe Network Tokens for fulfilling them.

I must have misunderstood the meaning of ‘node’ then. I might mean ‘client’. Any links to documentation would be appreciated.

Ah ok.

Yeah well it’s even simpler then.

You have a list of IP addresses on your computer that you try to use when you make a request to the network.

If you can successfully send your request to any of those addresses you’re good, whatever you wanted to do should work (request a file, upload a file, make payment). If you can’t, then you can’t.

Unfortunately, as far as I know there isn’t any up to date documentation right now as things are changing a lot. But there’s always the primer which was last updated august 2020 right now it seems:

1 Like

Clients don’t get any reward and they don’t get punished either. That’s just the nodes that make up the network. The primer is a bit out of date now but still basically correct on this I think.


Then it will not connect to the safe network will it. Simple logic, if it doesn’t connect to the internet where the global safe lives, (that includes connecting to another network that connects to the internet) then it doesn’t connect to the global safe network. If its independent then its independent

Not bounced around but taking a direct path through some sections. (It was) Always to the section closest to the target section and never the other way around. A shortcut and this maybe the way they do it now, is only send the request that way and when chunk is found the return path is direct to the section the client connects to. This solves the issue of transfer times and its only a tiny request packet taking O(long(n)) hops which is quicker and only one way is doing the hops.

For a mesh network to have nodes on the Safe Network then that mesh network has to be able to connect to the internet in a meaningful way. Thus a sub 1Mbit connection for the whole mesh is not meaningful, especially if many clients and nodes wish to be a part of the safe network.

Primarily the safe network is for the Internet infrastructure for well into the foreseeable future or always, any mesh networks wishing to have safe nodes & clients have to respect that.

As to the safe network only working on a mesh, then yes that is possible but it will not be the global network since the global people cannot access it. That network will be a specialised one separate to the global safe network.

1 Like

I just don’t get why there is no mentions of DHT in all the SN explanations. DHT should be a thing for people that are at least somewhat interested in decentralization, as it is at the heart of so many decentral software (IPFS, bittorrent, retroshare, … pretty much everything that is not a blockchain, or does the same sort of yolo network flooding).

No, meshnets & the internet are two distinct things. IPv4 & IPv6 are also two separated networks (although with a high intersection between them and shared infrastructure like routers that route v4 & v6). Does that lead to issues for elders that can be reachable from all the nodes in the same section (say they use IPv6), but then can not be reached from (some) other sections, that are running only on IPv4?

NO! You still need a DHT, otherwise you would end up with connections going from each section to all other sections and thus each section would need the current connection info for each other section (with all the privacy/anonymity consequences included, all node IPs visible to all other nodes, etc.).

This is also bad for privacy, cause you need to put the connection info of the requesting section to the request. At least you do not to flood the network to get all connection infos to all sections. Wouldn’t it also decrease the efficiency of caching?

Yeah, nodes need to be reachable, but clients do not. If there is a gateway (a SN node) that is also reachable from a private network (meshnet, your local network, …) then it could be used by a client in that network to send requests to the SN.

Just to be more specific: closeness is measured by logical distance between the ids of two nodes/sections (idA XOR idB) not their geographical distance.

1 Like

I know. Note the quotes around “works” and that I wrote “mesh net for Internet access” in the previous sentence, didn’t feel necessary to repeat that whole.

Do you have some source for the information about that this is how it works? You seem pretty sure.

I’m not talking about clients though, so not sure what in the quote you’re responding to.

Neo obviously knows this.

What do you mean? The source that the SN is based on a DHT? That part was about how the network is not working.

Routing is based on an algorithm that extends Kademlia DHT routing (see Chapter 4). […]
SAFE Network Primer under “Routing”

1 Like

Hmm, I’m a bit confused, but I think I understand that every section does not have a direct connection to every other section.

I searched to see if I could find where I had read that every section had a connection to every other, but I couldn’t find it, so I think it’s safe to say that the primer is up to date in this regard and that there are still several hops involved in requests.


1 Like