HTTP requests instead of (or in addition to) TCP sockets

[jpeisenbarth]

Hi,

I work at INRIA Nancy Grand Est (France) and our team is interested in the work you are leading on CONIKS.

We plan to use CONIKS in a context of an web application of collaborative editing in a peer-to-peer network. In this context, the communication with the CONIKS server would be simplified if it listened to HTTP requests (HTTPS in fact, we could still use TLS).

Currently the client and the server listen and use TCP sockets (or Unix
sockets) and I am opening this issue to discuss about the changing of the TCP sockets to HTTP requests (or maybe having both solutions).

What are you opinions about this ? (If you are ok I can develop this feature and suggest a PR :)

Thank you in advance !

[masomel]

@jpeisenbarth Thank you for your question! Could you please elaborate on this:

the communication with the CONIKS server would be simplified if it listened to HTTP requests

Can you also give us some details on how you would implement this feature?

[jpeisenbarth]

@masomel At the beginning it could be really simple and just replace the TCP sockets with HTTP.

Concretely :
Server side -> http.ListenAndServeTLS and http.HandleFunc instead of net.ListenTCP
Client side -> http.NewRequest and http.Client.Do instead of tls.Clientand tls.Conn.Write

I have a working prototype but is it a little dirty because with TCP you handle manually the sockets (listening, accepting and handling) but with HTTPS server it is automatic, only the handler function is needed. For this reason I bypass some code and it is not clean.

Secondly for a more elaborated HTTPS handling we could think about a REST API but this needs a lot of additional discussions

[masomel]

I think your suggested changes make a lot of sense, communicating over HTTPS would definitely simplify the interface. We've briefly discussed using a REST API on our end as a viable alternative to our current communication interface, and as you said, implementing this would certainly require more discussion.

We'll make sure to discuss this more during our next developer meeting. On our end, we are currently prioritizing finishing missing core features. It seems like you've dedicated more time to this change, so we are more than happy to support you and discuss all the necessary design changes with you if you would like to lead the effort to implement communication over HTTPS.

For now, when you think that your current prototype is ready for review, we'd be happy to review it and consider merging those changes! As a second step, we can work on developing a REST API later.

[vqhuy]

I think we need to do some refactor for the connection layer code. Related to #77.
It would be great if we can start the server with a switch run-over-tls-socket or run-over-https or something similar.

[liamsi]

I have a working prototype but is it a little dirty because with TCP you handle manually the sockets (listening, accepting and handling) but with HTTPS server it is automatic, only the handler function is needed. For this reason I bypass some code and it is not clean.

@jpeisenbarth: I saw one of your team-members closed the corresponding issue? Did you stop working on this?

[jpeisenbarth]

Hello @liamsi, it was a mistake, I just reopened it. I did not work on it since the opening of this issue, still have some sort of prototype but not proper code. Soon I will take some time to clean this and propose a pull request. Sorry for the waiting ...

[liamsi]

Thanks for your reply. And no problem. I was just curious.