docs
This commit is contained in:
parent
397e456983
commit
9ae70cdd36
8 changed files with 65 additions and 5 deletions
5
docs/src/content/docs/high-level-design/cryptography.md
Normal file
5
docs/src/content/docs/high-level-design/cryptography.md
Normal file
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Cryptography
|
||||
---
|
||||
|
||||
lol
|
|
@ -7,4 +7,12 @@ Some are the database kind that updates immediately.
|
|||
Others are the search kind that updates asynchronously.
|
||||
|
||||
Custom app authors can specify how their attributes should be indexed.
|
||||
Then, whenever
|
||||
Then, whenever any node has that particular attribute touched, a hook is run.
|
||||
|
||||
## Implementation
|
||||
|
||||
In the initial version of panorama, the daemon is thought of as having exclusive
|
||||
control over the database. It should not be run as multiple copies of itself either.
|
||||
|
||||
This way, the daemon can separately control indexes if it wishes, allowing it to
|
||||
call custom functions for indexing.
|
13
docs/src/content/docs/high-level-design/onboarding.md
Normal file
13
docs/src/content/docs/high-level-design/onboarding.md
Normal file
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
title: Onboarding
|
||||
---
|
||||
|
||||
## Creating a new database
|
||||
|
||||
1. Download the software
|
||||
2. It should automatically boot into a new database
|
||||
- Automatically connect to the hosted panorama bridge service
|
||||
3. Give the user the option to log into an existing database, and then allow them to merge
|
||||
|
||||
## Adding another device
|
||||
|
|
@ -8,7 +8,7 @@ hero:
|
|||
file: ../../assets/houston.webp
|
||||
actions:
|
||||
- text: Read the docs
|
||||
link: /dream
|
||||
link: ./dream
|
||||
icon: right-arrow
|
||||
variant: primary
|
||||
---
|
25
docs/src/content/docs/technical-docs/custom_app_hooks.md
Normal file
25
docs/src/content/docs/technical-docs/custom_app_hooks.md
Normal file
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
title: Custom app API
|
||||
---
|
||||
|
||||
## Registration
|
||||
|
||||
The following types of things can be registered by the app:
|
||||
|
||||
- Named types
|
||||
- Hooks (described below)
|
||||
- Background services
|
||||
- Frontend
|
||||
|
||||
## Hooks
|
||||
|
||||
Custom apps are allowed to hook into the following events:
|
||||
|
||||
- `install`: When the app is first being installed.
|
||||
|
||||
- `insert`, `update`, `delete`: CRUD hooks for nodes with a type that the app manages
|
||||
|
||||
- `attr-new`, `attr-update`, `attr-remove`: CRUD hooks for attributes with types that the app manages
|
||||
|
||||
Each hook is handled by a function, which must return with a success. If this
|
||||
doesn't happen, the daemon will re-call the function with exponential backoff for a specific number of retries.
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Custom App Sandboxing
|
||||
title: Custom app sandboxing
|
||||
---
|
||||
|
||||
:::caution
|
||||
|
@ -21,3 +21,7 @@ Each part needs to be sandboxed individually.
|
|||
## Backend sandboxing
|
||||
|
||||
This will be done via a WASM runtime. The custom app's backend software will
|
||||
|
||||
## Frontend sandboxing
|
||||
|
||||
lmao not sure if this is possible with a web-based host at all, looking into flutter...
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Formal verification
|
||||
---
|
||||
|
||||
lol
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Protected Namespaces
|
||||
title: Protected namespaces
|
||||
---
|
||||
|
||||
There's some protected namespace of nodes that's used to keep track of the
|
||||
|
|
Loading…
Reference in a new issue