...
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`
|
- `foo.bar` includes `foo.bar/qux`
|
||||||
|
|
||||||
etc
|
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