Data Independence Network

Keeping data in user's hands.

The Cooperative

The mission of Data Independence Network LCA PBC (a Colorado Public Benefit Corporation) is keeping data in users hands, providing support networks, aggregating group opinions.

Keeping data in users hands

The starting goal of DIN is keeping data in users hands, instead of the hands of centralized corporations. While not all data may decentralized we believe that an increasingly large percentage of it may indeed be shared directly between the people, without any commercial intermediary.

Providing Support Networks

We have very ambitions goals for building support networks. We'll start out with setting up open-source digital infrastructure for a community support network in Denver Metro Area. Once we have the bugs worked out we'll provide instructions on how other areas can setup their own networks. We think it makes sense for support networks to be reasonably local, while allowing for outside help and interaction between networks.

Aggregating Group Opinions

We are working on Votecube to promote aggregation of group opinion to and help people gain insights into the mass media and public opinions. Once launched Votecube will also help solve global issues by connecting people locally and internationally. It will promote promote cross-cultural understanding on issues that affect everyone across the planet by contrasting the voting outcomes. We expect Votecube's opinion aggregation to be useful for all kinds of non-governmental associations, from families to large organized groups.

The Team

Nikolay Dobrinov
Dr. Nikolay Dobrinov

Statistical Modeling & Analysis, Economics

Andrei Belitski
Dr. Andrei Belitski

Machine Learning & AI, Analytics

Brian Gill
Brian Gill

Application Development

Artem Shamsutdinov
Artem Shamsutdinov

Framework Development

Why: Data

The problem

The new DApps are gaining more functionality, getting more complex and currently the number of applications devs is limited due to a steep learning curve. For the majority of Software Engineers (who are used to working with relational databases) it is hard to write applications with complex data schemas.

Our solution

Our target users are developers for Distributed Applications. AIRport allows multiple applications to share the same schemas. It also allows to independently track data as Repositories. A Repository is a virtual database tracked in a number of tables across any number of schemas. At a high level, it's a "virtual interface" between applications and schemas.


  • Allows the Application End Users to seamlessly share the data only with selected Users.
  • Lowers the barrier to entry for new Apps as they can reuse existing schemas or write add-on functionality to existing Apps.
  • Lowers the barrier to entry by providing exiting data to new Apps.
  • Allows hybrid applications where part of the data is centralized (for large scale sharing) and part is in private Repositories.
For example in an event tracking App data for each event is a separate Repository. Other Applications can build upon this App's schema and provide functionality (such as event specific chat and voting systems) in their own schemas. Using all of these Apps the users add data to the same Repositories (for the the same events). Thus Repositories for events span schemas of all the Apps that together provide better functionality than each one separately. AIRport enables synergies between Apps where "the whole is greater than the sum its parts" thus reducing the overall costs.

Getting it right

AIRport offers refined, high productivity developer APIS:

  • Simplified JPA annotations (no session concept, easier relations)
  • GraphQL like query API
  • GraphQL/Firebase like hybrid solution for mutation & access rules.
  • Automatic schema generation and installation
AIRport is fully functional off-line, commits are made locally and are added to the "longest chain" once device is back on-line.

It is meant to run as a background app and can be used by both native and web applications on the device (while also providing a web-only preview with WebSql):

