Will
having dealt with this for a bit now, i've decided i care more, and that the optional libraries need to be opt-in parts of the build. editors / standard ecosystem...
it would be nice if the latency between a publisher writing a message and a client retrieving it is sufficiently long for the message to fall out of the database...
Probably worth revisiting the JSON file serialization used for `talek.conf` and `talek.handle`. In particular, the "public key as array of bytes" is probably better represented hex-encoded. Ideally a handle would...
Currently, the api in `libpdb/client.go` doesn't really make sense: * publishtrace and poll trace are debug methods and should be in a test class * subscribe doesn't provide any interface...
There isn't currently an exposed interface differentiating the `owner` of a topic who has the needed keys to publish to that topic, and subscribers who can read new values but...
We should provision 2-3 servers to run an initial demonstration instance of Talek for public interaction / testing. I think 3 would be great, since 2 remains a bit of...
Presumably it needs to keep track of where it is in a topic handle, but how does that bootstrap initially? in practice, the shared secret with the topic password should...
currently `server/centralized.go` expects act as either a leader with a single follower, or as a follower. We should at least generalize to support `n` followers for single leader.
if the client fully controls interest vector, they can trigger popular vectors to trigger other client reads. perhaps zero knowledge proofs can be used to force compliance of the interest...