One issue that I commonly see brought up when I onboard people to Delta Chat is that it’s a bit cumbersome to share the links or QR Codes as the main and only supported way to make contacts, so I was thinking of some possible ways that “usernames” could be implemented on-top of existing chatmail infrastructure (notably NOT the underlying email address, as it’s only used for transport)
starting simple, we could allow users to set usernames at a domain/website, by having the website serve a small file that contains the actual details to a user in a URL like user.example.com, kind of like what ATProto/Bluesky does with their alsoKnownAs field in user identities
to make this work, I’m thinking that the UX should be simple: input a username in the @user.example.com format and have delta automatically resolve the contact data from there
the data would by queried by doing a GET request to user.example.com/.well-known/delta/user, which could contain a response such as:
{
"avatar": "[data here]",
"url": "https://i.delta.chat/[contact info here]"
}
the avatar field could be optional of course; to bundle the avatar right into the response it could be encoded to a blob / Object URL that would otherwise be commonly seen in browsers.
Making a GET request to the root, i.e user.example.com / should open a contact page similar to that seen at i.delta.chat already; It could even be identical to the one already served, or just be a redirect to the corresponding i.delta.chat URL seen in the url field
Registering a username
Usernames could have varying degrees of “integration” in terms of how to obtain one. It could be a manual setup process, where one sets up their site to follow the format given above, but that would be tideous.
For a start, it makes the most sense to have the chatmail stack accept setting a username optionally by sending a PUT request containing the data above. This would have to be an authenticated request in one way or another, as to not make it possible to register someone else’s identity without their consent.[1]
Once the data is sent the chatmail relay could, if it accepts usernames, then setup a subdomain and serve the required data. This assumes that there’s a common mechanism to allow for subdomains to be quickly deployed programatically, but this is not a guarantee. See alternatives below
Alternatives
Webfinger
This could also very much be implemented with the existing WebFinger protocol instead, should there be the need for more easy, standards-based expansion in the future to include additional data without breaking backwards compatibility.
the principle of domains as usernames stays the same, but it would instead respond with a webfinger-compliant response containing roughly the same data as that seen above.
subdomain-less usernames
Alternatively, instead of having domains like user.example.com be the username, it could instead be something along the lines of @user:example.com or @user@example.com (notably any scheme that does NOT collide with existing emails)
how usernames are “served” would then change from being user.example.com/.well-known/delta/user to being example.com/.well-known/delta/user?=@user, indicating a user local to that chatmail relay
it would then give a slightly different response to what’s outlined above, namely:
{
"username": "@user:example.com",
"avatar": "[data here]",
"url": "https://i.delta.chat/[contact info here]"
}
the username field would be required so that the client can compare it with the “expected” username[2]
This would cut out the need for having the chatmail relay be able to configure subdomains, at the cost[3] of requiring a different username format.
I am very much looking for thoughts and ideas on this, and pardon me if I missed an open thread about this topic!