|
|
|
|
|
by jeroiraz
1638 days ago
|
|
first of all, thanks for your feedback and discussion :) if entering an email for downloading the paper is a concern, we'll consider it. immudb should be used as a traditional database (log, key-value or even a relational store - with limitations of course), so it's up to your deployment to whom you give user credentials with read/write permissions. The key difference is the state being captured by a single hash value. Given the hash value denoting the entire state can be signed and exported. It's out of control of the server how many copies or when a validation is going to be made. Currently, official SDKs are storing the latest validated hash in a local file, but it's perfectly possible to store the hash in a remote storage, other database, etc. This will ensure data is only added but never changed once written, please note with never changed I mean it's subject to detection when a proof is requested. immudb does not pretend to provide a complete security solution, but a key component when you deal with sensitive data. |
|