Differences

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

--- data_hosting_q_a [01/09/2022 10:19] – gfactor
+++ data_hosting_q_a [12/23/2022 12:16] (current) – removed gfactor
@@ Line 1: / Line 1: @@
-====== Data Hosting Q & A ======
-{{:qortal_official_logo_transparent_.png?400|}}
-Below is a Q & A regarding data hosting. Most answers are from CalDescent and a couple are answered by Oshmoun:
-**Q:** If my node is Relay node, does it store data?
-**A:** No, it only stores data that you have viewed or followed. Data being relayed is deleted as soon as the relay completes, so would only exist on your node for a couple of milliseconds whilst it's being handed from one peer to another.
-**Q:** Can someone intercept Relayed data and see what is my node relaying?
-**A:** I imagine an ISP or someone on the same network using wireshark would be able to see the encrypted data being transferred (but it would be just meaningless encrypted data unless they go looking for the keys).
-**Q:** Is relayed data encrypted?
-**A:** Yes, the system requires that all data is encrypted.
-**Q:** What does it needs to for decrypting Relayed data?
-**A:** We are dealing with public data here, so the decryption keys are published on chain for each transaction. This means that someone with a copy of the Qortal blockchain could decrypt the relayed data by locating the corresponding decryption key on chain. So as soon as someone knows that the data is Qortal-related, they could decrypt it if they try hard enough. The keys have to be available publicly, otherwise no-one would be able to view any public data at all. No-one will be able to decrypt private data, but we don't support that yet.
-**Q:** Can my ISP see and decrypt relayed data?
-**A:** As above, if they install Qortal, they could locate the keys and decrypt any QDN data.
-**Q:** How will video file be sent through Relayed node? Can someone see it?
-**A:** Every file relating to QDN is compressed and encrypted before it is sent or stored on a node. That includes videos.
-**Q:** Is QDN data stored on my node encrypted?
-**A:** Yes, data you are hosting on your node remains encrypted. The exception being sites that you have recently viewed, as for those we keep an unencrypted cache to speed up the loading time. The cache's expiry time is configurable in the settings (default 30 days). The Qortal web browser in the UI has "DELETE" and "BLOCK" buttons allowing you to immediately remove any questionable content from your node if you encounter it.
-**Q:** Can someone see files from QDN stored on my PC?
-**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:** Can I turn off data relaying?
-**A:** Yes, set `"relayModeEnabled": false` in settings.json
-**Q:** Can I turn off core auto updates?
-**A:** Yes, set `"autoUpdateEnabled": false` in settings.json
-**Q:** Can I expect that my bandwidth usage will be x2 whit Relaying turned on?
-**A:** Given that the core uses a lot of bandwidth already, I expect there will be very little noticeable difference when relay mode is on. It would probably be a long time in the future before the amount of data being relayed reaches 2x the current bandwidth usage.
-**Q:** Relayed data can be encrypted same as as data stored on PC if someone will run Qortal. Right?
-**A:** Yes, all relayed data is encrypted in the same way as data that is stored, but again has the same caveat that someone investigating it could locate the key and decrypt it. The encryption would be enough to prevent any automated network scans to detect it, but if someone were investigating the traffic in detail, they could install Qortal and find the decryption keys.
-**Q:** Will node data publishers have some kind of agreement about not posting dirty stuff on public websites?
-**A:** I don't see how such an agreement could exist, given that the Qortal network has no ownership or censorship.
-**Q:** Just an idea, can we have whitelisted webpages who agrees to moral compass and maybe an option in other cores for relaying only data from whitelisted nodes?
-**A:** We are looking into adding whitelists in the future so users can share lists of pre-approved safe content and then people can optionally subscribe to one or more whitelists. Same with blacklists. But it's a future idea, not something that exists now. I don't think a system-wide whitelist or blacklist is a good idea as that would end up with the same problems that the existing internet suffers with, where truth is deemed misinformation and therefore censored because it conflicts with an agenda.
-**Q:** When we will have torrent like system with all QDN data in chunks, then there is no issue of data decryption and intercepting from anyone, right? For relays and local data storage.
-**A:** Chunking is in place already - every file is split into 1MB chunks.
-**Q:** So how can then someone see full picture from my relaying data? Do they know what chunks go together for complete picture?
-**A:** They’d need to collect all the chunks. The node that has the data just sends the data chunked to the node requesting it (either through relay or directly)
-not sure if such metadata, like number of chunks, are transferred prior to starting the chunked transfer.
-**Q:** So, lets says that someone interested in my node trafic will intercept relayed data and decrypt it with key from chain. He will see only some 1 and 0?
-**A:** It is plausible to assume that the relay would serve multiple requests at a time. I checked the code just now, indeed there seems to be metadata transferred prior to the actual data transfer. The requesting node knows when all chunks are there by checking the metadata chunk signatures
-if chunks exist locally with all the signatures from the metadata, then it knows the transfer is done and it puts all the chunks together in the order specified in the metadata.
-**Q:** Can relaying be done in the way that chunks of data are sent through multiple nodes. In that way each node will have only chunk.
-**A:** Well that assumes that there are multiple routes from the requesting node to the data node, that can't be guaranteed I imagine.
-**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.
-**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.
-**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:
-. When asking for data, the requester would generate a public key and include it with the request.
-. When a peer is able to fulfil the request, they encrypt it using the included public key
-. The encrypted data is relayed back to the original requester. No other parties would be able to decrypt it.
-. 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.

Qortal Project

User Tools

Site Tools

Differences

Page Tools