This post was originally published on lettermesh.com.

Radiks is a framework for building complex and collaborative decentralized applications, using Blockstack infrastructure under the hood. It’s built to solve a few of the main problems I’ve found while building dapps on both Ethereum and Blockstack. It tries to solve the three main pain points that I think all dapps eventually run into: the ‘aggregation’, ‘modeling’, and ‘collaboration’ problems. Many dapps have created custom solutions to solve these problems, but I wanted to build a framework that would provide a generalized solution. After all, I want to see more great dapps out in the world.

The ‘Aggregation’ problem.

There are a variety of solutions when it comes to storing data in a decentralized way. Blockstack apps store user data on Gaia hubs, which can be hosted by any user, which allows them to store their data wherever they want. This provides a level of data ownership that is unmatched by other networks.

The hard part comes when you’re building an application that needs to aggregate and query data that is stored on Gaia. The fact that any user can use their own Gaia hub means that your application’s data can live on a bunch of different servers, so there is no way to filter or aggregate data across different users. Most decentralized applications end up building an ‘indexer’, which keeps track of decentralized data using a centralized database.

Radiks-server is a server-side library that you can drop into your application or deploy on its own. It provides APIs for saving, updating, validating, and querying data that is stored in Gaia. It keeps track of everything in a centralized database, but it’s built to make sure that the data in Gaia is the central source of truth. It has built in support for validating all writes, using signatures, so that you can verify that all data was actually signed by a specific user, and not tampered with.

The ‘modeling’ problem.

Gaia hubs are a simple key-value store. This makes them quite powerful, because the design allows Gaia hubs to remain stateless, and you can store anything from JSON to multimedia on a Gaia hub. Most Blockstack apps represent their app’s data with JSON files, and they roll their own solution for saving, fetching, and update their app state through JSON. Privacy-focused apps also need to take care of encrypting and decrypting data as it flows through their app.

Radiks provides a familiar API for creating models to represent your data. It looks and acts like ORMs you’re probably familiar with, like Mongoose or ActiveRecord. You can define schemas, methods, and relationships, and then easily query and filter models as you’d like.

Radiks is built to support privacy, while still being able to leverage the indexer when fetching data. You can define encryption support on a per-field basis, so that sensitive fields are encrypted, but indexable fields, which contain no sensitive information, are not encrypted. For example, consider a “todo” app. It has multiple projects, and each project has a bunch of tasks. The ‘Task’ model might have three fields – “title”, “projectId”, and “completed”. You’d want to encrypt the “title” field, because that’s private information. You don’t need to encrypt the “projectId”, and maybe not even the “completed” field, because they don’t provide very sensitive data on their own. By not encrypting it, you can query the indexer for all tasks that are incomplete in a specific project. This gives your app a big performance boost, because otherwise you’d have to keep everything in memory, and do your filtering in an unoptimized environment.

The ‘collaboration’ problem.

One of the most complex issues I’ve run into with decentralized apps is support for collaboration in a private, decentralized way. There are a bunch of tough problems with trying to support collaboration. When you have a bunch of users collaborating on private data, you need to keep track of a shared encryption key that everyone in the group has access to. You need to provide ways for users to invite and discover their collaborators. You need to rotate keys when a collaborator is removed from the group.

In centralized apps, this functionality is rather standard and easy to support. Doing it in a decentralized way, with maximum support for privacy, is much harder. Radiks takes care of all of this for you, so that you can write collaboration logic using friendly APIs.

Because collaborative apps often have the highest need for privacy, Radiks is built so that, if you’re not in a collaborative group, you have no knowledge of who is in the group. I think this is a big requirement, and further complicates things, but it’s worth it. For example, a privacy-focused decentralized messaging app should not disclose who is talking to whom, even if the message contents are encrypted. Radiks provides this guarantee.

I hope this post helps outline some of the reasons for why I built Radiks, and how it may be interesting to you. If you want to start digging in, here are some good resources:

At the time of writing, Radiks is still in early stages. Please reach out or open a Github issue if you have any questions, comments, or concerns. I’d love to help you out if you’re thinking about building an app with Radiks.