implement dclogin scheme

[Simon-Laux]

see https://github.com/deltachat/interface/pull/48 for the specification.

progress

deltachat.h

• [X] constants
• [X] documentation (lot/function)

implementation

• [X] parsing
• [X] test parsing
• [x] have a test for usename+extension@host cases
• [X] apply/action
• [x] test apply/action (test from qr method)
• [X] lot text1

bindings

• [x] node bindings constants
• [x] jsonrpc qr type
• [ ] python?

[Hocuri]

Just so we're on the same page, my understanding is that this is waiting for @Simon-Laux to fix the CI and fix my remaining comments (or comment that/why he doesn't think this can/should be changed). Or @Simon-Laux would you like to hand this off to someone else?

[Simon-Laux]

@r10s wanted to review it, but he also kept telling me how that isn't a priority for the 1.32 release, which should be out by now. anyhow I'm a bit confused here.

Anyways I'm not against handing this over as long as the spec doesn't change and it still works afterwards. I'm only against:

• wildcard config values (taking every possible config value, we could do such things maybe in a second version (in the version property), but even then I like the thing being well documented and future backwards compatible)
• removing the version property

[Simon-Laux]

easily leads to legacy code lying around for rare cases, including possible bugs, potentially waiting for being misused. why already prepare this pattern without need?

it is an documented interface to the outside, we don't control the creating of the qr codes, so if for example a provider once happens to implement V1 and then don't bother anymore when we bring out V2, then if we don't support V1 anymore, then there is an qr code for dc on the provider, but you can't scan it because in theory the provider would need to update to V2 or you have to downgrade DC (no normal user will downgrade DC ever).

I personally think the forwards and backwards compatibility is worth it.

With having a different version or variant, we can make certain parameters required and ensure the user scans it with a version of delta chat that supports it fully.

V2 could also just be same as V1 just with videochat and a fileserver required for example, so the V1 would not even get obsolete.

[r10s]

it is an documented interface to the outside, we don't control the creating of the qr codes,

sure. i think, no one has misunderstood that.

i just pointed out different, maybe easier and safer approaches - while still having the option for forwards and backwards compatibility - but i also pointed out that i do not see the current implementation as a blocker :)

[Simon-Laux]

or, better, a test added :)

sure, but I don't have a head for this anytime soon. Also it's kinda a theoretical problem anyway, In the sense that it is nice to have, but in the end it's up to the users to follow the spec.