Below is a Q & A regarding data hosting. Most answers are from Cal 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 seconds 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: 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?

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 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?

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.

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.