I am Bader from IoDLT - in short, I basically develop a bunch of IoT + blockchain stuff, but need way to store mass amounts of information, such as:
Sensor data, some of which pertain to health
Images taken from IoT devices - potential video as well
COVID-related data
I’m currently using the Symbol blockchain, and was thinking of ways to link up Storj with it to have the ultimate storage / ledger protocol!
Storj looks like the perfect solution so far - just had a few questions
Are custom networks able to be deployed? I see Tarigrade as a production ready network - would I be able to run my own storj network, potentially with slightly different configuration?
How is the GDPR / HIPAA status of Storj? Is it compliant? Is data able to be deleted from the platform, if needed?
Does Storj have an access control mechanism, where I could limit who can see the information?
If I needed, could integrate Storj with my preferred blockchain? How would I get started in doing that?
Welcome to the community! It’s good to see you’re interested in using Tardigrade/Storj. I’ll try to answer your questions as best as I can. But I’ll sometimes leave answering or refining the answer up to someone from Storj.
There are 2 things you can do.
Run a storj test network: This is mostly for testing integrations with Storj if you want to do this outside of the production network in your own environment. Info here: Test network · storj/storj Wiki · GitHub
Run your own satellite: The software is completely open source, so you can start your own satellite and run your own network. Keep in mind that you would be responsible for paying node operators and node operators would need to actually white list your satellite to even do business with it.
Depending on what the purpose was for running your own network I hope either of these would help.
I don’t believe Tardigrade is currently GDPR / HIPAA compliant, but please wait for confirmation from someone from Storjlabs on this one. You can delete data and data you delete will be removed from nodes right away. If the node is offline at that point it will be removed when the node comes back online at a later time using a garbage collection process.
I guess this kind of depends on what kind of integration you are looking for. Could you elaborate a bit on this? I’m probably not the one who could give you a detailed answer on this, but it would help someone else give you a better answer.
Firstly, thanks so much for the prompt response - seems like there is a nice community here
Very nice - I think that’s exactly what I’m looking for. Will have to read up!
The one thing that DLTs suffer from (which is also their primary strength!) is the inability to efficiently rollback information recored to the chain. I’d be very interested in this, as I have a pilot clinic that may benefit from having patient records stored securely on something like Storj, for example. Another usecase is COVID-related testing data, which also must be compliant.
Ideally, a pretty full integration directly into the chain itself. Something like a Storj instance that runs along with each node, with all interactions from the Storj instance recored on the ledger. Also, some extra functionality such as paying to access a datastore, represented by an entity on that chain etc. Even using that chain’s currency for rewards, as well. I suspect something like this would require some modification of the core code.
Will have to go do some serious reading on Storj, now that I see it’s a very good candidate for something like this.
In regard to this, not that i know either… but essentially you are the only one with access to the data because of how the Tardigrade encryption works.
thus any privacy concerns would be in regard to how you treat the data when retrieved from the network, to anyone else its just a big mess of encrypted data… and the data is encrypted by you before its transmitted.
its literally locked to the encryption keys you have and only those keys can decrypt it when the data has been retrieved.
So my guess would be that it is compliant unless if there are oddball rules that made sense 5-10 years ago…
3.6 Encryption
Regardless of storage system, our design constraints require total security and privacy. All
data or metadata will be encrypted. Data must be encrypted as early as possible in the
data storage pipeline, ideally before the data ever leaves the source computer. This means
that an Amazon S3-compatible interface or appropriate similar client library should run
colocated on the same computer as the user’s application.
Encryption should use a pluggable mechanism that allows users to choose their desired encryption scheme. It should also store metadata about that encryption scheme to
allow users to recover their data using the appropriate decryption mechanism in cases
where their encryption choices are changed or upgraded.
To support rich access management features, the same encryption key should not be
used for every file, as having access to one file would result in access to decryption keys for
all files. Instead, each file should be encrypted with a unique key. This should allow users
to share access to certain selected files without giving up encryption details for others.
Because each file should be encrypted dieerently with dieerent keys and potentially
dieerent algorithms, the metadata about that encryption must be stored somewhere in a
manner that is secure and reliable. This metadata, along with other metadata about the
file, including its path, will be stored in the previously discussed metadata storage system,
encrypted by a deterministic, hierarchical encryption scheme. A hierarchical encryption
scheme based on BIP32 [46] will allow subtrees to be shared without sharing their parents
and will allow some files to be shared without sharing other files. See section 4.11 for a
discussion of our path-based hierarchical deterministic encryption scheme
