🚀Kepler

Self-Sovereign Storage

Kepler is a system for user-controlled access to user-owned resources across a distributed network of Peers (which we call an Orbit) also chosen by the user.

With Kepler, you can designate where data is stored and who can access it. Data stored in a Kepler Orbit can only be accessed by those specifically authorized to do so. All these interactions are managed through the use of keys.

Orbits

Kepler Orbits are P2P networks controlled by the user's keys and represent the governance of a set of resources identified by the Orbit ID. Orbits have three distinct roles:

• Controller: The user. Controllers are the indisputable root authority of an Orbit. All authorization to perform actions on a resource within an Orbit must be traceable back to a Controller. Controllers determine who can be a Host and a Client.

• Host: Peers in the Orbit network. Hosts are where the Controller's data lives. Hosts are responsible for enforcing access control policies specified by the Controller, serving properly authorized requests from the Client, and managing the resources of the Orbit.

• Client: Clients are authorized by the Controller (or another Client) to make requests to Hosts as long as the request is within the scope of the authorization.

Capabilities

Kepler uses capabilities-based permissioning, which works similarly to an access pass. A Controller can specify who has access to data within their Kepler Orbit and under what conditions, then sign off on it.

For example, if a website wants to know how to store a file with a user's Orbit, the user can sign an access pass that specifies the website's public key (or Ethereum address) and the content hash of the file to be stored. This process, called Delegation, makes the website a valid Client.

The website can then countersign for the access pass and upload the file to one of the user's Hosts. This process is called Invocation. The Host will then check for a valid signature from the website, the correct content hash for the uploaded content, and that the resource owner signed off the capability. If everything checks out, then the file can be stored.

If the user decides they do not want the website to make more requests, they can cancel the access pass by creating a new message which cancels the Delegation, signing off on it, and showing it to the Host. This is Revocation.

To summarize, Kepler's capabilities have three possible steps:

• Delegation: Giving access to one or more resources in an Orbit by signing a message representing the limits on access and giving it to a Host.

• Invocation: Accessing or modifying one or more resources by signing a message representing the action to be performed and giving it to the Host, who then acts.

• Revocation: Cancelling a Delegation so that it can not be invoked anymore. Delegations can also be issued with an expiration time, after which they are automatically revoked.

Sign-In With Ethereum Support

Kepler works seamlessly with Sign-In With Ethereum (SIWE), using session keys. With Kepler, any SIWE user can immediately utilize a private data vault to store their preferences, digital credentials, private files, and more. This is an essential prerequisite to making dapps personalized and contextual to users. This works by using SIWE to perform Delegation.

To quickly get started with Kepler, check out the SSX Quickstart:

⚡pageQuickstart