Access-controlled workspaces (invite-only)

[cinnamon-bun]

How it works

Right now anyone can write to a workspace if they know its address.

Let's add a second kind of workspace which has a pubkey in its address. Every item posted in this kind of workspace must be signed by the workspace private key AND the author private key. This will be enforced by the feed format validator class.

So to write you need to know the workspace private key. You can give the workspace secret to someone to invite them.

This doesn't encrypt messages (yet) so it doesn't limit who can read, only who can write. Once we have encryption, authors can encrypt their messages to the workspace pubkey.

Key inclusion in workspace addresses

Currently workspace addresses have this format:

"+" NAME "." B32

+gardening.bzwo4h3   // hard to guess randomness, any length
+gardening.baweoijca48jao93jl39cajl94j3  // public key, 53 characters

B32 is a base32-encoded buffer that holds randomness that's hard to guess, or a public key.

There isn't yet a good way to tell if the B32 is a key or not. For now we can check if it's 53 characters long (a key) or shorter (random).

It'd be nice to also have an "invite format" that includes the private key.

Tasks

• [ ] Find better way to distinguish public key from randomness
• [ ] Add workspaceSignature field to validator class, and check for valid workspace signature there
• [ ] The Keychain type now needs to include the workspace secret as well as the author secret, hmm.

[sgwilym]

I'm going to implement this. As mentioned above, one of the problems to solve is distinguishing when a share address contains a public key and when it doesn't.

Some options:

1. As mentioned above, we could just use the rough heuristic of 'begins with a b and is 53 characters long'. If these criteria are satisfied, then a share's private key is required to write valid documents.

2. We could also make invite-only shares use a different address format, e.g. - or ++ instead of +. This has the benefit of making it easy for a user to eyeball if a share is an invite-only share as well.

3. One last option is to make all shares have a public key, and dropping the possibility of writing to a share with only the share address altogether. This makes Earthstar a little more secure by default, but I wonder if this introduces unnecessary complexity for many use-cases.

[johanbove]

How much time do we have to contemplate on these options? At first thought I would go for option 2 and use "-" to indicate the read-only mode.

[sgwilym]

@johanbove I have a branch which implements option 3 but I'm not totally happy with it.

One reason is that signing / verification of docs takes twice as long as there are now two signatures. This effectively doubles the time taken to perform common operations like ingesting docs from another peer.