Key revocation and management feasibility?

Nobody has claimed this yet.

I’ve been researching hyperdb/core/drive for a project and the last thing I’m stuck at is the key management. Currently hyperdb doesn’t support any sort of management but is this because nobody (aka @mafintosh or @noffle ;) ) hasn’t had time or need to put it in place or is it because there’s some inherent problem with append-only logs and keys that I just don’t see right now?

The two things I’m looking for are limiting the ability to authorize and ability to revoke right to read/write. Without these two it’s quite hard to build anything on top of hyperdb that’s not either fully public or fully trusted.

I understand hyperdb’s architecture at a high-level only right now so I’m hoping that somebody with more knowledge finds few mins shed some light on this :)

The issue identifies hyperdb/core/drive as the relevant area, but names no implementation files or tests. Start by reading that component and the project’s append-only log and key architecture, then determine whether authorization and read/write revocation are feasible. Done would require a documented feasibility conclusion or an agreed design for key management.

Written by the indexing model from the issue text.