Schema overhaul

[cryptix]

This is needed for #90 but because there is so much renaming, I made a separate PR.

• create consolidated schema with new members table
• remove allow_list and replace it with members
• update roomdb types
• rename User to Member
• add role enums (member, moderator, admin)
• update insert-user
• overhaul web/handlers/admin
• overhaul web/handlers
• overhaul roomsrv and tests
• copy previous allow-list stuff and use it as deny-list
• fix add-form layout on denied list (key|comment)
• fix add-form layout on members list (pub_key|nick)
• role change ui
• pick icon for denied keys menu entry (it's https://materialdesignicons.com block-helper)

[cryptix]

Just some thoughts as I'm jumping through these changes. Still stuff to do but thought I'd loop you in already.

Following from "allow lists is now members" comes the realization that members need to have a nickname. Assuming that no-one wants to deal with just public keys and they might not have an alias. So the current allow list form needs another input field (and styling for that... cc @staltz 😬) and a way to change the members role (not sure if we want to make this with a drop-down on the list or a separate edit page (which might be worthwhile if people want to change their nick or public key for instance).

[staltz]

Oh, yes it would make sense that the members page allows changing roles. A dropdown seems fine, to begin with. Just note that only admin should be able to change roles.

But nicknames? Why? Aliases are basically the nickname system.

[staltz]

Assuming that no-one wants to deal with just public keys and they might not have an alias.

Is this the reason? And in what context would they deal with public keys? Not sign-in, because that should be handled by SIWSSB (we don't want the fallback username/password system for all members. In fact we didn't even want it originally for anyone)

[cryptix]

Is this the reason? And in what context would they deal with public keys?

if the members don't have a nickname, you just see the public key on who created the invite or who do these aliases belong to.

Aliases are basically the nickname system.

Not all users might have an alias. I might not want all my devices identified with an alias, especially since it's enumerable from the public, unless I switch the room into restricted mode, which might not be what the other room members want.

edit: this members nickname is also different from the fallback password (where the "username" is called login). This is another place where entries are linked to the members and where changing or no aliases can be confusing.

[cryptix]

By the way: I don't think we need to spec this. It just makes sense for an implementation, I think. Simply starting from the case "what happens when you remove your only active alias" or "what do you show when there are two aliases?".

[staltz]

By the way: I don't think we need to spec this. It just makes sense for an implementation, I think.

That's good clarification. Thanks

if the members don't have a nickname, you just see the public key on who created the invite or who do these aliases belong to.

I see this as a possibility, but not a need, strictly. Seeing the raw public key is not pressing problem, as I see it. There are also considerations to make, such as minimizing how much the admin knows about its members (see some Security Considerations in the spec), and it's also possible to create confusion by having both nickname and alias (people might register one thinking that they wanted the other, or vice-versa). Attaching identifiable metadata to members should also ideally by signed by the member, so that's why I compared them to aliases.

[staltz]

Other thoughts about this

So the current allow list form needs another input field

I think it would make sense to merge the aliases and members list pages into one, and add role dropdown too. It would need some redesign, indeed. We might even need a "member details" page that lists all the details of that member and allows editing (e.g. revoke alias).

[cryptix]

confusion by having both nickname and alias

I'd argue the welcome strings we have act like help/descriptions on the page and should do a good job there.

minimizing how much the admin knows about its members

Honestly, I don't see how moderators can effectively govern a room if they don't know who is who.

Additionally, this feels like invite consumption should then be grouped with alias creation. Last time I asked for this you were against it, claimed people might not want an invite... 🤷

Attaching identifiable metadata to members should also ideally by signed by the member

Do you want to do this now? I'd rather put this on v2.2 or later since it would need considerable re-work and generalization.

Another approach to storing these on the room could be to hook into a configured peer and query it for type:about messages of the member, to shortcut this need for more signed off-chain redundancy.

I think it would make sense to merge the aliases and members list pages into one.

This sounds reasonable but can we do it as a follow-up? There is a lot of needed changes in here.

[cryptix]

we had a call and among other things decided to: later merge aliases with members managment/editing. We don't want to have a 2nd database of the social data that is already in ssb (type:about showing maybe in future versions) at which point nicknames might become obsolete. Generally we agreed that we shouldn't try to guess what our users might and might not want.

[staltz]

I took a quick look at all files and this seems good. :)

[cryptix]

Also did a high-level walk through with cblgh. Merrrging now!