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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