The process of installing AIRport is:

  • User navigates to a consumer Application that uses AIRport and creates a private Repository
  • Application prompts the user to install AIRport database App (if it's not installed already)
  • User installs AIRport App and navigates back to the application
  • The consumer application creates the private Repository and prompts the user for who to share it with
  • User shares the repository and the other users of that repository are notified

Why: Group Opinion

Coming Soon

Why: Support Networks

In Planning - Denver Support Network

In Planning - Denver Project Fund


Written in AIRport

Here is the application being developed with Autonomous Interdependent Repositories. AIRport is the reference implementation of AIR and the list of apps using it will be growing.


3D Decision making aid

Votecube is a global opinion aggregator. We help solve global issues by connecting people locally and internationally. We promote cross-cultural understanding on issues that affect everyone across the planet by contrasting the voting outcomes.

About the Project

The Story
The Story

In 2015 I (Artem V Shamsutdinov) wrote an Organizer app but wasn't satisfied with data sharing options available. I wanted to come up with a platform that allowed for secure and confidential data sharing between any number of individuals and organizations. So I started down that route in 2016 thinking that it will be a quick 3 month project. Several years of on-the-side development later AIRport suite is finally approaching readiness and Data Independence Network is now a project with aspirations of revolutionizing how the planet stores its data!

The Vision
The Vision

The future of computing is mobile. The smartphone finally has the resources required to do all of the data processing locally. CPU and RAM are plenty enough to run a personal database and all associated application logic. Storage is fast approaching the same point. I estimate that once smart phone storage reaches 1TB the question of "Why do a need that server again?" will be on every mobile developer's mind. It is possible that by 2025 every mobile smartphone will be storing most of data relevant to its user locally. Of course most of the planet's data is shared by multiple people. Autonomous Interpendent Repositories (AIR - US10902016B2) is our answer to how efficiently and securely manage that data.

The Technology
The Technology

AIR splits the data into virtual Repositories. They are virtual because any number of them can live in a standard (relational) database. These Repositories are fully autonomous and contain all of the data they need to be usable. Any given Repository is shared independently of all other repositories, via serialized Transaction Logs. The repositories are interdependent and can reference each other, hence building comprehensive data sets out of unique units of knowledge. AIRport Server (by default is a mobile app) that runs in the background and serves data to all of the Apps and Web pages running on that device. AIRport Client is a thin client library (installed by these Apps and Web sites) that deals with ORM, entity caching and general CRUD.


AIRport provides a net-like relational database of Repositories. Repositories are virtual databases, each with its own transaction log. Each Repository has a globally unique identifier that allows to distinguish it from other repositories in the same relational database (such as WebSql, or SqLite in a Cordova based App). For two Users to share a Repository it must be present on their devices, and the schemas used by that repository must be installed in AIRport databases on those devices.

Each device/phone contains a single AIRport database that is shared by all applications on that device. The composition of the applications on each device can be different. The composition of the schemas installed in each AIRport database on each device can be different as well. Each database contains only the Repositories the user of that device decides to keep on it.

AIRport Repositories have blockchain based transaction log storage to enable communication between devices. AIRport is fully functional off-line, commits are made locally and are added to the "longest chain" once device is back on-line. Each Repository transaction log is a separate chain and itself can consist of sub-chains if devices go out of sync. Thus, the Repository transaction log is a Directed Acyclic Graph with each commit being a separate block and all sub-chains are resolved to the "longest chain" via timestamp based conflict resolution mechanism.



AIR splits the data in a relational database into repositories. Each repository spans multiple tables. Each table contains records from any number of repositories. A repository is autonomous and represents a stand-alone unit of knowledge. Repositories are interdependent and can reference other repositories. A repository referencing other repositories can be used on its own (without others being present). A repository is stored in a ledger (transaction log) that is distributed between member devices (PC, mobile, IoT). It is secured and authenticated using standard data security mechanisms. A repository has a unique transaction order on each device. An overall order is computed for a repository as all member devices synchronize. An AIR application controls access to its database schema by other applications. CRUD (create/read/update/delete) access is determined on per-table basis. A user controls repository access by applications. She also determines access to her repositories by other users. Each device can contain only the repositories to which its user has access to. Globally repositories form an interconnected database. A device stores AIR data in a database shared by all Apps on that device.

How it works


AIRport Database servers AIR Repositories and is located right on every user's device. It contains only the data that the user contains and as much of it as the user decides to keep on that device (while archiving the rest). Since it's hosted locally on the device every database operation is as fast as that device allows it to be - no central server outages or overloads, no network deplays. Just the data that you need, when you need it.


Entity classes are decorated with JPA annotations. From them AIR dev tools generate a query API, which is then used in "TypeScript Instrumented Query Language" (TIQL) notation. It integrates SQL with TypeScript (with JSON-like query definition). This enables strict compile-time checks and query auto-completion. If you know JSON and SQL you can create and read TIQL queries. By default the select clause specifies object graphs and AIRport Query API retrieves fully interlinked object graphs (with more flat formats possible).


Every transaction for each AIR repository is signed by the Device+User+Application combination to ensure authenticity. It is also encrypted using repository specific key. Only the users that need to access or modify that repository are allowed to access/modify it. Transactions are (by default) shared directly between devices with no third party hosting services.



Say Hello.

We are eager to collaborate with individuals and organizations that have alike goals.