Generate chatmail credentials on the client #7360
Conversation
link2xt
force-pushed
the
link2xt/dcaccount9
branch
4 times, most recently
from
056dfcc to
624e0a4
Compare
There was a problem hiding this comment.
lgtm -- did you test in practise that it works with nine?
let me note that i am slightly skeptical of introducing a new scheme: we could also just special-case dcaccount:https://nine.testrun.org/newemail and not introduce a new account scheme that we might have to support forever.
Corresponding core PR: <chatmail/core#7360> dcaccount9 is similar to dcaccount, but contains the domain instead of the URL and generates 9 character username with a long password locally. This way we avoid unnecessary HTTPS request.
|
I tested it with nine with desktop PR: deltachat/deltachat-desktop#5618
Then nine becomes special and for everyone else onboarding is slower and less reliable. The goal is to remove username length configuration for chatmail relay and use dcaccount9 on the page after upgrade. "9" in the scheme means nine characters, not nine.testrun.org. Same for multi-transport, configuring transports at least for the default list should not involve HTTPS requests. |
|
Will change it to just using |
link2xt
force-pushed
the
link2xt/dcaccount9
branch
3 times, most recently
from
c2a5656 to
729869a
Compare
This is similar to old `dcaccount:` with URL, but creates a 9-character username on the client and avoids making an HTTPS request. The scheme is reused to avoid the apps needing to register for the new scheme. `http` support is removed because it was not working already, there is a check that the scheme is `https` when the URL is actually used and the core has no way to make HTTP requests without TLS.
link2xt
force-pushed
the
link2xt/dcaccount9
branch
from
729869a to
0bc3db4
Compare
Depends on the core PR: <chatmail/core#7360> Using domain name in dcaccount scheme works similarly to existing scheme, but no HTTPS request is made and credentials are generated locally on the client.
| } | ||
|
|
||
| /// scheme: `DCACCOUNT:https://example.org/new_email?t=1w_7wDjgjelxeX884x96v3` | ||
| /// scheme: `DCACCOUNT:example.org` |
There was a problem hiding this comment.
Would make sense to document this variant in the interface repo https://github.com/deltachat/interface/blob/main/uri-schemes.md
Corresponding core PR: chatmail/core#7360
Corresponding core PR: chatmail/core#7360
Corresponding core PR: chatmail/core#7360
Depends on the core PR: <chatmail/core#7360> Using domain name in dcaccount scheme works similarly to existing scheme, but no HTTPS request is made and credentials are generated locally on the client.
Corresponding core PR: chatmail/core#7360
This allows
dcaccount:to contain domain name instead of the URL.This is similar to old
dcaccount:with URL,but creates a 9-character username on the client
and avoids making an HTTPS request.
The scheme is reused to avoid the apps
needing to register for the new scheme.
httpsupport is removed because it wasnot working already, there is a check
that the scheme is
httpswhen the URLis actually used and the core has
no way to make HTTP requests without TLS.
For this to be used clients should switch from old dcaccount scheme to dcaccount9. We don't convert dcaccount to dcaccount9 automatically even for known chatmail servers.
Corresponding desktop PR: deltachat/deltachat-desktop#5618
Android issue: deltachat/deltachat-android#3963
iOS issue: deltachat/deltachat-ios#2855