Data Shell: Project Outline & Roadmap

3. Prototyping environment project

Prototyping web apps with data vault

3.1 What & How

Goal

This project aims to grant users full control, self-authentication and data portability by providing developers with an open standard for secure data vaults and an open prototyping environment for creating web apps based on that standard.
This project aims to provide developers with an open standard to make secure data vaults and an open prototyping environment for creating web apps based on that standard, to create an ecosystem that grants end users full control, self-authentication and data portability.

DataShell project aims to provide developers with an open prototyping environment to build web apps which separate user data from the apps themselves and comply with a data vault standard to grant users full control, self-authentication and data portability.

COMMENTS (about above):

Use the first sentence when you want to emphasize the user benefits of the project, specifically full control, self-authentication, and data portability. The sentence begins with "This project aims to grant users…" which puts the user benefits upfront. The sentence also mentions that the project provides developers with an open standard and an open prototyping environment, but these are secondary to the user benefits.
Use the second sentence when you want to emphasize the developer benefits of the project, specifically the open standard for secure data vaults and the open prototyping environment. The sentence begins with "This project aims to provide developers…" which puts the developer benefits upfront. The sentence also mentions the user benefits, but they come after the developer benefits.
Use the third sentence when you want to emphasize the technical aspect of the project, specifically the separation of user data from tools and compliance with a data vault standard. The sentence begins with "This project aims to provide developers with an open prototyping environment to build new tools which…" which puts the technical aspect upfront. The sentence also mentions the user benefits, but they come after the technical aspect.

Problem

data sovereignity

No existing p2p app decouples user data from the application, because there is no existing standard for how to do so and to enable many apps to share the mechanism
it is necessary to fullfill the promise of users-own-their-data so they can use data with other apps, export and manage access to their data
Once upon a time, in the early days of personal computers, users had all of our data on our disks and all software was reading and writing data to disk. Computers were new and operating system were not stable, disks were often crashing and backups were difficult to make and restore. Users were therefore happy when they could move more and more of their data into the cloud and didn't have to take care of backups themselves. But as users started producing more and more data, it became clear that hosting all this data isn't going to be cheap. Apps and services continued giving users free storage space but in return they got full access of their private data. User data is now a precious asset and the primary source of income for such companies and users have little control over where and how their data is stored and used online.

But today machines and systems are a lot more stable and powerful. Furthermore, peer to peer technologies have matured and they enable users to securely backup and easily restore our data across devices. What is missing is an environment and standards about how to build web apps which decouple user data from the application itself so developers can start building services that bring back the power to the users.

As soon as you sign up with a free email provider or install an operating system, you usually get some cloud storage space. Accessing your data through an online environment has become commonplace, for both, businesses and individuals. You can share everything from a grocery list with your significant other or even store sensitive documents in the cloud so you can access them from work or on the road. But to be able to have users upload, edit or create files online and pass them around, many cloud services require full access to users data. Like the extensive (and sometimes unreadable) privacy policies you already had to wade through to open your 'free' account, users do not have many options. Either you click yes and the cloud is yours, or you deny the apps all access and are left to your own devices.
The fact that you want to access your data online, does not mean you need to store it in a place where the provider requires you to hand over the keys. Especially when it is unclear who can use the keys to look around in your documents, or analyze sensitive documents simply for the sake of personally profiled advertising, which quite certainly is not what you signed up for. You would want to know where your data is, lock the doors to it yourself and keep the keys somewhere safe (without any intricate key management or cryptographic busywork).
Data portability is a personal right established in the General Data Protection Regulation (GDPR). This is in direct conflict with the desire of companies to retain users and their data. Data is often tightly coupled to the application, complicating transitioning data between services.
Big Tech companies currently dictate how digital identities are used. As a result, they have amassed vast amounts of private user data. Movements like Self-Sovereign Identity aim to give users control over their online identity.
Internet users have little control over where and how their data is stored and used online. Big Tech companies store gigabytes of data about you and know exactly which online services you use. User data is a precious asset and the primary source of income for such companies.
In our system, users are not reliant on Big Tech companies to authenticate themselves or store and host their data. User data is stored in a data vault on a device under the control of the user
The goal of this project is to design a system that gives users sovereignty not just over their identity, but also over their data.
As long as your data is on a remote server, it is not truly under your full control.

