# standardize user signup on web free software The work to list instances and service providers of a certain software is to put in the context of improving the sign up experience. This document is an attempt at listing the use cases, the intents and possible technical solutions to solve the identified challenges. # list of existing solutions Before diving on the topic, it is good to know what is already available out there. - [nodeinfo](https://github.com/jhass/nodeinfo/issues/19) NodeInfo is an effort to create a standardized way of exposing metadata about a server running one of the distributed social networks - https://joinmastodon.org/ # use cases ## mobile client As a user, I went to the play store/F-droid/Apple store, searched for a functionnality, and ended up downloading the mobile client of a free software. In the proprietary world, there is only one backend associated to a mobile client. I can give my email/phone number, password and get started. In the free software world, we have to help the user to find an open instance or create it's own. ## alternative list As a user, in the process of owning my data, I asked a friend or Internet how to do X, and they recommended me to use Y. I go the website of Y to start doing X. In the proprietary world, I give my email/passord and I get started. In the free software world, we have to help the user to find an open instance or create it's own. The mobile workflow is clearly where most users are, and the website is still used by many people in the world. With these two workflows in mind, we probably cover more than 95% of the use cases on how a user will try to start use web free software. ## application user As a user of a shared/demo instance I like it so much that I want my own instance for my organization. It would be nice to have the instance creation process embeded in the application itself in some advanced configuration. # Web application kind We have to first distinguish if the instances of the free software will be shared or private. ## shared/multitenant In a shared instance, the user will get only one account. It is also possible that the user can invite comrades from there organisation (compagny, familly, association, union..) to be there as well. We have to distinguish federated and not federated software as this will impact the user experience in choosing an instance to join. ### federated The wording of `mastodon` is really good here: ``` This is like picking an e-mail hosting provider, but more social since you'll see your neighbours. The domain will also be part of your username! ``` We have to help the user choose the instance, keeping in mind they'll only need one instance. They might still join various instances for there various identities (especially in a social app). ### not federated In the case of not federated, we have to tell the user that they'll have to join "communities", and present the different ones available. They might join various instances to work, collaborate with the various communities. ## private In this context we have to help the user to choose between: - getting hosting, the free software as a service model - DIY, install and secure it on your own server - mixed model, get an installed instance that you have to manage yourself We also have to help choose domain or subdomain, the size of the instance, and possible options. # Possible workflow ## shared instance This is the most common case. As a user, I want to experiement the free software and/or get started with it to use on a daily basis. I am presented a list of instances that I can filter based on specific information that are relevant to the software I'll use. (example `language` and `interest` in mastodon.) As a nice to have, we could also show an advanced view with all the dimensions you can filter instances on. ## private instance This is less common case. And this will be asked by power users. On the mobile journey, this shouldn't be on the default screen (or under an advanced button). On the website, this can be more common case, and we could ask the user at the beginning to choose between the 2 flows (shared or private) Then, as a user, I'm asked to decide some parameters: - my server (redirects to the install manual), or a hosting provider - managed or not - domain name or subdomain - my own domain (that I'll point to the provider) - plugins - size (cpu, mem, storage) - preferred language - support timezone For instance, on RocketChat, plugins can be IRC gateway, chat bot, and on Nextcloud, this could be collabora. Based on this question, we can establish a list of good hosting providers for the user. With a standardized API, we can even provision the server with the provider right from the mobile app, or the website. # Dimensions To help user choose an instance, we need to list dimensions that will help them to do an informed choice. Some dimensions will be specific to the software and some will be common to all. Let's list the common first and look at the specific for some known example after. ## Common dimensions - uptime (external) (especially true for shared instance, but can apply to private instances as well) - TLS cert quality (external) - speed (external) (first meaningfull paint..) - ToS;DR grade (external) - version of the software - support language - support timezone - economic model (free, donation, paid) - if paid, size of the demo account (GB, messages per day..) - ToS link - description - what makes it different - name - name of the compagny/group/individual behind - list of plugins - installed for shared instance - or possible to install for private instance - number of users - last activity - specific to private instances - packages available (instance size for # of people + price) - plugins prices ## Specific dimensions Didn't find any yet. The more common the better :) - RocketChat - - Nextcloud # MVP All of this is rather theoretic. Let's defince an MVP we can start working on. We want to put all these metadata as json-ld, with schema.org. If a parameter is not available at schema.org, we'll PR. For a shared instance, the best place to expose these metadata is from the software itself. With one update, all hosters have there json-ld ready to be scrapped. Let's start with one json-ld exposing the following: - version of the software - support language - support timezone - description - what makes it different - name - link to website of the compagny/group/individual behind If the data are not already present, we'll need to add an admin dashboard to be able to fill them in. Then, if somebody wants to be listed, they only need to make a PR to add the URL of there shared instance. With hugo, we can then use remote json as "databases". And generate the list of available instances this way. # Next steps - uptime monitoring - TLS monitoring - https://tls.imirhil.fr/tls - https://observatory.mozilla.org/ - speed monitoring - Automate ToS;DR grading # Misc Some people might have concerns about exposing the version of the software. We could hide this behind a secret. Or make a push of the version instead of pulling. (but well, it is pretty easy to know a software version, just from the hash of js/css/html files I guess...) We can then filter out instances that are lagging too much behind. (same would apply with uptime/TLS/ToS;DR)