133 lines
3.4 KiB
Markdown
133 lines
3.4 KiB
Markdown
- 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
|