Hi Marcela,
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.
best, Vu Quoc Huy