Well, that wasn’t my plan at all 
The problem I see is that any improvement which minimizes the information exchange to make it easier to do an out-of-band authentication means we’ll have to do proper authentication on an insecure channel. This is a difficult problem in a field with very little trusted and high quality libraries and the number one rule beeing “don’t roll your own”. So we should probably wait for others to solve it while working on other ways to make the setup as easy as possible.
This is the best paper I’ve found during a quick search: “Authentication protocols based on low-bandwidth unspoofable channels: a comparative survey”
This presents several interesting protocols, I suggest reading at least the conclusions on page 37ff. There are even nice tables comparing the number of bits which have to be transferred over the human channel.
But unless one of the core devs is willing to implement one of those and to deal with the fallout if the impementation was weaker than the proposal, we’ll probably have to wait until someone capable needs it more than we do and open-sources it.
So while this is the best solution, because it actually solves the underlying problem, we can at least alleviate the pain caused by the current implementation with little effort. @calmh @AudriusButkevicius @Nutomic: if you want me to open tickets for any of those, just tell me.
-
Nowadays we can ask the browser to hand over control of the webcam to scan the other devices QR code. By now every laptop has a webcam and the desktop market is basically dead, so the amount of users who can profit from this is huge. There is also a FOSS JS lib ready to do all of that: QCodeDecoder. The only GO lib I found is this wrapper, and it’s not really feature rich: GitHub - shezadkhan137/go-qrcode: A light golang wrapper around zbar, used for qr code processing
-
Create a wizard where noobs are led trough the necessary steps to choose/add a device + folder in the right order. It’s automatically shown on first run and then available from the “actions” dropdown. User education is very important. Basically all of the most popular apps with a hunch of UI complexity do this. And for a reason.
-
We can think about linking the “add device” dialog from the “Shared With” and “Share With Devices” sections in the folder overview and the folder settings respectively. The source folder would be checkmarked automatically in the opened “add device” dialog. This deals with the case where a user either accidentally created the folder first, or wants to add a new device, but needs to add it to only one folder. This is making it easier for beginners, because more of the avenues they explore for getting done what they want to achieve actually work.
-
A simple “mail:” link in the “show ID” dialog to enable desktop users to email the device ID. This isn’t very secure by default, but neither are phone calls. And security concious users can use GPG/PGP.
-
The Android app still has room for improvements from a UI perspective:
-
there should be a “share with” icon next to the device ID (your own and others), which opens the “share with” intent. There the user can choose their preferred means of communication.
-
the “click to copy” functionality might be hinted at, because it deviates from the Android default (selectable text can be copied by long click). As the default action (long click) also works, only the case where people don’t even try to click the ID is problematic tough.
-
(Encoding the current IDs diceware-style is pretty straight-forward and gets us down to 20 words people have to communicate. Not great, but better than 56 chars and with less room for errors. One caveat: ideally the users language preference would determine the diceware list used, because unknown words can’t be pronounced. This necessitates a big red warning & dropdown with language choices next to each ID tough. :-/ Not sure if it’s worth it usability wise.)