From 4c4b065869f3b437d10a6250dcc044ccf3386c5c Mon Sep 17 00:00:00 2001 From: tezlm Date: Tue, 22 Aug 2023 01:15:40 -0700 Subject: [PATCH] ... --- docs/notes.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/docs/notes.md b/docs/notes.md index 84721cb..3794db8 100644 --- a/docs/notes.md +++ b/docs/notes.md @@ -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.