Beyond Decentralized

In 2015 I wrote a Family Organizer and realized that families would have to trust a company with their plans. I started to write a relational adapter for Google Docs to store data in personal accounts. Overtime it evolved into AIRport . I have been thinking that AIRport can also work in centralized environments and seamlessly serve both centralized and decentralized data. Now I'm realizing how siloed, centralized databases can join a fine-grained, privacy oriented network of databases.

Decentralized

In the decentralized environment AIRport runs on user devices. Apps are loaded in VMs and inter-operate through AIRport. Data never goes out to third-party servers and stays in a database on user's device. Repositories are maintained in IFPS and Arweave. This works well for family and friends data but does not work for situations where data is shared with the general public. AIRport Applications can with the data from central servers but that data would still be siloed.

Organizational

Luckily, I had to learn OAuth recently. This made me realize that there already is an authorization infrastructure for internet-scale interoperation. Apps are already talking to APIs everywhere, they just aren't sharing a common database. This is what the Data Independence Network tries to answer - how to keep data locally and allow to share it globally, in a secure and fair way.

The industry already has a technical solution for a global database. Relational databases like CockroachDB already let you partition relational tables and schemas geographically or in just about any other way. But this means that everyone has to be on the same distributed database. Singing up everyone for (and placing everything in) the same database is not likely to work. What is needed is an internet of databases. There has to be a way to share just the right amount of data to fulfill the needs of the calling App for a particular User.

How

This is where AIRport excels - each Repository is meant to have all of the information needed to fulfill functions associated with that data and also can automatically be linked with more related data, if and when needed. Because each Repository hop is a distinct operation, AIRport answers the who, what, when, where, why and how questions on data sharing.

Permissions

Of course enforcing rules on per-repository basis is hard to accomplish manually. The technical side of doing so is easily accomplished by OAuth but figuring out if a given App+User should have a permsission to a given repository is not a trivial task. It is possible to come with and maintain a database of permissions (and in some cases it will be the way to go) but for (likely) the vast majority of the cases large scale data modeling, per-repository pre-flight text processing and artificial intelligence will be required.

Adapting Repositories

Another question is how to take an existing centralized relational database and break it up into pieces. After adding REPOSITORY_ID and REPOSITORY_ACTOR_ID columns something will have to figure out what data belongs to which repository. Here, for fast majority of the cases following the @OneToMany and @ManyToOne links in the data will allow you to isolate data groupings eligible for being Repositories. If there are logical rules for spitting the data, filters can be written that will narrow the boundaries of Repositories as they are first being retrieved and defined. And for very large databases, models can be trained on data samples and then deployed to govern Repository boundaries for all of the data.

Or just plugging in

In certain cases it may not be required to split up relational databases at all. This can be done when AIRport is running in an environment protected by the organization that is sharing its data. With additional AIRport hooks that Organization can write apps that will provide security rules for all queries performed against it's data. This will allow other third-party Applications to Run on the same server and to join Repositories from other databases to still-centralized data of this Organization. The core requirement for interoperability at this level is publishing of the Organization's schema definition for others to see and build queries against.

Ultimately the sharing granularity provided by Repositories, combined with ability to separate Data providers from Application providers gives the ability for Applications to share data across companies and jurisdictions without compromising privacy of those companies and jurisdictions. This is accomplished because AIRport controls all database access and API operation flow, and acts as a temporary custodian for the data. Applications just run in locked down VMs and can't send or receive data from anything other than AIRport server. AIRport controls all interoperation with other local Applications and other AIRport servers.

With a bit more work AIRport will share data across multiple databases, schemas, devices, applications and users. It is designed to so in end-users best interests - in the interestests of the every day families and friends. There is a lot of work ahead to bring it to the public and much more work to get it adopted. After the first AIRport applications are deployed and first central databases are based on it, to take it to the internet level the next big question will be - how to ensure that AIRport servers can be trusted by all parties involved.