5 minute read
There are three basic types of application data access:
If your application needs to store data, you can use the @SDK to manage data securely and easily in the @persistence keystore. This SDK provides the following capabilities:
Note: the cloud @server does not have access to the secret private key. This prevents bad actors from accessing or modifying private data not meant for them.
Data operations that involve writing data to the @persistence keystore can only be done with the approval of the owner. Access to this data is cryptographically controlled. This is managed for your application by the @SDK and is remarkably easy. The types of access that can be set for each data record include:
Naturally, the owner of an @persistence keystore has access to any and all data that is contained therein. After being authorized, your application can read the data that it needs from the keystore as well. Applications that prefer to rely on data within its own namespace can also store read data from the @persistence keystore with approval of the owner. As always, all data stored is owned and controlled by the owner of the @persistence keystore.
Applications typically are a combination of an owner’s data and data that has been shared with them by others. This is a new feature and is what we’re referring to when we talk about P2P (Peer-to-Peer) applications.
For example, messaging applications available today involve a combination of data (messages) from various people but have no way to ensure that each individual message belongs to its creator. With the @protocol, messages that I create and share with other people are owned by me and likewise, messages that others create and share with me are owned by them. The messaging application is thus responsible for interleaving and presenting these messages while simultaneously maintaining privacy controls for the owner of the data (i.e. I own my messages to you and you own your messages to me).
While this may seem confusing and difficult at first, the @Client SDK and the Flutter UI Component libraries make it very simple to implement. This results in surveillance-free, privacy-compliant applications that are simple, cost-effective, and efficient, with better performance than backend server-based applications of the past.
The @Client SDK provides the following capabilities that help to integrate data shared by others in your application:
For more information on how your application can create, update, or delete data, see the [@Persistence Keystore Guide](Persistence Keystore Guide) and the @Protocol Verbs.
One super interesting side effect of giving people control of their data and storing it all in one place is that any application that they authorize can reason over any data that they are allowed to access. Applications that are certified as @protocol compliant (@pps) can provide amazing new experiences because they have the ability to access and reason over all data stored in an @persistence keystore.
For example, a certified messaging app may contain a thread where a group of people are discussing which movie to go see on Wednesday night. If permitted, this information can also be presented as an event in their certified calendar application and similarly presented as a group in their certified contacts application.
If you would like to store application data, you are free to use the @persistence keystore for your persistence if you want to. You may want to get your application certified anyways to advertise that it is privacy compliant and have it included in our list of certified apps.
If your application does not require data persistence on behalf of the person using it; for example, if you just want to make sure that your application is licensed to the person using it, then you do not need to get it certified. You may want to get your application certified anyways to advertise that it is privacy compliant and have it included in our list of certified apps.
For more information about getting your application certified, see the Certification page.