search

coniks-sys / coniks-go

A CONIKS implementation in Golang
http://coniks.org
Other
116 stars 30 forks source link

Managing identities from a variety of services/protocols in a single server #30

Open vqhuy opened 8 years ago

vqhuy commented 8 years ago

Tor Messenger doesn't handout any identities, and it supports various protocols. In such a case, do we need to provide a way to manage identities of each protocol for the developer?

In the current implementation of CONIKS for Tor Messenger, the CONIKS server stores all the identities of all protocols in the same tree, the key of each user leaf node is formatted as username + '@' + protocol. We probably want a better way.

Or the developers could have multi CONIKS server instances, each of them corresponding to a specific protocol.

\ Maybe the title of the issue is incorrect, so I'm glad if someone helps me replace it with a proper title.

masomel commented 8 years ago

Maybe the title of the issue is incorrect, so I'm glad if someone helps me replace it with a proper title.

I didn't think the title was incorrect, but I tried to make it a bit more specific. I hope it makes sense!

Tor Messenger doesn't handout any identities, and it supports various protocols. In such a case, do we need to provide a way to manage identities of each protocol for the developer?

This is a good question. I think that this is more of an issue of managing the identities of various services, and not various protocols. CONIKS should be protocol-agnostic, so I think managing all the identities for all the different services and protocols in a single directory should be fine. If the developers wanted to run multiple server instances for each protocol or service they support, they could, and this should work without any changes to our current design.

In the current implementation of CONIKS for Tor Messenger, the CONIKS server stores all the identities of all protocols in the same tree, the key of each user leaf node is formatted as username + '@' + protocol. We probably want a better way.

This does seem a bit hacky, but I think it's fine for now. Once we start adding support for other services such as XMPP servers, we might want to change this naming scheme. But as I said above, I don't have a problem with managing all identities in a single tree.

The only way I can see this becoming an issue is if one of those services (e.g. Twitter) decided to start running their own CONIKS server. Would Tor Messenger have to transfer all Twitter names it currently knows to Twitter? How would this transition look like? How can we ensure that the transition is safe, i.e. nothing about the protection of the names in Tor Messenger's directory should change when they are transferred over. This might be a separate problem than the one you're addressing here, but I think it's related, so if we think this is a real concern, I think it's worth looking into better ways for managing all these various identities.

vqhuy commented 8 years ago

I didn't think the title was incorrect, but I tried to make it a bit more specific. I hope it makes sense!

Great. Thanks!

The only way I can see this becoming an issue is if one of those services (e.g. Twitter) decided to start running their own CONIKS server. Would Tor Messenger have to transfer all Twitter names it currently knows to Twitter? How would this transition look like? How can we ensure that the transition is safe, i.e. nothing about the protection of the names in Tor Messenger's directory should change when they are transferred over. This might be a separate problem than the one you're addressing here, but I think it's related, so if we think this is a real concern, I think it's worth looking into better ways for managing all these various identities.

Really interesting! I will keep this issue open for future discussions.

liamsi commented 8 years ago

This is a bit off topic but maybe it could be interesting to see if we can bind multiple names to one main-name / identity / key? Maybe this could be doable using #17 and encoding the other names + keys into the multiple data entries. Not sure if we ever wanted this and because people who want several pseudonyms who aren't connected with each other, this would need to be optional (which shouldn't be a problem). I think this approach could be interesting if we ever wanted to run some global identity service not bound to one service (like twitter etc). This could be something more like @keybase is doing (https://keybase.io). Didn't think it through, though... Just writing down some thoughts.