#19 64char codes vs. memorable names

[Anonymous]

Originally created by: arminus

Problem

As a continuation of https://github.com/denislupookov/altersend/issues/1, 64char codes are not user friendly unless transferred implicitly by a QR code or some other means (which then ads UX complexity). This problem specifically exists with non-mobile receivers and/or without access to a webcam (like in a linux terminal).

Proposed solution

Adopt a solution like magic wormhole etc. which uses a triple of random dictionary words which can be easily typed if other transfer means are not available.

Alternatives considered

https://github.com/denislupookov/altersend/issues/1

Additional context

[Anonymous]

Originally posted by: denislupookov

Thanks for opening this @arminus, I agree this would be a solid improvement.

I don't have the capacity to design it properly right now (the word-code path needs an Argon2 stretch into the 32-byte topic, and getting the entropy/word-count trade-off right deserves a proper look), so I'm going to come back to it later rather than rush it.

Holding it for now, will revisit. Appreciate the thoughts here 🙏

[Anonymous]

Originally posted by: arminus

@rahulmathews you also expressed some interest?

[Anonymous]

Originally posted by: rahulmathews

@arminus Yes, But as denis mentioned we need to be store them in a database or some temporary cache storage and there is a risk of the collision between the common magic words and this risks one user getting files that is sent to some other user. If we decide to go forward with this plan, I have some key points to unblock the above:

• For the magic words storage we can use some kind of elastic cache with a fixed ttl so that they will be discarded after a certain time or after the transfer is done.
• To check the collision between the common phrases between multiple users, we need to follow the same steps that major social media companies follow to check whether the username is taken or not.

[Anonymous]

Originally posted by: arminus

Conceptually, this sounds good to me, but where would you put the cache without some server in the loop - which would kind of violate your architecture?