...
This commit is contained in:
parent
e7b305ecc2
commit
4c4b065869
1 changed files with 26 additions and 0 deletions
|
@ -104,3 +104,29 @@ having mutex tagging (`things/foo` or `things/bar` but not both) would be nice.
|
|||
- `foo.bar` includes `foo.bar/qux`
|
||||
|
||||
etc
|
||||
|
||||
## encryption
|
||||
|
||||
Encryption is not implemented here. I am not a cryptographer and
|
||||
will probably do something silly. Instead, layer encryption on top of
|
||||
events. While the downside to a "layered" approach is that metadata is
|
||||
leaked, that same metadata is required for the server to index/aggregate
|
||||
events and allow querying.
|
||||
|
||||
## key groups
|
||||
|
||||
I found [p2panda](https://p2panda.org/), and I like a lot of the
|
||||
ideas. Some parts are similar, and I think designing everything around
|
||||
append-only logs does simplify some things (though I think modelling the
|
||||
world as a graph database is a lot simpler and makes other things easier),
|
||||
but I digress.
|
||||
|
||||
One thing I completely overlooked is managing ActorIds/key groups. A
|
||||
user needs a single keypair on every device they want to use, which is
|
||||
horrible from a security and usability standpoint. P2Panda solves this
|
||||
with key groups.
|
||||
|
||||
Key groups let keys be added/removed to a group (wow), which also acts
|
||||
as authorization, which controls who can send what events (kind of like
|
||||
`x.acl`). I'd probably copy this and gut it for key storage, but I might
|
||||
even go farther and implement ideas into x.acl.
|
||||
|
|
Loading…
Reference in a new issue