p2p/dat ecosystem perspective

It requires a lot of time and effort from a dedicated team to build p2p apps and package them cross-platform
development cycle is long, because getting users to download, try and give feedback to apps is hard because users hesitate to download unknown apps to their computers
users don't want to download anything on their computer to just try and play around
users see that if they want to commit themselves to p2p they will need to download many apps

data sovereignity

each app will have a different way of dealing with data and a different identity
users expect to have some sort of data vault and full control over their data on each app + easy way to export/import identity

p2p development

developers don't know how to think p2p and have no guidance and best practices on how to use APIs
developers need to be very experienced in many fields to build a p2p part, frontend and to package the app
developers can't quickly prototype and just play around and try to make app because it takes too much effort

p2p adoption

bringing dat in the browser has been tried many times, but developers still didn't massively start building p2p apps in the browser, why?

your data is stuff you care about
mostly you only get to interact with it in places owned by corporations
- a bit like living in someone elses house
you dont get to choose ho can see your stuff
malicious actors can follow your activities and harass you
owners of spaces can record what you do and sell information
because it is not your space, you cant decide how anything works
features can disappear overnight
your data can be changed or deleted without your consent
what if you and people you care about could band together
have your own place for your data to live
where only people who see your stuff are people you trust
nobody is selling your privacy
you decide how things work and when they should change

3.4 Roadmap

INITIAL MILESTONES

v0.1 - Core Environment

