ONE first principles

juergen.geck@refinio.net, 20191003

20181218

intended audience:        All stakeholders

why it is

We want everybody to be in a position to fully control their data. We believe that this requires software which is compatible with their data to be freely available. We further believe that this software must be able to run locally. Most of us have amassed quite a collection of computers, ranging from mobile phones, to tablets, to laptops, Network Attached Storage servers, and hosted servers. For simplicity we will call all such computers devices.

And we believe data should be distributed amongst all of its owner’s computers together with the software, where said distribution gets managed by the software. The software must be freely downloadable. The owner of the computer can then run our software, at her discretion, providing services to herself and to others, optionally independently from the rest of the Internet.

what it is

ONE is a system of tools to manage individual data, data formats, and software in one consistent approach. By sharing configuration data it puts devices under the control of their owner. It has been designed from the ground up to be consistent, local, user centric, secure, and hardware agnostic.

With compatibility, interoperability, security, privacy, and ubiquity as design end points.

With no limitations to adding more data and data types, no limitations to the number of software add-ons to exploit said data, no limitations to duration of storage, and no limitations to hardware platforms it runs on.

how it is different

All ONE objects reference the specific software defining their meaning.

ONE can resolve software dependencies from the perspective of data, and automatically provides all necessary software locally, on every device.

top down

ONE is an abstraction for user interaction with apps. Atoms of such interactions are ONE.actions, depending on data type definitions, and on program code defining the meaning of data types.

market trends

• Massive compute power and storage growth in individual and mobile devices
• Chip / fab evolution vs general purpose computing requirements, i.e.
  Minimum compute capacity in microcontrollers vs. price performance evolution
• Maintenance argument

• Ongoing hardware market life expectancy reduction requires hardware abstraction
• Growth of minimum Chip Fab products meets
  Price performance wall - e.g. Grundig
• Hardware manufacturers will have to move
  from providing Development Environments to Standard Runtime support
• Toolchain evolution provides for availability of runtimes

why nobody else has done it

1. But-This-Is-How-We-Always-Did-It argument:
   If you keep repeating the same mistakes you will never see them as such.
   We have all gotten used to software being incompatible, data and code being locked into silos, platforms being owned by US West Coast Corporations, nobody but MIT could educate the next Zuckerberg etc.
   Who would expect smart software startups to originate anywhere but in Stanford?
   Europe has given up. Germany has given up. Pathetic. No more.
2. Education failure argument:

Complexity is bad, webpages are dumb, data in end users’ hands is dangerous, deploying software is silly, the cloud is good, and so on.
We, as humans, have evolved over 4bn years to become highly federated, massively parallel computers able to parse this here sentence. Facebook, Google and Microsoft are very valuable companies. So we must replicate their approaches. Find the problem.

3. Historical argument:
   Price performance in compute hardware is only getting to the point where ONE becomes possible now.
   Also, the usual genesis of platforms is an app having grown too fat, and a platform being spun off to make things bearable again. With ONE the platform has been there first, with products now being deployed into an environment built for them.
4. Experience argument:
   We are a very experienced team
5. Centralized monetization argument (-breakdown)
   Refinio charges for maintenance and customization services for certified versions of the software for e.g. the medical or education space. For brokering data between supply and demand (-> matching.one) Refinio charges a service fee.

   ---

first principles

1. HTML is the most ubiquitous, versatile data container in existence. This gives us confidence that data represented in HTML can be long lived. For semantics we use a W3C draft called Microdata (https://www.w3.org/TR/microdata/).
   
   ONE stores data as objects presented in Microdata in HTML

2. All data is metadata.
   All data describes some aspect of one reality. All data describing other data is just yet more data stored in ONE, starting with the owner of an Instance.
   
   ONE stores context
   
3. ONE transactions are documented within ONE.

For every transaction a Plan object gets created first, containing method and parameters. ONE evaluates such Plan objects, and stores the result as an object in a Story object, together with the Plan object. By evaluating Story objects, ONE can re-use pre-existing results.^[1] 
The Story object of a specific version of an Instance object is the root object of a Merkle Tree, which contains all objects in this version.

ONE data can be rolled back, rolled forward, and has a full audit log

4. ONE does not delete data without context. All ONE objects remain in ONE. Deleted objects are described by Deleted (a ONE data type) objects. Objects in Deleted objects can be deleted without losing the integrity of ONE.
   To fully erase data requires an incomplete copy of an Instance to be created.
   
   ONE has an immutable memory
   
5. JS (Javascript) is the natural complement to process HTML. We decided to use JS because of its ubiquity. And we decided to use nothing but JS to harvest the benefits of a homogenous technology platform. JS is static content which can be wrapped in HTML. ONE treats JS code as yet more data.
   
   ONE manages its own software.
   
6. ONE data types are defined by JS code.
   
   In ONE the code is the spec.

Necessary definitions

ONE objects are stored as Microdata objects in HTML. All objects in ONE can either be stored in one file, or separately, in one file per object, and then be connected by Reference objects containing the cryptographic hash value of their member objects. Because files are named after the hash value of their content, and because these hash values are stored in Reference objects, Reference objects form a Merkle Tree.

ONE maintains internal indexes called Maps to support the traversion of the data tree towards its root. ONE objects contain id fields, with the ID hash of an object being calculated with non-id fields stripped. Maps are named after the ID hash.

Deletion of objects in ONE retains documentation of the deleted data.
To fully delete data, the ONE Instance holding it must be replaced by a new instance holding all but the deleted data.

Transactions in ONE are defined in ONE objects called Plan. Plan objects reference immutable functions and their parameters. After a Plan object has been evaluated, the Plan object and the result are referenced in a Story object. Story objects are the memories of ONE.

ONE instances can easily replicate themselves, and keep replicas in sync. By doing so ONE leverages the same strategy for long term storage like nature does in cells. Replicas can be stored images or live systems, the latter providing a superior type of backup over existing solutions.

ONE is designed from the user perspective, looking down into the technology stack, e.g. the presentation layer is from where we started defining ONE’s architecture.
APIs for ONE are not abstracting hardware or middleware, but rather look the other way, “up the stack”, they abstract user and sensor interaction.

Examples for resulting abilities of ONE

• Owners consume ONE objects, and produce ONE objects called Actions when interacting with a UI, which defines and implements user primitives.
  ONE becomes an OS around owners, rather than around hardware.
• Data queries are based on transactions providing a fixed version of the internal data tree in ONE at any time.
• Instances of ONE communicate via shared storage, represented by ONE Chum objects, and are based on the access rights defined in ONE Access objects.
• Because ONE Instances can be synchronized, ONE user interface modules can also be synchronized. Clusters of instances of ONE running the same app can emerge. Swarms of instances of ONE, sharing sets of data, can emerge. This means that the numbers of endpoints for interactions with data content are only restricted by resources, i.e. bandwidth and compute power, not by properties of the software or configuration.

What is not there cannot break. External libraries we do not use do not limit our ability to support new runtime environments, and business models.

Be scarce in what we use.

Don’t take decisions away from the owner. If in doubt, afford an extra configuration option rather than to just assume some configuration. And get out of the way as much as possible.

Be humble in UI design.

naming

We at Refinio believe that we have to start with one building block as a template, just like complex life started with the first Eukaryotic Cell, and then have many similar ones, which are compatible from the beginning. So we built ONE.

Google, their company name, is derived from 10 to the power of 100.

With ONE, Refinio is taking the opposite approach. We share Google’s mission statement to “Organize the world’s information and make it universally accessible and useful.“.

Where we differ is in that the organizing should take place in the hands and under the control of individuals.

We aim for more computers per data, and many of the same.