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
|
||||
- An "ensures" hook runs whenever a particular metadata key is created, or its
|
||||
value changed.
|
||||
- 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:
|
||||
|
||||
- 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