Core: portal (web server)
- web server configuration standard
- includes index.html with single script tag
- includes shim.js to import and boot kernel script (loaded via script tag)
Core: dpm OS (default WebApp OS, using web kernel)
- includes .data/* folder on portal to host all OS customization code
- defined via package.json dependencies and entry script
- uses entry script for advanced customization
Core: web kernel (web runtime patch)
- installs itself as a service worker and reloads the page
- serves the OS system html page
- serves scripts offline to load a visual shell
- can add more scripts based on package json to customize OS
- allows user shell code to be executed in runtime
- provides dpm (data package manager) to be used by user via shell commands
Core: shell
- includes a command log so user sees history of interacting with the shell
- includes a command line to type in javascript and commands for execution
- indicates vault account user is logged in with (dummy account by default)
- allows to list all data available on a specific portal (stored just in memory for now)
- add advanced formatting to all basic types of shell messages for easy debugging
- allow commonjs based import of data modules in executed code snippets
Core: dpm (data package manager)
- add basic data integrity verification mechanism
- implement support for some very limited basic commands:
  - help command to list all available package manager commands
  - commands to list all available data
  - commands to download more data
  - commands to create a user project folder and data inside it
  - commands to download some data from the browser to the users disk on the device they use
  - commands to start a specific app available (apps have access to commonjs import mechanism)
Core: vault:
- add vault mode to kernel
- specify vault message protocol to talk to kernel and apps
  - based on comlink library or similar logic
  - includes transferable arraybuffers
- implement vault message protocol to communicate with kernel and apps
- add basic permission hooks
- add basic user permission prompts (all ow all vs. deny all)
Core: sandboxing:
- adds as basic iframe based sandboxing mechanism to kernel runtime
- allows user shell code to be executed in such an iframe sandbox
- add sandbox message protocol to enable communication with sandbox
- add commands to list and spawn and shut down sandboxes

v0.2 - Basic UX/UI

vault
- wireframe basic responive data vault UI
  - list all apps/software installed
  - list all datasets created
  - indicate permissions set for a specific dataset
  - indicate permissions per portal
- implement basic iframe view and fullscreen vault view
- add UI for user to trigger actions available via data package manager such as:
  - add actions to change permissions
  - add actions to delete or add datasets
dpm OS
- nav bar
  - user account
  - offline/online indicator
  - open/close/collapse shell
  - data status indicator
- content area
  - layout design

Initial unstable release

FUTURE MILESTONES

v0.3 - Basic Editor App

basic text editor
no syntax highlighting
actions: new/open/save file
allow multiple editor tabs

v0.35 - dpm intermediate

allow installation of complex apps with dependencies from web server cache
allow export of app with multiple dependencies created via text editor in vault
- to be downloadable as zip file, which can be extracted to update web server cache

Pre-alpha release

v0.4 - Intermediate Sandboxing

based on inter in-process sandbox ocapn (object capability network)
using research from endo/lavamoat/agoric/SES
- to harden the global primordial objects
- utilizing javascript proxies and the with statement to restrict access
- using eval in this restricted context to run code sandboxed
integrate commonjs module import with in-process sandboxing
will not have DOM access

v0.5 - Advanced Sandboxing

implement fast and lightweight virtual dom
implement a DOM communication protocol between sandbox and renderer thread
- to shuttle dom updates from sandbox to renderer
- to shuttle dom events from renderer to sandbox
include basic signaling library and protocols to ease usability

v0.6 - Intermediate Vault

implement a few basic demo apps to refine permission system
make concept for different kinds of data types and structures supported to be used in apps
make concept for meaningful user permission prompts based on data
implement test library to semi-automate testing and simulating user interaction scenarios
design access control interaction
test permission system

Alpha release

v0.7 - Basic Deamon

create basic cross-platform installer for "localhost p2p data daemon"
add hyper-dht-relay to data daemon installer
add kernel code to detect and start communication with data daemon

v0.8 - Advanced dpm

allow download and publish of data packages to p2p network
enable export of data packages as p2p archives for web server cache
enable dpm to download data packages from web server cache

v0.9 - Advanced vault

enable user self-authentication and self-authenticating data structures
wrap all vault data in hypercores or similar p2p datastructures
sync them from browser cache to device disk via localhost daemon
enable sharable p2p dataset links for others to access vault data if permission is granted by user
create p2p address book of trusted peers
enable downloading datasets from peers given access was granted by those peers
enable subscription to dataset updates

Early Beta release

known bugs fixed
release

3.4.2 Project outline

portal (web server)

distributed network of "portals to download & explore dpm OS customized with data packages" many can host for users to have options
[1] a portal is a static web server which hosts:
- [1] index.html (or 404.html)
- [1] shim.js (which imports & boots bootkernel runtime)
- [2] (optional) .data/* (folder)
- [1] package.json (config/manifest file)
  - [2] to define normal and dat dependencies
  - [1] (optional) entry_script.js (=init script) (to customize system by auto installing and executing whatever is bootscript)
[1] public portal (static web servers)
- used by developers and operators to publish/promote and share new p2p web apps and bootstrap node addresses
- used by users to discover and quickly test p2p web apps and possibly share them
- hosted by trusted portal operators
- [1] work out-of-the-box in offline-first mode without the need to install anything on local system
- securely accessible under a public domain based portal url
private localhost home portal (needs native portal daemon installed)
- used by users and developers for maximum security when working with their apps and data
- used by users to securely browse the dat (=p2p network)
- run by users
- works after installation of the portal daemon by the user
- securely accessible under http://home.localhost

Bootkernel/runtime web shim (dpm OS)

Everything is a log! (not a file nor an object, but a log)
Code is tolerated inside the bootkernel only if moving it outside (e.g. permitting competing implementations), would prevent implementation of the system's required functionality.
Make each module do one thing well. To do new jobs, compose and build afresh rather than complicate old modules by adding new "features"
Expect output of every program to become input to another yet unknown program. Don't clutter output with extraneous information. Don't insist on interactive input.
We should have some ways of connecting programs like garden hose–screw in another segment when it becomes necessary to massage data in another way. This is the way of IO also.
Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

[1] user's initial portal url visit requests browser to contact portal web server to download index.html and start installation
[1] INSTALLATION: request -> portal web server: index.html + shim.js -> import + boot bootkernel.js -> restart
- [1] download and evaluate domain1/index.html with single script tag domain1/shim.js
- [1] download and evaluate domain1/shim.js to import and boot domain2/bootkernel.js
- [1] download and evaluate domain2/bootkernel.js will install itself as domain2/bootkernel.js#service_worker (BKSW) and reload page
  - SEE MORE: => in renderer session
[1] LOAD: shared kernel worker bootkernel.js#shared_worker
- [1] hosts all kernel functionality and offer syscalls API
  - [1] Kernel code handles sensitive resources and implements the security and reliability barriers between applications
- [1] wait for renderer session to connect
- [1] (re)establish & maintain kernel connection to user cached or default data vault's shared kernel shared worker (in vault mode)
  - [1] do this by using "kernel execution hook"
  - [1] @TODO(1): test if shared vault worker can be kept alive solely by a foreign shared worker holding onto a message channel
    - [1] if not: make sure to at least keep one vault iframe around in one of the app tabs and re-establish if needed
    - [1] vault (re)connection hook (optional use in case shared kernel worker has no vault connection yet)
      - spawn a vault iframe (purse mode) and use it to connect + change when user logs in or transitions to different vault
      - @TODO: maybe a vault shared worker can send a last message to vault user tunnels before last vault closes to respawn a vault
        
        unless a vault user tunnel is enough to keep vault shared worker alive )see @TODO(1)
      - [1] receive vault url and message port to forward to spawned vault url iframe to keep alive until told to shut down iframe
        
        [1] double check security implications of message channel interception
- [1] load package.json (from cache or fetch) via data-vault
  - SEE MORE: => in data vault
- [1] detects boot mode based on url and environment to prepare script loading & initialization
  - embed mode environment (app iframe) -> just for CORS)
    - SCRIPTS: viewport, (API: sandbox, package manager, vault)
  - [1] plain mode environment (app window)
    - [1] SCRIPTS: viewport, shell, (API: sandbox, package manager, vault)
  - [1] vault mode environment (vault window)
    - [1] SCRIPTS: viewport, vault, (API: sandbox, package manager)
  - [1] purse mode environment (vault iframe) -> just for CORS)
    - [1] SCRIPTS: (API: sandbox, vault)
- [1] load and initialize (extension shared worker modules) according to mode and extend kernel and offer additional "syscalls"
  - e.g. think: IOCTL => for uncommon hardware devices -> "device driver shared workers" to manage additional other resources
  - based on user settings and/or renderer session request (prompt user for permission)
- [1] sends SCRIPTS: (custom cached and/or default) init and user scripts to new session (e.g. renderer)
  - [1] includes mode SCRIPTS (always includes: vault hook script + sandbox)
    - [1] e.g. refresh/reload script to any of the renderer session (e.g. browser tabs), e.g. to trigger a "reload"
  - [1] init script (entry script from package.json)
    - [1] init.js can be shim.js by just stopping exec via throwing error and cutting away initial 2 lines later on.
  - [1] user script (user defined customization)

Renderer Session

[1] BOOT: (offline first page)
- download and evaluate BKSW/index.html from bootkernel serviceworker which includes BKSW/renderer.js

  <!doctype html><html><head><meta charset="utf-8"></head><body><script src="renderer.js"></script></body></html>

download and evaluate BKSW/renderer.js script to load (spawn or connect to) shared kernel worker domain2/bootkernel.js#shared_worker
[1] INIT: spawn user (sub)session via BKSW/renderer.js as main renderer process and run BOOT SCRIPTS
- [1] setup kernel worker execution hook to listen for initial session BOOT SCRIPTS from bootkernel worker
  - [1] Renderer is a "container-frame" (browser-vm) connected to bootkernel shared worker [BK.shw]
- [1] load bootkernel.js#shared_worker shared kernel worker (see below)
- [1] receive initial session SCRIPTS from bootkernel worker and execute them
```
// renderer "firmware"
window.kernel = new SharedWorker('https://domain2/bootkernel.js#shared_worker')
kernel.port.onmessage = ({data}) => eval(data) // renderer bootloader
```
[1] available APIs depend on protocol scripts sent by kernel based on custom renderer apps

dpmOS

@GOAL: develop system in system

create first portal with meaningful data in hand coded portal
using legacy umblical_fetch (legacy fetch for https) to pull in legacy code, turn it into "hyper" MODULES in dpm/store to later export into new portal

shared worker bootkernel














































































































































































































const renderer = new WeakMap()
onconnect = event => {
  const [port] = event.ports
  renderer.push(port)
  port.onmessage = kernel_protocol
  // @TODO: define and check connected renderer type
  // @TODO: maybe based on "kernel mode" too
  const mode = "plain"
  port.postMessage(`(${default_renderer_JS})('${mode}')`)
}
function kernel_protocol (event) {
  // ...
}
////////////////////////////////////////////////////////////////////////////////////////////////////
;(async () => {
  document.body.replaceChildren()
  document.head.replaceChildren(Object.assign(document.createElement('style'), { textContent: `
    *, *::before, *::after { box-sizing: border-box; }
    body, h1, h2, h3, h4, p, ul, ol, li, figure, figcaption, blockquote, dl, dd { margin: 0; }
    body { display: flex; flex-direction: column; min-height: 100vh; }
    iframe { border: 0; flex-grow: 1; }
    img, picture { max-width: 100%; }
    table { border-collapse: collapse; }
    html:focus-within { scroll-behavior: smooth; }
  ` }))
  document.title = 'Playground'
  
  const { port1, port2 } = new MessageChannel()
  port2.onmessage = event => {
    console.log('[kernel]:renderer>', event.data)
  }
  port2.postMessage('hello renderer')
  const kernel = { port: port1 }
  default_renderer_JS('plain', 123)
  
  async function default_renderer_JS (mode, id) { // basic renderer // @TODO: unique renderer ID
    // https://markkarpov.com/post/the-identicon-package.html
    // https://terrykwon.com/blog/visual-hashing/
    // https://jdenticon.com/#icon-Dylan
    // https://morioh.com/p/91ef450fe563
    // http://jsfiddle.net/pHv6W/
    // https://github.com/MyCryptoHQ/ethereum-blockies-base64
    // https://github.com/laurentpayot/minidenticons
    // https://siva.dev/identicons/
    // https://github.com/Lobstrco/stellar-identicon-js
    // https://dev.to/krofdrakula/improving-security-by-drawing-identicons-for-ssh-keys-24mc
    // https://www.cssscript.com/svg-identicon-generator/
    // https://www.cssscript.com/canvas-geometric-identicon-generator/
    // https://www.cssscript.com/identicon-generator-jdenticon/
    // https://www.cssscript.com/github-identicon-avatars-squareicon/
    // https://www.cssscript.com/random-cartoon-avatars-svg-faces/
    // use: package.json#name + location.href + source code hash or hyperurl and version (log index)
    if (mode !== 'plain') return document.body.innerHTML = `<h1> '${mode}' is not supported yet </h1>`
    kernel.onmessage = renderer_protocol
    function renderer_protocol (event) {
      console.log('[renderer]:kernel>', event.data)
      // ...
    }
    document.onkeydown = event => {
      const { altKey, ctrlKey, shiftKey, /*metaKey, which,*/ code, key, /*charCode, keyCode, location, */ repeat } = event
      console.log({ altKey, ctrlKey, shiftKey })
      if (altKey && ctrlKey && shiftKey) {
        console.log('shell')
        shell.hidden = true
      }
      console.log(JSON.stringify({ code, key, repeat }))
    }
    ////////////////////////////////////////////////
    // FEATURES:
    // 1. ctrl+alt+shift   => toggle shell
    
    ////////////////////////////////////////////////
    // GOAL:
    // 1. sandboxed viewport (iframe sandbox)
    // 2. default shell, replaceable by custom shell
    ////////////////////////////////////////////////
    // RENDERER KERNEL:
    const shell = sandbox(shell_JS, shell_protocol) // shell_JS is not an address, but a script
    const viewport = sandbox(viewport_JS, viewport_protocol) // viewport_JS is not an address, but a script
    document.body.append(viewport, shell)
    return
    ////////////////////////////////////////////////
    async function shell_JS (port2, ID) { // script
      document.head.replaceChildren(Object.assign(document.createElement('style'), { textContent: `
        html { background-color: black; color: lime; font-family: mono; font-size: 8px; }
        *, *::before, *::after { box-sizing: border-box; }
        body, h1, h2, h3, h4, p, ul, ol, li, figure, figcaption, blockquote, dl, dd, pre { margin: 0; }
        body { display: flex; flex-direction: column; min-height: 100vh; }
        iframe { border: 0; flex-grow: 1; }
        img, picture { max-width: 100%; }
        table { border-collapse: collapse; }
        html:focus-within { scroll-behavior: smooth; }
        input, button, textarea, select { all: unset; max-inline-size: 100%; color: white; flex-grow: 1; }
        .shell { flex-grow: 1; display: flex; flex-direction: column; height: 100%; }
        .log { display: flex; flex-direction: column; flex-grow: 1; overflow: auto; max-height: calc(100vh - 9.5px); }
        .cmd { width: 100%; display: flex; }
      ` }))
      console.log('[renderer/shell_JS]', ID)
      port2.postMessage('ping')
      port2.onmessageerror = event => console.error('error', event)
      
      port2.onmessage = onmessage
      
      document.body.append(Object.assign(document.createElement('div'), { className: 'shell', innerHTML: `
        <div class="log"></div>
        <div class="cmd">🌐alexander@seraseed.com:/dpm/store/foobar#>&nbsp;<input placeholder="type command"><a title="Keyboard Shortcuts:\n ctrL+shift+alt: toggle shell">❔</a></div>
        <!--<div>👤alexander📍seraseed📂🗂️🐚/dpm/store/foobar🛠️▶<input placeholder="type command">❓❔📡⚫🌐🌎🌍🌏 ⚪🔴🟢🟡🔵🟣🟠</div>-->
      ` }))
      const [log, { children: [input] }] = document.body.lastChild.children
      input.onkeypress = event => {
        if (event.key === 'Enter') return input.value = evaluate(input.value) || ''
      }

      Array.from({ length: 30}).map((x,i) => (input.value=i,input.onkeypress({key: 'Enter' })))
      await new Promise(ok => setTimeout(ok, 200))

      return
      function onmessage (event) {
        console.log('[renderer/shell_JS]:system>', event.data)
        // ...
      }
      function evaluate (data) {
        log.append(Object.assign(document.createElement('div'), { innerHTML: `<span>></span> <span>${data}</span>` }))
        log.scrollTop = log.scrollHeight
        port2.postMessage({ type: 'exec', data })
      }
    }
    function shell_protocol (port1, ID) { // onready
      // @TODO: messageport .close() and .onmessageerror
      console.log('[system]:renderer/shell', 'init', ID)
      port1.postMessage('hello')
      port1.onmessageerror = event => console.error('error', event)
      port1.onmessage = event => {
        console.log('[system]:renderer/shell>', event.data)
        port1.postMessage('pong')
      }
    }
    function viewport_protocol (port1, ID) { // onready
      // @TODO: messageport .close() and .onmessageerror
      console.log('[system]:renderer/viewport', 'init', ID)
      port1.postMessage('hello')
      port1.onmessageerror = event => console.error('error', event)
      port1.onmessage = event => {
        const { type, data } = event.data
        console.log('[system]:renderer/viewport>', type, data)
        port1.postMessage('ack')
      }
    }
    async function viewport_JS (port2, ID) { // script: viewport is augmented no-script iframe
      document.body.style.backgroundColor = 'darkblue'
      console.log('[renderer/viewport_JS]', ID)
      port2.postMessage('ping')
      port2.onmessageerror = event => console.error('error', event)
      port2.onmessage = event => console.log('[renderer/viewport_JS]:system>', event.data)
      await new Promise(ok => setTimeout(ok, 200))
    }
    ////////////////////////////////////////////////
    function sandbox (script, onready) {
      if (typeof script !== 'function') throw new Error('no script function provided')
      if (typeof onready !== 'function') throw new Error('no ready callback provided')
      const ID = `${Math.random()}`.slice(2) // @TODO: where to get real pids from?
      const srcdoc = `<!doctype html>
      <html>
        <head><meta charset="utf-8"></head>
        <body><script>(${firmware})(${ID}, '${location.origin}', ${script})</script></body>
      </html>`
      const opts = { srcdoc, sandbox: 'allow-scripts' } // @TODO: what about CSPs and other flags?
      const iframe = Object.assign(document.createElement('iframe'), opts)
      window.addEventListener('message', onmessage)
      console.log('[kernel]', 'spawn:iframe')
      return iframe
      function onmessage (event) {
        if (event.source !== iframe.contentWindow) return
        event.stopImmediatePropagation()
        window.removeEventListener('message', onmessage)
        const { data, ports: [port1] } = event
        console.log(`[kernel]:sandbox-${ID}>`, data)
        console.log({ port1 })
        onready(port1, ID)
      }
      async function firmware (ID, origin, script) {
        const name = `[sandbox-${ID}]`
        const AsyncFunction = (async () => {}).constructor
        const source = opener || parent
        const { port1, port2 } = new MessageChannel()
        try {
          const run = new AsyncFunction('port', 'ID', `await (${script})(port, ID)`)
          console.log(name, 'init:script')
          source.postMessage('ready', origin, [port1])
          // @TODO: could use OCAPN to sandbox scripts
          const code = await run(port2, ID)
          // @TODO: maybe await script and then close/shutdown worker/iframe and notify all users or it's user          
          console.log(name, 'exit:script', code)
        } catch (error) {
          port2.postMessage(error)
        }
      }
      function ready (source, data) {
        if (source !== iframe.contentWindow) return console.log('@TODO: wat pxeboot?')
        console.log('[kernel]:iframe>', data)
        source.postMessage(pid, origin, [port2])
      }
    }
    ////////////////////////////////////////////////
  }
})()

