Idea: Exploration of possible cwtch identifiers #91
Labels
No Label
applications
BLOCKED
bug
design
duplicate
enhancement
fixed?
funding-needed
help wanted
infrastructure
invalid
payments
qubes
question
ready-for-implementation
refactor
spam
tapir-server
testing
tor
wontfix
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cwtch.im/cwtch#91
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hey there folks,
I had a look at ricochet last year, and read the whitepaper for cwtch a couple of weeks back.
One of the open problems was "Usability of Cwtch Identifiers".
I haven't used golang for a project before, so haven't been able work out how to build the codebase from source yet.
However, I did put together this document discussing some of the ways an identifier could be represented to users, along with a PoC in Python. I haven't seen any identifiers particular to cwtch yet, so I just compared Richochet, and what I think is onionv3 addresses. I assumed that both were encoded in base36.
Anyway, any feedback or suggestions would be appreciated. Especially since I haven't had the chance to use cwtch myself yet.
(Github) Mnemonic - Base64 strings as human readable phrases
Thanks,
Wheest
Hi!
Yeah this is one of those questions that eats at me - I actually played around with a similar word-list based approach a few years ago (https://github.com/ricochet-im/ricochet/issues/128#issuecomment-107001948)
There are a few formats we've been using for Cwtch:
Cwtch will almost-definitely use torv3 addresses which even with word list encoding become unwieldy and we are going to need a more friendly approach.
My leaning right now is to build a name-resolution cwtch bot that allows registration/lookup of names and package that with the software. This is a centralized approach, and one I don't like completely, but I think we could design it in such a way that trust/metadata is minimized as far as possible and make it optional - it certainly needs thinking through.
The other approach, as you noted, is a blockchain/namecoin type approach which I don't think works well for Cwtch given the metadata resistant goals.
Glad to see that the space has been explored before. The extension of applying the encoding in chunks, with different word lists chosen from each time to make a more meaningful sentence is really novel. Something I'll keep thinking about for a while. Standardised, it could be a great way of having memorable secrets (though I'm not a cognition expert, maybe people are better at remembering random looking strings than I realise).
In terms of name registration/lookup, two questions I can think of right now.
Setting the scene first of all, say that we have a user Alice with a onionv3 address at
4rkafskjfk...
, and they want a more memorable name for this service, say they choose the namecauldhame
. Alice sends this tuple of4rkafskjfk...
andcauldhame
to the name registration bot which propagates it through cwtch name servers (let's assume the address is transparent for now).If Bob is given the name
cauldhame
, to find Alice's true address, they need to put in a request with a name server, who should return4rkafskjfk...
.So, assuming this scenario is roughly what you're thinking:
This could be mitigated by having a name, and a "join code". So the name server has the name
cauldhame
, and the address encrypted using some scheme with a join code such as24hpii94fw81...
. So the server stores(name, E(join_code, address))
. The address is decrypted locally by Bob after fetching. This method does have the downside anyone who knows the join code can populate name servers with misleading addresses associated withcauldhame
. I guess that brings me on to my second question:Okay so some thoughts on this that I've been failing to actually say for like a month plus because I'm a disaster at doing anything:
I think it might work to have a cellphone-contacts type model? Like, where we have globally-unique addresses that are not all that human memorable/distinguishable, stored locally-to-the-person with info like Contact Name and stuff.
Adding new contacts like that could be done by relatively-carefully-reading the long unweildy identifier*, but only once.
Groups (and servers? Do we want to do that?) could be handled similarly, just labeled in the lists as Groups, not people.
Within a group conversation, to (a) allow people you haven't met to have readable names, and (b) allow all the fun name-hopping-for-specific-jokes-and-stuff we've come to expect (and equivalently (c) be conducive to people trying out different names/identities/that Personal stuff) could display the display-name they use for the group, and then (slightly less emphasized) the unique-to-the-current-viewer name -- that would either be the name in their contacts list, if they have them, or else their cwtch id, truncated until it's unique to the current group.
e.g.:
(As, like, a quick thoughtsketch. There are prolly better ways to display it.)
* This could probably be improved by using the word-ist method as a transport protocol. That makes it easier to read/hear out loud, type, and remember for the few seconds it takes to write it down. Additionally because this is a transport protocol negotiated between humans just for that one transmission, it has the advantage that we can allow for multiple wordlists, so that we can easily add other languages (possibly just copying the Diceware Word Lists and not start with non-English-as-second-class (although we may want to do different word lists to emphasize sound differences).
We could even have a similar way of doing visual transport/confirmation views, allowing for an easy way to pass them as QR-codes, unique pictures like SSH does, etc.
The cellphone-contacts model is what I imagine the default set of affairs might be. Additionally, as you suggest, there could be a specific message header that gives someone an in-group nickname of their choice.
What I see as the design problem here is how can you have a way sharing these long Torv3 addresses in a more user friendly way, without compromising security. I too have been thinking about it, with some half baked methods of storing a global list of usernames, with users sharing their username, and a random "join code" key, and servers storing a key/value pair with the username and an address encrypted with the join-code. But then there are all of the issues of how many bits one would need for a good join-code, and the biggie of authenticity. Plus there is the global state coordination headache.
I'm still trying to strengthen my understanding of crytpoprimites, so I can't say for sure if there's a place for a zk-proof here. Conceptually, the "Where's Waldo Book" behind a big bit of paper with a hole in it is all I can grasp conceptually rn. If anyone has any comments on this, it would be appreciated.
But I think that we should probably be clearer about what our user models are here. How would our users be sharing their cwtch addresses anyway? If it's over an existing digital channel, then we can just copypaste. If it's verbally, or some other method that requires manual typing, then we've got a problem. Perhaps QR codes are how most folk would use it? If people are using the long-form addresses, it's difficult to remember, and error prone to type.
Would it make sense to create say 3 model users to aid the design process? Who would we interview for that?
Closing in favour of cwtch.im/cwtch-ui#415 which is likely the main improvement to sharing cwtch identifiers.