[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2568: Magic Folder: usability issues with 'tahoe magic-folder join'

[Tahoe-LAFS]

#2568: Magic Folder: usability issues with 'tahoe magic-folder join'
-------------------------------------+-------------------------------------
     Reporter:  daira                |      Owner:  dawuud
         Type:  defect               |     Status:  new
     Priority:  normal               |  Milestone:  undecided
    Component:  code-frontend-       |    Version:  1.10.1
  magic-folder                       |   Keywords:  tahoe-magic-folder cli
   Resolution:                       |  usability reliability
Launchpad Bug:                       |
-------------------------------------+-------------------------------------
Changes (by daira):

 * owner:  daira => dawuud


Old description:

> While manually testing Magic Folder, I ran the commands for Alice to
> create+join a folder, and to invite Bob. Then I accidentally had Alice
> use Bob's invite code to join again. This didn't cause an error; it just
> overwrote Alice's `private/magic_folder_dircap` and
> `[magic_folder]local.directory` entry.
>
> This is an easy mistake to make and could cause data loss. Alice has lost
> her write cap to her DMD, and there is no way to get it back (only a read
> cap to that directory is linked from the collective directory). Also,
> Alice's magic folder db will be inconsistent with the DMD that she is now
> using.
>
> The above problem is easy to fix by making it an error for a client to
> join a magic folder when it has one already configured. (Perhaps a `tahoe
> magic-client leave` command could be added; this would disable magic
> folder and also delete the magic folder db.)
>
> A related but trickier problem is that if the invite code is used twice,
> then two clients will be writing to the same DMD. There's no way to
> enforce that an invite code is single-use, because `join` is a strictly
> local operation that has no side effects on the collective directory.
> This has some advantages --if you lose state but retain the invite code
> then you can re-join-- but is also a little error-prone.

New description:

 While manually testing Magic Folder, I ran the commands for Alice to
 create+join a folder, and to invite Bob. Then I accidentally had Alice use
 Bob's invite code to join again. This didn't cause an error; it just
 overwrote Alice's `private/magic_folder_dircap` and
 `[magic_folder]local.directory` entry.

 This is an easy mistake to make and could cause data loss. Alice has lost
 her write cap to her DMD, and there is no way to get it back (only a read
 cap to that directory is linked from the collective directory). Also,
 Alice's magic folder db will be inconsistent with the DMD that she is now
 using.

 The above problem is easy to fix by making it an error for a client to
 join a magic folder when it has one already configured. (Perhaps a `tahoe
 magic-folder leave` command could be added; this would disable magic
 folder and also delete the magic folder db.)

 A related but trickier problem is that if the invite code is used twice,
 then two clients will be writing to the same DMD. There's no way to
 enforce that an invite code is single-use, because `join` is a strictly
 local operation that has no side effects on the collective directory. This
 has some advantages --if you lose state but retain the invite code then
 you can re-join-- but is also a little error-prone.

--

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2568#comment:2>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage