Multiple Users Support

[ben-kaufman]

As we briefly started discussing in #131 , I was thinking about adding Specter support for multiple users/ accounts sharing the same Specter server. I think the main use cases would be:

1. Sharing your node and Specter setup with less technical family and friends.
2. Having a demo server on the cloud where people can play with it before actually installing it.

As @stepansnigirev mentioned, there is the tradeoff here of leaking some privacy to the node operator. Personally, I'm not too worried about that because:

1. I think if you can't trust the node operator with your privacy you should probably not trust him with running a "real" full node without cheating you.
2. The current alternative for today for those who don't run their full node is usually trusting a 3rd party company server. So I think having small trusted "local" operators is still much better than everyone trusting a large centralized 3rd party.

Any thoughts on this (in general/ implementation-wise)?

[stepansnigirev]

I think it's a very nice idea.

The question is how to implement it... The first thing I am thinking of is to have a user_id key in wallet.json and device.json files. So when the user is logging in he can access only the devices and wallets he created.

But there should be also a privileged class of users, that can remove or add other users. Like an admin flag. When this admin deletes the user, all devices and wallet of the user should be deleted as well.

We already have an authentication selection in settings, at the moment there is only "use rpcpassword" option. I think it makes sense to add another one - username & password. If this option is selected, first user is assigned as admin, and there should be a new menu item somewhere to manage access.

[ben-kaufman]

I was thinking of having instead of just single wallets and devices folders to have a users.json on the root level and then for each user have a separate folder with its wallets and devices. But I guess that's a relatively minor difference from what you described.
I think that with such users.json file we could do all the admins and users management.
We'll definitely need to add user+password authentication for that feature.

Removing user should be quite trivial to implement, but adding users could be done in multiple ways and I'm not sure which is better. One option is to have the admin register new users, and then send them username and password (which they can edit for themselves later?). Another option could be to allow the admin to send some registration link/ OTP for the new user which will set the account himself.
Another, probably only relevant to the demo servers could be competitive open registration by users without admin intervention, though that might be too open. I think the second option is the best but not sure.

[stepansnigirev]

to have a users.json on the root level and then for each user have a separate folder with its wallets and devices

Nice. Then recursive delete of the user folder is all we need. In Bitcoin Core we can also separate wallets into folders named after users, similar to what we are doing with specter instances (specter + random id). We can either use usernames for folders, or maybe incremental user ids. In case of user ids they can also change the usernames if they want to (not sure if it is needed though). The only problem will be switching from multi-user back to no-auth or rpcpassword-auth method - should we allow it only if there is a single user? Like to say "delete all users if you want to switch back to non-authenticated access"?

Another option could be to allow the admin to send some registration link/ OTP for the new user which will set the account himself.

I think it's the right approach. Then for the automatic registration in the cloud demo we can make a simple script that will be sending these links to provided email addresses, or just displaying them on the webpage.

[stepansnigirev]

Implemented in #172,
I think after we have some kind of user management screen to delete users we can close this.

[ben-kaufman]

Closed with #172 #194 #261