move design.md into the docs folder
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
This commit is contained in:
parent
ec776ff1e3
commit
82d73fa987
GPG key ID:
BDA47A31A3C8EE6B
2 changed files with 129 additions and 139 deletions
133
design.md
133
design.md
|
|
@ -1,133 +0,0 @@
|
||||||
- CLI API
|
|
||||||
|
|
||||||
- `mznotes install` : Install a script into the database
|
|
||||||
- `mznotes show` : Show the information about a particular node, by ID
|
|
||||||
|
|
||||||
- Database of nodes + code
|
|
||||||
|
|
||||||
- Code
|
|
||||||
|
|
||||||
- Code is all interface-based. Interface implementations give specific ways
|
|
||||||
behaviors are implemented
|
|
||||||
|
|
||||||
- Standard interfaces:
|
|
||||||
|
|
||||||
- Indexed
|
|
||||||
|
|
||||||
- Node definition
|
|
||||||
|
|
||||||
```typescript
|
|
||||||
type Node = {
|
|
||||||
metadata: KVStore,
|
|
||||||
interfaces: Set<InterfaceURI>,
|
|
||||||
edges: Set<(EdgeType, Edge)>,
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
- Within the metadata kv store, keys are namespaced, according to the
|
|
||||||
application name. Application names must be registered ahead of time
|
|
||||||
|
|
||||||
- Nodes implement interfaces, the code of which is fetched from the internet
|
|
||||||
and validated
|
|
||||||
|
|
||||||
- Nodes are namespaced, although namespacing isn't the primary hierarchy
|
|
||||||
protocol.
|
|
||||||
|
|
||||||
- This is needed because the database itself has a privileged namespace
|
|
||||||
- The privileged namespace is for keeping track of database state, for
|
|
||||||
example which scripts are trusted
|
|
||||||
|
|
||||||
- Hooks:
|
|
||||||
|
|
||||||
- Hooks consist of a (pattern, type, callback). The pattern is a metadata
|
|
||||||
matcher, that determines if the node should be executed upon. The
|
|
||||||
callback is Javascript code executed in the app's execution context.
|
|
||||||
|
|
||||||
- Type determines what kind of callback to call.
|
|
||||||
- Ensures callbacks: these make sure that a node has
|
|
||||||
-
|
|
||||||
|
|
||||||
- Database service:
|
|
||||||
|
|
||||||
- IFTTT Events
|
|
||||||
|
|
||||||
- Local vs. distributed IFTTT events?
|
|
||||||
- Local means that ur particular device is repsonsible for running it
|
|
||||||
- Distributed means any device can consume the event???
|
|
||||||
- is this even a good idea? Maybe just have one dedicated worker
|
|
||||||
device. For example, may not want to run certain automation tasks
|
|
||||||
on phone, while others may only be able to be run on phone
|
|
||||||
|
|
||||||
- Cron tasks
|
|
||||||
|
|
||||||
- Sync protocol:
|
|
||||||
- After a modification, the modification gets written to a queue
|
|
||||||
- CRDT?
|
|
||||||
|
|
||||||
- Other privileged concepts:
|
|
||||||
|
|
||||||
- User: a pub/priv key pair
|
|
||||||
|
|
||||||
- Sample apps
|
|
||||||
|
|
||||||
- Todos app
|
|
||||||
|
|
||||||
- Metadata keys (these are somewhat based on Taskwarrior)
|
|
||||||
|
|
||||||
- `status`: Enum{Pending | Deleted | Completed | Waiting | Recurring}
|
|
||||||
- Task status
|
|
||||||
- `description`: String
|
|
||||||
- Description
|
|
||||||
- `start`: DateTime
|
|
||||||
- `due`: DateTime{.due >= .start}
|
|
||||||
- `depends`: NodeRef
|
|
||||||
|
|
||||||
- Interfaces:
|
|
||||||
|
|
||||||
-
|
|
||||||
|
|
||||||
- Content / blob storage
|
|
||||||
|
|
||||||
- Interfaces:
|
|
||||||
|
|
||||||
- `Content`
|
|
||||||
- `upload() -> Writer`
|
|
||||||
- `get(node_id : NodeId) -> Reader`
|
|
||||||
- `Writer`
|
|
||||||
- `next_chunk(Vec<u8>)`
|
|
||||||
- `Reader`
|
|
||||||
- `next_chunk() -> Vec<u8>`
|
|
||||||
|
|
||||||
- Personal journaling (like Logseq)
|
|
||||||
|
|
||||||
- Weight / fitness tracking
|
|
||||||
|
|
||||||
- Calendar app (store events)
|
|
||||||
|
|
||||||
- Git app (store code)
|
|
||||||
|
|
||||||
- File backup
|
|
||||||
|
|
||||||
- Chat / Mail?
|
|
||||||
|
|
||||||
- Photo viewer + indexing using ML models for face detection / keywords
|
|
||||||
|
|
||||||
- Not sure yet:
|
|
||||||
|
|
||||||
- Automatic sharing of database nodes? This seems like a bad idea for
|
|
||||||
multiple reasons. Maybe better to just have a specific app for
|
|
||||||
doing permission models
|
|
||||||
|
|
||||||
- Other concerns
|
|
||||||
|
|
||||||
- Local protection using libsecret?
|
|
||||||
|
|
||||||
- Migrations?
|
|
||||||
|
|
||||||
- If an application needs to migrate its data format, should we formalize
|
|
||||||
this?
|
|
||||||
- Data migrations that don't need to create / delete nodes, only metadata
|
|
||||||
|
|
||||||
- Have the frontend also shipped with the backend?
|
|
||||||
|
|
||||||
- Subset of React components to typecheck against
|
|
||||||
|
|
@ -1,10 +1,133 @@
|
||||||
# Notes
|
- CLI API
|
||||||
|
|
||||||
### Pattern types
|
- `mznotes install` : Install a script into the database
|
||||||
|
- `mznotes show` : Show the information about a particular node, by ID
|
||||||
|
|
||||||
- Ensures
|
- Database of nodes + code
|
||||||
- An "ensures" hook runs whenever a particular metadata key is created, or its
|
|
||||||
value changed.
|
- Code
|
||||||
|
|
||||||
|
- Code is all interface-based. Interface implementations give specific ways
|
||||||
|
behaviors are implemented
|
||||||
|
|
||||||
|
- Standard interfaces:
|
||||||
|
|
||||||
|
- Indexed
|
||||||
|
|
||||||
|
- Node definition
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
type Node = {
|
||||||
|
metadata: KVStore,
|
||||||
|
interfaces: Set<InterfaceURI>,
|
||||||
|
edges: Set<(EdgeType, Edge)>,
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
- Within the metadata kv store, keys are namespaced, according to the
|
||||||
|
application name. Application names must be registered ahead of time
|
||||||
|
|
||||||
|
- Nodes implement interfaces, the code of which is fetched from the internet
|
||||||
|
and validated
|
||||||
|
|
||||||
|
- Nodes are namespaced, although namespacing isn't the primary hierarchy
|
||||||
|
protocol.
|
||||||
|
|
||||||
|
- This is needed because the database itself has a privileged namespace
|
||||||
|
- The privileged namespace is for keeping track of database state, for
|
||||||
|
example which scripts are trusted
|
||||||
|
|
||||||
|
- Hooks:
|
||||||
|
|
||||||
|
- Hooks consist of a (pattern, type, callback). The pattern is a metadata
|
||||||
|
matcher, that determines if the node should be executed upon. The
|
||||||
|
callback is Javascript code executed in the app's execution context.
|
||||||
|
|
||||||
|
- Type determines what kind of callback to call.
|
||||||
|
- Ensures callbacks: these make sure that a node has
|
||||||
|
-
|
||||||
|
|
||||||
|
- Database service:
|
||||||
|
|
||||||
|
- IFTTT Events
|
||||||
|
|
||||||
|
- Local vs. distributed IFTTT events?
|
||||||
|
- Local means that ur particular device is repsonsible for running it
|
||||||
|
- Distributed means any device can consume the event???
|
||||||
|
- is this even a good idea? Maybe just have one dedicated worker
|
||||||
|
device. For example, may not want to run certain automation tasks
|
||||||
|
on phone, while others may only be able to be run on phone
|
||||||
|
|
||||||
|
- Cron tasks
|
||||||
|
|
||||||
|
- Sync protocol:
|
||||||
|
- After a modification, the modification gets written to a queue
|
||||||
|
- CRDT?
|
||||||
|
|
||||||
|
- Other privileged concepts:
|
||||||
|
|
||||||
|
- User: a pub/priv key pair
|
||||||
|
|
||||||
|
- Sample apps
|
||||||
|
|
||||||
|
- Todos app
|
||||||
|
|
||||||
|
- Metadata keys (these are somewhat based on Taskwarrior)
|
||||||
|
|
||||||
|
- `status`: Enum{Pending | Deleted | Completed | Waiting | Recurring}
|
||||||
|
- Task status
|
||||||
|
- `description`: String
|
||||||
|
- Description
|
||||||
|
- `start`: DateTime
|
||||||
|
- `due`: DateTime{.due >= .start}
|
||||||
|
- `depends`: NodeRef
|
||||||
|
|
||||||
|
- Interfaces:
|
||||||
|
|
||||||
- Examples:
|
|
||||||
-
|
-
|
||||||
|
|
||||||
|
- Content / blob storage
|
||||||
|
|
||||||
|
- Interfaces:
|
||||||
|
|
||||||
|
- `Content`
|
||||||
|
- `upload() -> Writer`
|
||||||
|
- `get(node_id : NodeId) -> Reader`
|
||||||
|
- `Writer`
|
||||||
|
- `next_chunk(Vec<u8>)`
|
||||||
|
- `Reader`
|
||||||
|
- `next_chunk() -> Vec<u8>`
|
||||||
|
|
||||||
|
- Personal journaling (like Logseq)
|
||||||
|
|
||||||
|
- Weight / fitness tracking
|
||||||
|
|
||||||
|
- Calendar app (store events)
|
||||||
|
|
||||||
|
- Git app (store code)
|
||||||
|
|
||||||
|
- File backup
|
||||||
|
|
||||||
|
- Chat / Mail?
|
||||||
|
|
||||||
|
- Photo viewer + indexing using ML models for face detection / keywords
|
||||||
|
|
||||||
|
- Not sure yet:
|
||||||
|
|
||||||
|
- Automatic sharing of database nodes? This seems like a bad idea for
|
||||||
|
multiple reasons. Maybe better to just have a specific app for
|
||||||
|
doing permission models
|
||||||
|
|
||||||
|
- Other concerns
|
||||||
|
|
||||||
|
- Local protection using libsecret?
|
||||||
|
|
||||||
|
- Migrations?
|
||||||
|
|
||||||
|
- If an application needs to migrate its data format, should we formalize
|
||||||
|
this?
|
||||||
|
- Data migrations that don't need to create / delete nodes, only metadata
|
||||||
|
|
||||||
|
- Have the frontend also shipped with the backend?
|
||||||
|
|
||||||
|
- Subset of React components to typecheck against
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue