New Account ID format

In addition to the existing account IDs (public keys), we will support a new format with the following shape:

USER_ID@DOMAIN

For example, K3A8L45@seed.hyper.media

Inside each server, any authentication mechanism can be used to identify and resolve the UserID. For our initial implementation, we will use magic links.

These new Validator AccountIDs can be invited to documents, or mentioned. They can even have their own site, but that is not really recommended because they are dependent on another domain.

Server Config Options

When you set up a ANY HM host, you must choose at least one of the following options.

Set Up Email Sending

In the server, add the SMTP settings (or Mailgun or something). Then the server has the ability to send notification and email settings.

This will enable the "sign in with email" workflow. To sign in, the user will type their email address and click "Verify my Email"

Set Up Allowed Upstream Identity Provider(s)

The site owner will choose an Upstream Identity Provider where users will authenticate through

This will enable the "sign in with <hostname>" workflow which feels to the user like OAuth.

Enabled Any Upstream Identity Provider

Any upstream identity provider will be allowed. So the user can input their own domain. As long as that domain is using the HM protocol, it can provide identity for the current domain.

App-Based Identity

A server may be configured to show the "device linking" flow that will allow the identity provider to be based in the desktop app or mobile app. This is the most secure option but it will require more steps from the user. So they should be encouraged to do this.

Fallback Identity Provider

If there is no email sending setup, and if there is no upstream identity providers, then we will fall back to using hyper.media as the identity provider.

User Auth Workflow Options

Sign in with hyper.media

The user creates a comment on hyper.media and then is prompted to create an account. Or they directly click "Create Account / Log In" and the workflow starts.

They get two options: App Identity (secure) or Email Identity (convenient).

The user clicks Email, and they type their email address. When they submit, their browser's public key is sent alongside the email.

The server generates a user ID or looks it up if the email has been used before. A token is generated and emailed to the user. When the email link is clicked, it becomes validated.

Now when this accountID is mentioned or creates a comment, their name is "Display Name (hyper.media)"

Sign in with hyper.media from example.net - H.M is the identity provider

User clicks on "Sign in with hyper.media" and there is an OAuth-style redirect to hyper.media where the user may already be signed in, or they can create an account, or they can sign in with the above workflow

Now when this accountID is mentioned or creates a comment, their name is "Display Name (hyper.media)"

Sign in with email address - example.net is the identity provider

Say we are at example.net (self hosted) and the site owners have disabled all identity provider except for their own email validation. The platform is trying to keep a very streamlined user experience and own all the emails.

The user creates a comment or clicks login/register. They see an email input and type their email. When they submit, their browser's public key is sent alongside the email. An email gets sent with a SMTP provider, and the user clicks the email. After confirmation the server signs a validation which contains:

User ID

Provider ID

Domain (eg example.net)

Signature

This validation will be distributed alongside the content to make sure that people know who this person is.

Sign in with <other identity provider>, user input domain

Similar workflow to "sign in with hyper.media" but the user is allowed to type any domain. They will be redirected to this domain for auth.

Sign in with Seed App

Similar to the device linking workflow we have today, ideally with an improved UX and with mobile app support

Their account ID will just be the normal key-based account ID of the app identity. When this account is mentioned or when they make a comment, their self-proclaimed name will be shown without any domain name.