Control your own data – Develop and share knowledge – Create your digital self

A future where there is a Kontekst running for every single human.

• Storing data
• Keeping track of events
• Analyzing data
• Running AI
• Freeing up time and capacity

All controlled and owned by the person!

Contextus, joining, weaving, structure, connected, unbroken

In many Apps the full user-interface state is only kept for what is currently being displayed and the App code handles navigation from page to page or view to view. Opening, closing and re-creating views, state and data as needed.

In the Kontekst Apps we keep the full App state as if all pages and views are open at the same time. This allows us to easily adopt the Apps to different devices and an increasing available display surface. From the minimal view of a mobile phone to a full-blown multi widescreen desktop setup.

The App state is separated from the display code and hooked in using event streams where each stream is the current data for a page or part of a view. When a change occurs the display code listens to the stream and updates with the data from the event. When the user interacts with the display an event is created and sent to a sink (input to a stream). The state code handles incoming events on sinks and creates outgoing events on streams according to the business logic of the App. A single incoming event can result in multiple outgoing events updating different parts of the user-interface.

Take an App for accessing multiple e-mail accounts at the same time. On mobile it would consist of a list of inboxes where the user can select to open one. The App would navigate to a list of e-emails in that inbox and further on to open one of the e-mails. When the App runs on devices with bigger display the view would change to display the list of e-mails and an open e-mail at the same time. Even expanding to show the list of inboxes, e-mails and an e-email.

Kontekst uses a form of one-time key encryption for communication between users, agents and Apps. A new encryption key is used for each message and once the message has been received the key is destroyed. If someone were to monitor or intercept messages sent and received they would have to gain access to the key in almost real-time to be able to decrypt the message. Even if they gained access to one key, it would only unlock a single message.

There are two case variations on the one-time key encryption concept. (Authentication, assuring the identity of A and B is left out)

Agent A wants to send a message to agent B (push)

1. Agent A sends a request for a one-time key to agent B.
2. Agent B generates a one-time key consisting of a private key, a public key and a GUID. Then sends the public key and GUID to agent A and stores the private key and GUID.
3. Agent A encrypts the message using the public key and sends it to agent B along with the GUID.
4. Agent B receives and decrypts the message with the private key belonging to the GUID.
5. Agent B destroys the private key.

Agent A requests information from agent B (pull)

1. Agent A generates a one-time key consisting of a private key, a public key and a GUID. Then sends a request for information to agent B, including the public key and GUID.
2. Agent B encrypts the reply message using the public key and sends it to agent A along with the GUID.
3. Agent A receives and decrypts the message with the private key belonging to the GUID.
4. Agent A destroys the private key.

In both cases the private key that can decrypt a message never leaves the receiver and only exists during the message exchange. A time-to-live value can be set on a key to further reduce the risk of interception. In reality gaining access to the private key would mean having access to the device the agent is running on, which most likely would mean being able to read the decrypted messages directly.

The Kontekst concept for handling and storing User and Agent data let them control and own the data themselves directly. Stored locally on a device or at a service the owner provides. Access is granted run-time to Apps. With several levels of control, parts or full. The code is moved to run where the data is owned instead of moving the data to where the code is running.

The User or Agent data is never stored in a centralized location at each App provider, where administrators and other back-end or secondary systems can access it. This simplifies the over all system with handling access control, rules and regulations for personal data, risk of misuse or abuse of data, unauthorized access and complexity and cost of data storage for the App provider. He can focus on his core business of his App, leaving the complexity of securing, handling and storing personal data to an expert service provider in that area.

In its simplest implementation form the storage is locally as a file on a device (mobile, PC, pad, USB drive). A step further is a form of database running locally with an API for queries, transactions, backup and encryption. The local storage implementation has some advantages in certain cases but for most a cloud service would be better.

Take Google Drive as an example. It provides cloud file storage allowing users to access their data from any device or location. Authorization and access-control is managed by Google and the data-storage data-owner relationship is between Google and the user. At the same time a user can grant an App access to use his Google Drive (part or full) for storing files. The App provider only has to know the API for accessing data and the meta-data structure of the data, not needing direct access to the content.

In the same way a cloud service can be provided that goes beyond files to a full database depending on the needs (SQL, NoSql etc.) of an App. It can also extend to computing power and running agents in the cloud. All owned and controlled by the end-user of an App. The storage service provider is responsible for implementing all rules and regulations for data storage, ensuring security and integrity of data, scaling with demand and most important being trusted by the User.

Instead of the User having to trust multiple service and App providers and companies, across countries and different laws and regulations. He can rely on a single or a few trusted storage-handlers of his data.

Example case: Medical data in an analytics Agent
We have developed an Agent that can make predictions for the life expectancy of a person. The data required for the analysis is from different sources, one being the medical history of the person. Medical data is considered to be some the most sensitive data to handle and store. If a user were to submit his medical data to an Agent for analysis and the Agent wanted to access or store the data on a centralized server. The legal, technical and security requirements for the server would be enormous. Forcing the developers of the analytics Agent to spend time and resources on something outside their primary domain, possibly making it impossible to build the Agent at all.

With our concept the Agent runs as an App on the users mobile phone. Asking permission to use the users own database service for storing and processing data. The App collects over a period of time data about eating habits, exercise, body monitoring and other information about the person. In addition the App asks the user for authorization to access the medical records stored by the National Health Service (NHS). They are retrieved through an API provided by the NHS where citizens can access their own records. The API is used directly from the App and data is stored in the personal storage of the user along with the other data being collected.

At no point is any personal data stored or processed outside of the users own control and ownership – except in the storage service. The provider of the life expectancy Agent will never have access to any personal data or the results of its analysis. The User and Agent data is only stored and handled with direct control and authorization of the owner.

In one word, more…

The combination of machine and human intelligence. Enhancing, extending, augmenting, compensating each other.