Beyond Decentralized is about fairly storing and sharing data. It's first framework AIRport aims to enable DApp building on top of an Internet of Databases.

First Turbase Apps

For a while now there has been a plan to run Sapoto.net and Votecube.com as the first Apps on Turbase. Sapoto.net is a social support network and Votecube is a public opinion poll record. These are very important projects but there is something even more important that recent events brought up.
...

No record copies in DB

With the current solution of copying records between Repositories there would still be multiple records in the database for the same exact record - one per repository that has a copy of that record. This is hard to maintain and comes with a performance penalty.
...

Turbase the Network

Storage of Repository data is pretty straight forward - every entry in its transaction log can be a separate file, timestamped at the time of its creation (preferably the proven time of persistence of the transaction log entry). But the retrieval of data is a lot more complex.
...

Dependency-First Queries

This morning I finally arrived at the idea of how to efficiently and effectively ensure repository Atomicity at query time.
...

Cross Repository OneToManys

As it stands right now, repositories are linked via @ManyToOne relationships. This is easy to do since the Many side of the relationship contains the foreign key into the parent table. However, as I've been writing the first internally provided DApps I realized that there is a need for linking from the @OneToMany side as well. And the proposed solution opens up the possibility of a Graph database implementation on top of AIRport.
...

SQL Queries

I've recently learned that some organizations value working with raw SQL. Keeping your queries in raw SQL makes sense and I am starting to design an additional, SQL-first ORM for AIRport.
...

Gate-keeping persistence

AIRport has a very useful feature: all objects passed into @Api() methods get updated with the latest state (when they are returned back to the Client). This is very useful - the Client doesn't have to re-query the object to get the latest state: less code to write and maintain (and faster applications). However there are cases where objects in the passed in object graph must be overwritten.
...

At last, just Ids

As I'm using AIRport APIs I'm realizing that the existing records passed into AIRport APIs need to be verified as such. This is leading me to finalize the Id API for AIRport.
...

The Internet came together as a miracle, really. Anyone with a wire can publish, we need to keep it that way.

Barry Diller

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 virtually decentralized databases. ...

Solving Id Problems

AIRport Id scheme has an optimization for local storage of globally unique Ids. It is a limiting factor that is leading to a new way of doing things.
...

Short Queries

One thing I'm starting to think about is adoption of AIRport. It will certainly be useful for building production applications but it's query syntax lacks a bit when it comes to quickly cranking out prototypes.
...

AIR UuId

Working with raw AIRport ids is cumbersome. The reason for that is the fact that an Id of an entity is spread across 3 different entities:
...

Dependency Injection

A key factor in Turbase (and thus AIRport) adoption will be the ease of writing applications. One key feature that needs to be done in a developer friendly way is Dependency Injection.
...

Application Interoperability

A key feature of AIRport framework is the ability of applications to interoperate. This is possible because of two reasons:
...

Follow the Many to Ones

As the name states, Autonomous Interdependent Repositories are meant to be interdependent. This basically means that records in one repository can have columns with ids pointing to records in other repositories. In itself its a simple concept however it presents a number of technical issues when actually implemented.
...

Highway - Repository Turn

Recently I've have arrived at a breakthough in thinking about how Highway can be implemented in a strait forward and simple way, provided that some assumptions are kept about underlying data usage.
...

More on APIs

Recently I got the inital implementation of application isolates working (in browser only, without pulling application code from remote location) and as part of that did a pass on API implementations.
...

Everything as Repository

Unlike JPA/Hibernate, AIRport entity management is sessionless. The way it accomplishes change detection is via original values tracking in a hidden object property. Recently I've been debugging Insert vs Update detection and realized that everything is easier with Ids that are generated. If the Id is present in the input it cannot be an Insert. That got me thinking - should all entities be forced to have generated Ids?
...

Migrating the data

Schema migrations are hard in general. In AIRport/Turbase schema migrations are even harder for a number of reasons:
...

Securing Turbase data

In AIRport any given virtual repository can be in multiple states at the same time. This is because multiple users can be using the same virtual repository. Since they may be using a repository while being offline, the repository will get out of sync with the rest of the devices that have it. Hence, to keep track of that Turbase version controls all of virtual repositories using a simple Directed Acyclical Graph. ...

Turbase - AIRport with Advertisement Engine

For a while now AIRport has been the brand for the AIR technology. And also for quite some time we've been dicussing building an adverisement engine on top of AIRport to generate revenue that can be shared with Apps and users. Now finally I've come up with a good enough of a brand for the actual App that will be installed on phones and other devices - Turbase. ...

Interdependent Components

I've now come to a full realization of what logic in isloates mean - locally-run vetted components. This trully changes the way AIRport applications can be written. Apps are no longer required to maintain expensive (to most people on the planet) server side components. Also that allows for a degree of independent developer specialization that is already standard among most professional programmers and UI designers. ...

Injecting schemas

Internally Airport used "on the stack", token based dependency injection to allow for seamless framework upgrades on each device. However this type of injection is non-standard and can throw schema developers off (as something unfamiliar and therefore unnatural). With introduction of isolates adding more tranditional constructor based dependency injection scheme becomes possible. ...

Schemas in action

The next step after code execution isolates and schema upgrade strategy is defining exactly how schemas will be installed and how they will run. Here is my first (detailed) take on it. ...

Schema Interoperability and Upgrades

Naturally occurring
Another issue that has been bugging me for quite some time is how exactly schema upgrades will work. My initial thoughts have been about building a framework that will enforce backwards compatibility for schemas. Switching to natural DAO logic lead me to re-think the approach and make it more natural, give more freedom to schema developers and define schema interoperability rules.
...

To boldly Go and isolate

The solution to natural DAO logic
For quite a while now I've been dreading having to write Firebase-like rules for mutation logic. I have a number of reservations about writing a custom syntax engine:
...

Free at Last

4 month have passed since my last blog post and I didn't have any time to devote to coding. Hence I'm open sourcing the projects "as is" (with a bit of additional documentation).
...

Highway - The Begining

I haven't head as much time as I have hoped to develop Highway last year. So during the beginning of this year I'm focusing on developing a prototype product based on Highway and developing Highway itself in the process.
...

Transactionality

Ability to support transactions has always been important with AIR but the API has been in flux until now. Here is the description of the final version of the API.
...

Highway

Quite a bit of code written as part of the Airport effort really has little to do with the concept of Autonomous Interdependent Repositories (AIR).
Here is a list core, already working features...

Air Tower = IPFS/Peergos + Airport

Since the beginning of the Airport project the question of how to share data was outstanding.  Eventually I started the automated-gateway-transit library to act as a gateway between airport instances...

Airport in Cordova

Initial designs behind Airport called for an all-in-browser framework. However after I did enough research this proved to be impractical for the following reasons...

Build time Queries

Just like with persistence operations it is possible to process query operations at build time, while keeping all of the benefits of TypeScript type checking and auto-completion

First Application

The relevant part of the first Airport application Votecube has been finished. The application itself is still a prototype (currently running on Firebase) and is yet to get it's long term back-end. But the font end is finished! ...