Mastodawn

@millesimus
- Passwordless registration
People have been signing up for email accounts and mostly remembered their password for decades.
Without any means of recovery, you might accidentally lose contacts and you'd have to share your address with everyone again. What could be reasonable though is a multi-stage onboarding where the client will only ask you to setup means of recovery (which could also be other things than a password) after you started using it.

@larma Not saying it's impossible to use passwords. Just saying that it's an obstacle, and that I have experienced many "forgot my password" situations with my users. I think it would suffice if they had to write down the password when making a backup.

@millesimus
- Get rid of the roster
Most clients already allow you to chat with others without adding them to your roster. However if you start adding those contacts to PEP nodes, there is no privacy win (it's just a different list). Presence has other usage than purely informational to the recipient user, it's also used for technical purposes so that remote servers know a device is online and ready to receive updates.

@larma Clients allow it, yes. I would love it if the ecosystem would move to this as the new default. Less metadata on the server.

@millesimus
- Make groups a client concept
This makes sense for small, private groups, but less so for public channels, simply because it doesn't scale. Also your server will always learn about those groups anyway due to patterns: research has shown it takes 3 to 5 messages in a group for a server to reliably discover group membership for this kind of group (client fanout), even if sealed sender is used.

@larma
I agree that this is mainly a thing for private groups. I just didn't write it down.
I do agree w.r.t. to correlations, but 1) it's still better than having the metadata rest on the server, 2) it solves the annoying issue of users on remote servers dropping from the group on a server restart, 3) the correlation could be mitigated by multi-address profiles which are also on my wish list.^^

@millesimus
Concepts for what some also call "multi party direct message" have been around for some time. The problem is the adoption, as it can't be done easily in backwards-compatible fashion when existing clients only have the concept of server-managed group chats and direct 1-1 messages.

Maybe we can find some solution where a MUC is still used, but only for communication with non-supporting clients, so we can start rolling this out backwards-compatible and eventually cut the MUC out.

@larma Maybe clients could implement them and show an "upgrade this group chat to the new version" button to group admins. Or would you prefer backwards-compatibility even for those cases?

@millesimus
Users don't know and shouldn't care which clients other users use or want to use. Such a button thus might accidentally kick users from a group without the user or client knowing, which sounds like a terrible UX. Given that the benefit of this "upgrade" for endusers is really not that big (no new feature, no practical changes at all in the happy case), I doubt a lot of people would ever want to press such button except developers.

@larma Yes, I see. Silent kicks are a hard argument against it. Users wouldn't even have the chance to switch their client to rejoin the group.