Single link: account creation + chat invitation (+ more crazy stuff)

Feature Proposal
1

Actual behavior

If I use DC app on mobile to read QR code with encoded link https://nine.testrun.org/#6C49FB963C89EAB5AAEB6F2EC5D5DA5DD7DB1F03&a=dxaf7hf36%40nine.testrun.org&n=9er&i=T7Rs9d76kH6NimvmLOxPmEED&s=teaXFN-D0aLgTqFaJEu6xSES (real link, my actual account), DC app opens URL https://nine.testrun.org/ in a web browser (maybe even with query part - I didn’t check).

JIC here is same link, QR-encoded:

nine.testrun.org
nine.testrun.org212×212 447 Bytes

I didn’t take a look at the source code, but I think that DC app checks if domain in URL is i.delta.chat, and if not, just pass it away.

Notes

There was some previous discussion: How to invite new user to specific server?
From now on, as ‘server’ I will mention some private chatmail server, not one of DC official ones.
I will use numbered points for referencing.
There may be some errors in exact terms, so please pardon me.

Expected behavior

  1. DC app should examine the invite URL, pasted or scanned, inside the app. If link contains specific args (like #<user_pub_key>), DC app should not pass it to the web browser.

  2. Instead, DC app should ask:
    “User user@server.tld invites you to chat. Do you want to create account on server.tld ? …”

  3. “… or use your existing account?” (and give a list of existing user’s accounts to select).

  4. Then, after account creation (or selection), DC app should immediately establish a conversation with specified user.

  5. Before asking user, DC app may check if account registration is available on specified server (with the token from URL).

  6. (Do I get it right that account registration on the server may be limited only to users with special token?)

  7. URL can contain fingerprint of server’s TLS certificate, to allow verification without using certificate chains outside of control of server administrator.

  8. This may also be not a fingerprint of actual server certificate, but public key of server’s administrator, with which actual server’s certificates will be signed (advantage here over my previous point is the ability to re-issue the certificate without loosing the trust of users apps).

  9. Also there may be parameter in the invite URL, that says “it’s standalone server; it is not talking to other mail servers, so if user want to accept the invitation, she needs to create account there; existing accounts will not work”.

Background

a. In some (not so democratic) countries there are active DPI boxes installed on every ISP network.
b. Encrypted means of people’s (pseudonimous) communications may be (soon) prohibited by law, or just quietly ‘dealt with’ by the people in power.
c. Messenger apps installation from app markets is not prohibited by law (yet). But servers hardcoded in (many) messenger apps are blocked.
d. Custom messaging servers inside the country borders are out of state’s attention currently.
e. The state are not nearly ready to get the whole email industry under it’s control …
f. … but may start to mess with TLS certificate system.

Goals

A. simplify the onboarding process for DC users (point 1-5)
B. keep chatmail servers hidden in the crowd of ‘usual’ mail servers (points 6 and 9)
C. get ready to work on self-signed certificates (points 7-9)

1 Like
2

yip, combined account creation and getting directly into a chat afterwards, is definitely something many (me included :slight_smile: ) want to have, and there is some agreement, that this will be added.

however, due to limited resources, it is just not done yet :slight_smile:

2 Likes
3

Re: B
In the short term, removing obvious distinguishing marks from chatmail servers seems workable. In the long term, giving all common e-mail servers optional chatmail capabilities seem preferable.

This seems to be happening already with Mox. There has been discussion of YUnohost and Freedombox on the forums.

I agree that being able to enable moderated Chatmail, with accounts limited to pre- or post- approval (using tokens etc.), would make stealth servers easier. It would make them use more human time, tho.

4

Maybe another aproach will be more achievable.
Can ready-made account be imported to DC app via link or QR code?

Can you make a list of these marks?

5

Importing the private key of a new account seems needlessly risky. You want a specific preset password? Username? You could do an automated variant of this:

I think you are making a list of them! Maybe a private list.

6

yes.

there is the DCLOGIN: scheme for that, interface/uri-schemes.md at main · deltachat/interface · GitHub , iirc, it is used rarely, if at all, so not sure how well it is supported on all platforms. also, that does probably not work with “chat invitation” in the same scan as well.

so, allowing to create an account on scanning a QR-invite-code might be more doable

7

How did I missed it? Thanks :slight_smile:
Hopefully I can (temporary) use it instead of 1-6. Eager to test it.

Pp 7-8 (self-made cert trust setup) are steel needed, though.

1 Like