The simple, efficient, encrypted personal data store and sharing system.

What is Sylow?

Sylow is a personal data store and exchange system, founded on principles of sharing and encryptability, upon which a wide variety of client applications can be built. It prioritizes a flexible, extensible schema and simple API and operation.

The idea: provide an API server, connected to a database and file storage system, that can prototype different forms of data, store, encrypt and serve them in a uniform manner. One can then build a variety of different applications that use the same API, simplifying the task of developing end user applications. The servers will ultimately be able to encrypt each form of data stored using public-key encryption, and communicate with each other for decentralized sharing.

Sylow establishes a certain set of built-in schema that can be used to share data. However, since schema are linked from externally-hosted sources, individual server operators will be able to define and use their own schema. This allows new forms of data to emerge depending on the implementations different groups want to develop.



A Sylow server is a repository for a user's documents and data. The server is a sort of dumb blob store, storing encrypted data and metadata on behalf of the user. The server will also handle sharing this data with other entities as directed by the user.

Servers are discovered using an SRV record stored at the root of the associated domain's DNS zone. This SRV record specifies the fully-qualified domain name and port at which users under this domain can be reached. For example, if a server wants to know where to find the Sylow server for the entity with the handle, it first does a lookup for SRV records associated with, finds one for Sylow that points to, then passes off all of its requests to that location.


An entity is an account that is created on behalf of the user, which is used to create and interact with documents.

Each entity has one server that they are registered with, and that acts as the authoritative server for that user. For example, an entity bob is registered with a Sylow server at, and so is the authoritative server for bob. Anytime Bob creates, retrieves, updates or deletes data, he does so from his authoritative server first before it is propagated across the rest of the network.

Entities are also first-class documents that can be shared across servers. In this way, one can send records of certain entities and create relationships between them. For example, when Joe follows Bob using a Sylow-powered social media app, Joe's server sends Bob's server a copy of Joe's entity as a document, which contains Joe's profile as well as Joe's public key, which Bob's devices can use to encrypt documents to send Joe's way.


A Client is any client application that is registered with the server, and that can display or modify documents on behalf of a user. Client applications can be varied depending on the types of data one wants to store on their Sylow server.

A physical device can actually include multiple Sylow Clients: a smartphone with one social media app and a second photo gallery app counts as two different clients, of course. That's because clients are actually OAuth2 clients that can each have specific permissions or be independently revoked as necessary.


Schemas represent versioned definitions of documents and all their associated fields. These schemas are used to validate documents as they are exchanged between servers, in order to standardize expected behaviours. Servers must adhere to a particular defined schema when transmitting information to another server. Sylow schemas are defined using the JSON Schema standards, and as such they can also reference other schemas and add their own fields through nesting or inheritance if necessary.

Sylow comes with some built-in schemas, including for social media statuses, photos, general files, essays (blog posts) and more. Custom schemas can also be used by referencing an externally-hosted JSON Schema. A Sylow server will then look up this externally-hosted schema and use it for validating incoming documents. Servers can be set to allow or refuse custom schemas as the server operator sees fit.


Authentication with Sylow happens in three ways:

  1. Administrative functions, like creating a new account or adding a new device, are done using password-based authentication. First, a user's salt is retrieved from the server. Next, this salt is used on the client side to assemble a Scrypt hash of the user's password. This hash is then transmitted to the server, and if this hash matches with what is stored for that user, the user is allowed access to the administrative function in question. This is done so that the user can potentially use the same password for administrative functions as they use for protecting their file encryption key.
  2. Device authentication with the server, including fetching lists of documents, creating them or modifying them is done using an OAuth2 token and scope system.
  3. Server-to-server communication is performed using signatures computed from a server's private/public key infrastructure.


Sylow encrypts the content and metadata of communications using a combination of methods. Each entity has a public key and a private key, the latter of which is encrypted by a password and stored with the server. This public/private key combo is used to prove entity (identity) ownership, as well as encrypt documents that are shared with other entities and servers.

Each document has a symmetric encryption key which is used to encrypt the contents of the document. This key is encrypted with the entity's private key and stored alongside the document. The document can then be decrypted by the user by first decrypting the individual document's key and then using said key to decrypt the document.

When a document is shared with another entity, the device looks up its saved copy of the foreign entity's public key, then uses this to encrypt the individual document's key, and sends the document and encrypted key to its server. The server then handles the delivery of the document to the server of the foreign entity.

Full Example

Bob uses a social media application with his Sylow server to post some interesting stuff.

  1. Bob opens the social media client on his smartphone.
  2. The client registers with Bob's Sylow server as a unique device using OAuth2, and receives permission to create posts on Bob's behalf.
  3. Bob creates a social media post using his device.
  4. The device uses Bob's password to decrypt a locally-stored copy of his entity's private key.
  5. The device generates a symmetric encryption key to encrypt the content of his new social media post, then uses the decrypted private key to encrypt said symmetric key.
  6. The device also encrypts the symmetric key with the public key for each person that follows Bob, and uploads all of these keys to his server alongside the encrypted document.
  7. Bob's server looks up the server address for each person that follows Bob, then sends each server a copy of the document with the appropriate symmetric key.

Design Principles

The design principles of Sylow can be summed up as the following:

Put simply, Sylow is intended to provide a basic framework for formatting, storing and exchanging content. Beyond that, it should provide individual users the tools to create a much more robust system on top of that, but should not enforce any standards that are not absolutely necessary for the proper performance of the system.


Sylow is a work in progress, and we'd love additional help with the server implementation, protocol and in creating new applications. We're located on Github and you can check out all of our repos there, which we try to keep up-to-date with issues (new features) and milestones (release roadmaps). Give us a shout if you have a cool idea or you want more information on how to contribute or build with Sylow. ❤️