Korkman

I don't know how the protocol deals with SyncIDs / device names at handshake time. Depending on when and how SyncIDs are exchanged in advance, it may be easier to generate something new like an AuthID and use that for the process. But that's left for the devs to decide Upgrade transition to an "authorized" share is probably a bit difficult here. The user should be informed that devices A B C have compatible btsync versions installed and device D will disconnect when the share is upgraded until client on D is updated. There's really lots of UI stuff associated with this process but I think i

Basically the same that happens when a file is edited in two places: "User action wins", so the later decision will overwrite the earlier. As soon as the client recognizes a change to the list of valid devices, the event could close any "Yes" / "No" dialogs and in addition show a notification "device X has given / denied permission to device Y to join share Z at Timestamp". From a data perspective, all I see is a hidden file .shareDevices with lines like Device:ActionDevice:AllowOrDeny:Timestamp For example HomePC:MobilePhone:Allow:Timestamp Stranger:HomePC:Deny:Timestamp which i

The current process of adding devices to a share is kept simple and fast. Copy the key, paste, the device has access to the share. The major drawback here is that the key, should it fall into wrong hands, immediately allows an attacker full access to the share. For example when the mobile phone QR code is presented on screen, a camera across the room could easily catch that. I propose a list of known devices shared within the folder. When a new device appears, a dialogue would appear on all currently active devices asking for permission to add the new device. A "yes" would add the device to