Inviting new participants should use wormhole

[meejah]

When inviting a new participant to a folder we should use magic-wormhole to do so. This avoids putting secret information into the invite-code. The existing invite-code is pretty bad: if even a passive observer sees it, they can forever impersonate the invited user (and view all magic-folder updates) if they (also) have access to the Tahoe grid being used.

magic-folder invite should print out a magic-wormhole code and magic-folder join should consume one. The details of the communication protocol should be specified first (ideally in a .rst document) but should communication the following information:

• collective DMD capability
• personal DMD capability
• author public-key

Note that the current system lets the administrator of the magic-folder retain information they should never have; the magic-wormhole based system can take advantage of two-way communication. Here is a suggested flow:

• wormhole succeeds
• admin sends read-capability for the collective DMD
• invitee sends: preferred name, read-capability for their personal DMD and their public-key
• admin sends "okay" or "error" (e.g. if conflicting name?)
• wormhole closes

Obviously this needs more details fleshed out, but the core improvements are that the invitee is the only one who ever sees the write-capability for their personal DMD and the private portion of their author key.

[meejah]

There has also been some discussion of whether the default for the CLI should be "wait for the invitee" or to not wait (seehttps://github.com//pull/217#discussion_r469298597).

Either way, it seems that the actual HTTP API that "does" the invite will need to be two-part: "start the invite" (and receive some token in response) and "check status of invite (token)" or "wait for invite to complete (token)". Perhaps it also makes sense to be able to list all pending invites?

[meejah]

Implemented