Hi everyone,
This is my second status report on the CONIKS for Tor Messenger project.
During the last two weeks I’ve been working on several things:
1. Continue implementing the Merkle prefix tree module and fix issues based on comments from Marcela, Arlo and Ismail. These are still some works need to be done including: - Using an abstract cryptography library [1] instead of specific primitives - Add hooks for storage backend [2]. Currently, I’m discussing with my mentors (Marcela and Arlo) about how to do it.
2. Spend time to studying current implementation of coname/dename [3, 4]. It would help me so much when I go to implement the CONIKS library (e.g., the server struct, server config and http front)
3. Work on some other modules of libconiks library (HTTP server and server config)
4. Implement the Twitter bot for registration protocol. I used a 3rd client library for Twitter APIs [5]. This bot uses the Twitter streaming APIs to listen for new coming registration message, as described in the account verification protocol.
The source code of (3) and (4) is not pushed to the github repo yet since I’m still doing on these modules and they are not ready for integrating into the library.
My focus on two next weeks is mainly to implement the registration protocol and continue refining the Merkle tree library.
Best, Huy
— [1] github.com/dedis/crypto/ [2] https://github.com/coniks-sys/libmerkleprefixtree-go/issues/4 [3] https://github.com/yahoo/coname [4] https://github.com/andres-erbsen/dename [5] https://github.com/dghubble/go-twitter
The source code of (3) and (4) is not pushed to the github repo yet since I’m still doing on these modules and they are not ready for integrating into the library.
As much as possible, I would encourage to work in the open, and publish early and often. Even though the code may not be ready for review, it's helpful to see progress from our end.
Thanks.
Hi Huy,
Thanks for your 2nd status report!
|> The source code of (3) and (4) is not pushed to the github repo yet |> since I’m still doing on these modules and they are not ready for |> integrating into the library. | | As much as possible, I would encourage to work in the open, and publish | early and often. Even though the code may not be ready for review, it's | helpful to see progress from our end.
Another related issue that arises if you wait to push all of your new code at once is that your PRs become very large and more complex to review. So in addition to publishing your code early and often, I would also encourage you to divide your tasks into smaller units that can be easily debugged, tested and reviewed. Creating separate specific issues on Github for each small task might be a good way of keeping track of what work is in progress, what you still need to do, and what you've finished.
Best, Marcela
On June 18, 2016 at 01:08:34, Marcela S. Melara (melara@cs.princeton.edu) wrote:
Another related issue that arises if you wait to push all of your new code at once is that your PRs become very large and more complex to review. So in addition to publishing your code early and often, I would also encourage you to divide your tasks into smaller units that can be easily debugged, tested and reviewed. Creating separate specific issues on Github for each small task might be a good way of keeping track of what work is in progress, what you still need to do, and what you've finished.
On June 18, 2016 at 00:46:01, Arlo Breault (arlo@torproject.org) wrote:
As much as possible, I would encourage to work in the open, and publish early and often. Even though the code may not be ready for review, it's helpful to see progress from our end.
Yes. I will do it.
Best, Huy
-
Arlo Breault -
Huy Vu Quoc -
Marcela S. Melara