I've had something like this in mind for a very long time now, well before joinjabber became the collective that it is. Each time we talk about the website I feel we haven't really discussed what should go in there and for what reasons, so here's my take. This is why I wanted to start the project in the first place.
The current homepage "does the job", and it's great we have it, but it's far from what I have in mind.
This isn't born out of my magic hat. We've had a few chat sessions with UX designers. I'm trying to distance myself from the "by geeks for geeks" image here that we see everywhere around free software.
I'd be very happy if more designers would chime in and help improve the idea.
I'm creating a different issue than joinjabber/website#27 because my gut feeling says it's different. joinjabber/website#27 is also too over-engineered to me. I'd like to solve one use-case and solve it well. We'll merge them later if it appears they are similar enough.
In the end if this isn't what the collective wants, then I'll probably take my leave and go do that elsewhere because I think it's important, if I get the motivation and time for it…
Gitea supports editing issues so we'll be able to refine this over time. Here it goes.
# Who (target)
Mr, Mrs, Mx. Let's call them Bob.
Bob uses WhatsApp, Telegram, or Facebook Messenger, or a mix of all those, because their family is using it. Bob does most of their online activity on mobile, even though there is a desktop computer in the house, which is sometimes used to connect to Facebook. They play Youtube videos from the TV.
Bob doesn't know about computers very much and is not particularly interested to know more, or just doesn't have time for it.
Bob also finds it very annoying to have to remember different passwords for every application. They may have been writing them down, or they may have been using a password manager on their desktop because someone from their family installed it for them.
Bob has somebody in their circle who is using XMPP and would like to communicate with them. This is where JoinJabber makes its entrance.
# The What
Help Bob get into the XMPP network easily.
This seemingly simple sentence hides a lot of complexity, and I'll try to go through what I think is necessary to do.
## Help, easily
Hoping into a federated network is often seen as painful, because right off the bat there are choices to make: a username, a password, a server.
Choosing a server specifically is a complex task, and I hope that's where we can help.
**Why choose a server at all?** Centralized networks don't have this "problematic" and so many users have never been exposed to it. One may want to say that this isn't true because everybody is exposed to emails. And in a way that's correct. Even though nowadays people don't do emails anymore, they do Gmail, or Yahoo, or WhatsMicrosoftsServiceAgain. And it happens these can communicate together. At work, they got assigned an email so they didn't get to choose either.
Nobody ever took the time to explain to Bob that `email@example.com` meant the user `bob` on the `gmail.com` server. And they've indeed never had to know this to send emails. It just works.
**Why choose a server over another one? What should I know when choosing? How do I know if it's good for me, for my use-case? Should I worry that it doesn't do X?**
These questions are very important, and yet it's almost impossible for Bob to answer them without investing significant time in documentation, or asking around.
## An attempt at an answer
So while I definitely don't want to hide the fact that there are servers in a federated network -- because it's a component of the federation property and I think people should know -- I want to improve the situation of getting into XMPP. And to me this translates to making many choices in stead of the user.
Concretely, this means asking for the less possible and trying to get the user the fastest (with the least steps) on XMPP, without compromising on security and privacy.
If this means that we have to handle complex things on our side, and or the operator's side, then so be it, as long as the user doesn't see it.
This also means that I'm ready to involve operators in the process if need be. Having them deploy code that would be necessary for this on-boarding process.
The same thought process goes for the choice of a client. The less choice presented to the user the better.
I am still struggling to see what would go into such a page/process though.
The steps required are (not especially in this order):
- Getting a username
- Getting a server name
- Registering the account
- Suggesting a client to use
I am thinking the maximum that we should require from the user is a **display name**, and then a server would be chosen for them (depending on many variables that could be adjusted in some advanced view, maybe). With this we have `username@server`.
For the registration, we could redirect to the server handling it. Maybe with a token that JoinJabber would be using, they could have access to privileged actions such as determining if a user exists, and performing the registration.
This token could also be used to open up invite-only servers to the world through JoinJabber, for example.
I'd like to avoid asking for a password at all on the page, so that Bob doesn't stall here, because as mentioned above Bob doesn't like passwords. I'd rather have the client generate one itself, which is already what some are doing (Snikket, combined with an invite token). And then extend the protocol to have clients being able to make other clients connect without needing to enter a password at all (QR code or some other token thing).
Talking about clients, same as with servers, we should recommend one that we think is best for the user (depending on variables: platforms etc.). The thing is that we might already have sent the user away from our page at this point so I'm not entirely sure how to do.
And that's the bulk of it from a UX perspective. Technically it doesn't seem impossible, things will need to be developed for sure.
So to summarize:
- Ask for a display name
- "Randomly" assign a server
- Somehow check if that user exists on the server
- Give a link to a client so that registration is handled directly in it, and neither the user nor us see the password at all.
## What does this imply for JoinJabber?
1. We still need a list of reliable servers that we deem recommendable (compatible with the software we recommend, political affiliations and whatnot)
- Privileged token / In-Band Registration (IBR) done client-side (hosted by us or not): Technically we don't have to handle spam, but we should help operators. They would still get access to the same amount of information, plus that the user comes from JoinJabber.
- No token / Redirecting users to the server web registration: No spam for us, business as usual for public servers.
3. [Fill me]
## List of servers
There are already public lists, all have various opinions on what servers to include. One format that looks like it would fit the most to me is [providers.json maintained by melvo](https://invent.kde.org/melvo/xmpp-providers/-/blob/master/providers.json). There are many things automatable in there though (with a module on the server).
## What's missing in the protocol?
Invite tokens have been a thing for some time in Snikket. Somebody would need to confirm that this can be extended for this kind of usage (a somewhat static token, or regenerated every so often that would have different restrictions than what Snikket uses currently?). Also I don't know about implementations in ejabberd.
Other than what Snikket forked off, clients might not be handling invite tokens (apart from Yaxim? What about Dino, gajim, beagle, etc.)
Other types of privileged tokens might not be a thing yet. Specifically I'm thinking being able to check that a user exists on a server. This isn't really something that a server wants to expose in general (even if technically there are ways to know.. but that's really just side-effects).
We also need to figure out how to prevent everybody from using the public token. Having operators restrict to Token+(our) IP doesn't do as we'd certainly do operations client-side, so with the IP of the user.
I'm not so worried about deployment since we'd be in contact with all operators that appear on the website.
## In summary
I'm probably missing many things but I'll leave it here for now. If edits other than typos ever happen I'll bump the issue.
Please comment :)
Feedback still appreciated, either here or on Codeberg.