jellevandenhooff / keytree Goto Github PK

All parts of the protocol should be documented. Update and lookup rules are the most critical.

The server currently will accept as many updates as its CPU can handle. To prevent abuse, rate-limit updates per-IP, per-domain, per-username.

Additionally, we should rate-limit (and size-limit) updates coming in from mirroring other servers. A malicious server could trick a follower into downloading a very large tree and fill up its memory. However, because servers pick what trees to mirror manually, this is a less pressing issue.

Barebones lookup verification code exists in web/client.js.

Ideally, we expose a simple API for lookup up a specific kind of key from a user, and if the lookup fails, you get a human-friendly error message.

Later on, we could also expose a simple API for updating for users that do not have a Keytree lock key configured. Then apps could use Keytree without requiring users to install a new app. For users that do have a lock key configured, the update API can forward users to the full-blown key management client.

The commandline client should support lookups as well as updates. It should read and store a configuration somewhere. It should help you out if servers disagree on the current status of your record.

Starting your own server should be a very-low friction operation. Ideally, you download the code, compile it, and start it, and you're done. Step 2 is configuring your client to use the local server (should be a one step action as well), and publishing your server to other servers. Perhaps keytree.io can mirror servers automatically?

The server website should display basic statistics (number of entries stored, memory used, number of servers mirrored, size of each mirror).

The JavaScript client will handle untrusted JSON input. To make reasoning about the code easier, we should type-check the returned JSON in a centralized place.

For security, each user should be able to configure their own quorum. For convenience, you should not have to configure your own quorum.

Ideally, Keytree ships with a standard configuration built into the code, but will read from (something like) ~/.keytree/config to support user-supplied quorum configurations.

Apps using the Keytree library should be able to override the standard configuration (or extend it) with their own server to not depend on anyone else.

We also need a format for configurations. Ideally, we allow arbitrary nesting of quorums.

Right now, the mirroring API requires parallel requests for reasonable performance. This keeps the API simple, but does not scale well (one TCP connection per outstanding request). Either HTTP2 or some kind of TCP multiplexing would be the easiest way to solve this problem.

Should investigate if multiplexing gives acceptable performance, or if we need batching of multiple requests in a single HTTP request as well.

The code needs to be audited and tested.