[tor-dev] [GSoC] CONIKS implementation for Tor Messenger
Huy Vu Quoc
huyvq.c633 at gmail.com
Sun Mar 13 07:40:44 UTC 2016
Thanks for your quickly reply.
> It's reasonable to assume that the client may one day talk to other CONIKS servers and
> clients. So clearly specifying the data format that the Tor Messenger client (and also
> the server) uses is an important part of the project. Ultimately, the data format specification
> should follow the data formats given in the paper. So you should provide a clear specification
> for Tor Messenger but you shouldn't worry too much about making it compatible with other
> services. The main reason being that we don’t know of other communication services that
> have already implemented and deployed CONIKS.
> I'm not currently working on a standard specification. That's something that I think
> communication/identity providers should come together to do once there are a few tested
> deployments of CONIKS. This is what I've heard from other communication service providers
> I've talked to, and I think it makes sense.
> To get a rough sense of what a data format might look like, you may look at the CONIKS reference
> implementation (github.com/coniks-sys/ref-implementation). It uses Protobufs
> to specify the data exchange format, so you could use a similar format.
Thanks for your suggestion. I will have a look at this carefully.
> As part of your application, we’d like for you to provide us with your planned timeline
> according to the functionality we’d like to have. Here’s the functionality that would
> be great to have by the end of the summer: key registrations, lookups and monitoring.
> The nice thing about splitting up the functionality like this is that it allows for the
> key server and the client to be built incrementally. So given how you want to tackle these
> tasks, you should set up your plan accordingly.
I get it. It would help me a lot when writing my proposal.
Vu Quoc Huy
More information about the tor-dev