Qortal Project

The future of blockchain platforms

User Tools

Site Tools

Trace: • port_forwarding
data_hosting_q_a

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
Last revisionBoth sides next revision
data_hosting_q_a [01/09/2022 10:17] – created gfactordata_hosting_q_a [01/09/2022 14:25] – gfactor
Line 35: Line 35:
  
 **A:** No, unless they somehow gained access to the PC itself. Obviously an ISP could track the files going in and out of the network and then make assumptions as to what might be stored. **A:** No, unless they somehow gained access to the PC itself. Obviously an ISP could track the files going in and out of the network and then make assumptions as to what might be stored.
 +
 +**Q:** I can block a user, right?
 +
 +**A:** If you block a user, then it will prevent your node from relaying (or storing) any data from that user. So there is some level of control. If you follow a user, you become a mirror for all of their data, which helps the network even more than a relay.
  
 **Q:** Can I turn off data relaying? **Q:** Can I turn off data relaying?
Line 80: Line 84:
 **Q:** Ok. Conclusion: If someone whants to see what data is relayed through your node, it can be seen with lot effort, but, it can. It is public data, with public decryption keys and whole data is chunked in small pieces with guide how to combine them to see full picture. Combining data is also available to everyone. All chunks go through one node? **Q:** Ok. Conclusion: If someone whants to see what data is relayed through your node, it can be seen with lot effort, but, it can. It is public data, with public decryption keys and whole data is chunked in small pieces with guide how to combine them to see full picture. Combining data is also available to everyone. All chunks go through one node?
  
-**A:** All chunks can go through one relay node, but that's not necessarily always the case I imagine. +**A:** All chunks can go through one relay node, but that's being coded to NOT happen. So there will not be all chunked data found on one node. Therefore, there should not be any concern about what chunked data passes thru your node.
  
 **Q:** Is that random rule, or is it hardcoded to use multiple relay nodes and shuffle data? **Q:** Is that random rule, or is it hardcoded to use multiple relay nodes and shuffle data?
  
 **A:** At the moment, it will get chunks from whichever nodes will serve them. That means in a lot of cases they will all come from (or via) a single node. Longer term we could add logic to try and spread the chunks out via multiple nodes, but we're way too early in the system right now for that level of intricacy. Remember, it's all public data anyway, so each individual chunk could be identified by an ISP or whatever just by them checking against the public metadata. So anything we do is just obfuscation. It's public data after all. **A:** At the moment, it will get chunks from whichever nodes will serve them. That means in a lot of cases they will all come from (or via) a single node. Longer term we could add logic to try and spread the chunks out via multiple nodes, but we're way too early in the system right now for that level of intricacy. Remember, it's all public data anyway, so each individual chunk could be identified by an ISP or whatever just by them checking against the public metadata. So anything we do is just obfuscation. It's public data after all.
 +
 +**Q:** If relay default is on then port forwarding is NOT required? This would help reduce the nerd factor required to run a node. We are getting more civilians on board and are trying to lower the barriers right? PF is our Archilli’s heel because of ignorance and product variability.
 +
 +**A:** Having relay nodes allows us to remove the port forwarding requirement for those publishing data. Without relay nodes, data publishers would be required to port forward, which is not ideal at all. It doesn't affect the port forwarding situation for the network in general, but we do have some future plans to remove that. So in the future it's possible that neither port forwarding or relays will be required for anything. But quite a bit of development needs to be done to get there.
 +
 +**Q:** Why not keep relay off for simplicity’s sake?
 +
 +**A:** The problem with that approach is that we are gambling on enough of the network to opt in. There's a good chance that QDN would be very unreliable if we just hope for the best. Each node is already using 200GB+ a month (2.5gb per day) in terms of data transfer. I expect the additional data from relays will be so small that it's unnoticeable. Maybe in the long run it will add up, but right now I'd be very surprised if enough data will be published to make bandwidth a problem.
  
 **Q:** Can VPN hide any relayed data from ISP or someone trying to see what is going through your node? It shall hide who is running node, so maybe not connect them with you, but with some VPN IP. **Q:** Can VPN hide any relayed data from ISP or someone trying to see what is going through your node? It shall hide who is running node, so maybe not connect them with you, but with some VPN IP.
  
 +**A:** Yeah if using a VPN, everything will be encrypted and invisible to the ISP or any other onlooker. The only entity that would be able to see would be the VPN provider, so it comes down to trust as to whether they keep logs even if they say they don't.
 +
 +I did have an idea to encrypt data further:
 +1. When asking for data, the requester would generate a public key and include it with the request.
 +2. When a peer is able to fulfil the request, they encrypt it using the included public key
 +3. The encrypted data is relayed back to the original requester. No other parties would be able to decrypt it.
 +4. The original requester decrypts the data using their private key.
  
 +The problem here is that, whilst the file's data itself is encrypted, the metadata/identifier is still public. So anyone watching would be able to see the metadata of the encrypted file and therefore deduce what the file was. The metadata/identifier has to be public because the network needs to know what file is being requested. I don't think there's a way to hide that, but just putting this idea out there in case it can be expanded upon.
  
 +The default value is a difficult decision, as if we default it to false (and don't have enough people opting in to enable it) then the reliability of QDN will really suffer. But if we default it to true then we risk upsetting community members that missed the discussion and didn't opt-out in time.
  
 +**Bottom line, if you are really concerned about the legality of allowing your node to be a relay, then don't be a relay - it is totally optional.**

Page Tools