SUMMARY

portal (web server)
- hosts index.html/shim.js/init.js/package.json/data/*
bootkernel (web runtime) [dpmOS]
- install kernel service + vault connection for pkg.json + send init scripts to renderer
- load kernel module extension shared workers
renderer session
- connect to kernel service to receive init scripts and execute them
sandbox
- …
data vault
- …
dpm (data package manager)
- …
shell UX
- …
viewport (UX)
- …
deamon
- …
Data registry and p2p hosting (datdot)
- …
Prototyping Environment
- …
Apps/Tools
- …
About Page
- …

sandboxed runtime

Data Vault

One of the main goals of this work is to help users regain control over their data and thus over their privacy. The first step is to standardize how apps are separated from user data to then enable users to put their data into a data vault, which they can self-host. The system is specifically designed to not rely on cloud infrastructure. All data is stored with and hosted by the user. This makes the vault GDPR compliant by design, so there is no data storage for processing by third parties eliminating the need for Privacy Officers and Data Protection Officers. This stops data-hungry companies from running machine learning algorithms over user data and learning users’ behavioral patterns. This has the added benefit of disrupting Big Tech from monetizing user data.

[1] loaded from a vault portal
[1] initializes bootkernel in the same way as a plain portal environment
[1] receive vault.js and run it
- if user wants to change vault portal, that's one thing => trust in portal developer (e.g. use home portal)
- if user wants to change vault script, that's another thing (e.g. change user interface and features of vault)
  - keep baseline to reset vault script
  - but keep standards based data and basic kernel protocols used by any vault script
  - hence run vault script in sandbox and log all it's interaction with data
  - vault script always has all permissions and forwards to vault users

==> NEEDS SANDBOX FIRST !
==> then probably needs PACKAGE MANAGER first (used by kernel by default to install package.json)
==> maybe that's enough to assume shit is there and we can think about package manager later
==> i guess package manager api and vault is the same or at least related (npm vs. npmjs.org) or (git vs. github)
==> git can also push to remote git repos …interestingly (maybe hypershell is the answer!)

LESEZEICHEN: do not receive vault (re)connection hook but instead custom or default vault script

Data package manager (dpm)

shellUX

taskbar

give commands (shortcuts in jump lists)
access resources
view program status

[user]@[node]:[path]#[task]>

DATASHELL UX:

RUNLOG: everything is a log (not object, not file, but log!)
- sends user input to connected node(s) (e.g. app)
- receives and displays output from connected node(s)
COMMANDLINE:
- PROMPT: [user(=e.g. vault)]@[node(=e.g. tool)]:[path(=e.g. project/folder)]#task(=e.g. roadmapping/todo)> [ACTION/PARAMS]
- APIDOC: eval, …
  - ACTION: commands/program or api call (defines messages type)
  - PARAMS: all data entered after a space following the command

user@domain:path> asdf
user@domain:path> asdf1
user@domain:path> asdf2
serapath@shell:~#live>
~: vault user home
/: normal path local to app
.. and . only exist in commands, not in "path" segment of prompt
user@domain:~/path/to/dir> asdf
user@domain:path> asdf2
user@domain:path> asdf3







input.onkeypress = e => {
  if (e.key !== 'Enter') return
  const { value } = input
  const { user, node, path, task } = prompt
  const msg = make(user, node, path, task)
  shell(msg)
}







const task = { // task & task protocol
  pid: project.id,
  tid: taskid(),
  ins: [],
  out: [],
  log: [],
}

viewport (UX)

Deamon

enables you to connect to the dat network (hyperswarm) (gets you 'online' in the p2p sense)
provides storing on the device instead of browser cache
can run additional sandboxed services (other p2p network / blockchain nodes)
enables data sharing
- selected data from user vault is available to the other users when this user is online/connected to the dat network (using the deamon)
data is protected in transit with noise protocol
p2p/Hypercore
- Data is also protected in transit with noise protocol. Packets are encrypted with the recipient’s public key and signed for authenticity and integrity.
- In the future, users will be able to securely backup and share data in the peer to peer network.

Data registry and p2p hosting (datdot)

enables selected datasets to be always available
makes all the published data publicaly available (data can still be encrypted, but it can be always accessed unless it is unpublished from the registry)
uses public ledger to store data addresses and a network of peers volunteering to host data for other peers
verifies if data is really available
uses fairness ratio to avoid spam and malicious attacks
DatDot registry uses public ledger to store data addresses and a network of peers volunteering to host data for other peers
DatDot data registry / p2p hosting
- There are several threats to data availability. The first threat is the lack of redundancy. All the user’s data is on a mobile device that can temporarily or permanently be out of service for a number of reasons. If the data vault is not backed up on a more reliable medium, the user risks losing data if the device becomes permanently inaccessible.

Prototyping Environment

"Encourage to write programs that do one thing and do it well. Write programs to work together. Write programs to handle json, because that is a universal interface."