Topic: Is there a use for private authenticated off-chain storage? (Read 77 times)

That's excellent, I wasn't aware of stacks - thanks.  From a brief look it works in a very different way, using private auth tokens instead of public smart contracts to control access, but the result is very similar - a private data layer for dapps with full read/write/delete access controls.  Will do a deep dive.

I think Gaia has solved that problem, however, there might be a lot of room for niche solutions. About Gaia: https://docs.stacks.co/build-apps/references/gaia

No, they are valid points.  DApps built on public blockchains and decentralised storage networks is a beautiful concept.  However, there are problems with DSNs: they don't offer authenticated access controls, afaik (except by controlling who has the file id and decryption keys, which cannot be revoked); data can't be deleted; data can't be easily analysed; they don't help companies that store different parts of customer data in different tools (e.g. salesforce for sales data, mysql for the core product, etc).  This limits the use cases for DApps built on DSNs, it seems to me.

I guess the question is, is there value in having the access controls deployed on, say, Ethereum while the data is held on a private trusted server?  The vision would be a marketplace of 1000s of cloud-based vault services all competing on integrity, security, availability and feature set while some users run their own home servers and let their friends and family use them.  DApps for whom data integrity is not that important, like social media DApps, could allow users to choose where their data is held, while others could insist on using one of a set of trusted cloud vault services.  Companies that insist on storing their customer data locally would be able to demonstrate to a regulator they have an active smart contract proving they have their customer's permission to hold the data and conversely would have to delete the data if the customer terminated their contract.  Some cloud vault services could be gateways to DSNs.

In the same way you can have the access part in one table (or even one database if you want to!) and the actual data in another.
For now private blockchains couldn't convince me good enough that they worth that much attention. A blockchain is a limited database. Indeed, if trustless relationship is needed between multiple entities who will maintain the data integrity, public or shared blockchain is beautiful. But again, maybe it's me, maybe I'm missing a point somewhere.

Don't take me wrong, DApps are very interesting on a blockchain, the problem I see is that the blockchain, whatever you do, doesn't have the flexibility of a database (or, as I said, even a file system).

Thanks.  Yes, one way to think of it is as a linux file system with file permissions defined in a smart contract.  Sounds pointless right?  I'm not so sure.  I think there are benefits that could be valuable to DApp developers:

From a DApp perspective the permissions are separated from the data which allows the data to be stored anywhere and the DApp to control access permissions using a state driven, auditable, authenticated smart contract that can accept money.  This opens up interesting new use cases like data monetisation and users taking control of their own data.  It also means the DApp developer doesn't need to deploy and configure their own backend server, instead they simply deploy a smart contract and use an existing cloud based vault server or allow each user to choose where their data is held.

For old-school users and businesses it could be seen as a stepping stone towards full decentralisation.  i.e. businesses can start exploring DApps without having to fundamentally change their existing infrastructure.

Imho you are trying to force the use of blockchain in places old-school storage (or even the file system!) does its job good and blockchain is not actually needed.
...but maybe it's only me.

Smart data access is meant as an alternative to decentralised storage platforms like filecoin, sia, storj, ipfs and ipdb, and to storing data on-chain.  It can also allow companies to step lightly into the world of decentralised applications by allowing them to store off-chain data locally on existing infrastructure.

There is a plethora of applications that use private blockchains for storing records/data. Just do a search for "blockchain applications". One typical search result is https://www.businessinsider.com/blockchain-technology-applications-use-cases

I'm looking for feedback on whether the following idea for 'smart data access' could be of any use for DApp development. It combines off-chain data storage with on-chain authenticated access controls. Smart contracts control the access rights to data stored in a 'vault' on any compatible private server, whether that's a home server, company server or cloud storage service. DApps send read/write requests directly to the server and authenticate using the user's key. The server queries the blockchain for the access rights before servicing or rejecting the requests. The life-cycle of the data in a vault is controlled by the vault's smart contract, which the DApp developer would write for the specific use case. Being a state machine the smart contract can be transacted with to, say, grant and revoke access for specific users or to transition through a pre-defined service life-cycle.

It's a simple concept but I think it has powerful applications. Would a generic off-chain storage solution like this that offered authenticated read/write/delete access be of use? I'd appreciate any feedback you have.

---

Some example uses:

Blogging Dapp: a user's posts could be stored on a server of the user's choosing and the DApp could allow the user to grant and remove access for their friends.

Paywall: access to web content is granted and removed based on payment to the smart contract that controls the content's vault.

Online Service: access to different pieces of a user's data is granted to different companies in a supply chain, granting and revoking access throughout the life cycle of the service and finally deleting the data when the service is complete, perhaps after a legal retention period. The state of the service life-cycle is visible to all parties at all times and transitions are visible as blockchain transactions.

Company Storage: a company can hold all its documents and communications privately on its own servers while making the data accessible to DApps run by authenticated users.

GDPR Compliance: customer data can be held on a company's servers and access to update and delete the data is granted to the customer. Alternatively, the data could be held in the customer's own vault and access granted temporarily to the company.

https://github.com/Datona-Labs/datona-lib