scanning QR with mailto link is returning contact ID of email contact instead of encrypted identity

[adbenitez]

QR with mailto link (type DC_QR_ADDR/320 ) in the parsed QR the ID of the unencrypted address contact instead of the encrypted contact, we normally when handling mailto links prefer the encrypted contact (it is used by bots to auto-complete commands via links in HTML messages)

when asking for "get contact by addr" we also return the encrypted contact ID already

I came into this problem because I wanted to parse mailto links via existing core api instead of having to manually parse it in the UI client

[iequidoo]

Forwarding my message here from the "2.x release coordination" chat:

Putting a "mailto:" URL into a QR code would always cause looking up an address contact when scanning it, so it is not the same as calling dc_lookup_contact_id_by_addr(), but i think this is correct because when one just posts their email address, they usually mean "send messages to this address and encrypt them if you want", the key fingerprint isn't attached to every message for simplicity of texting and reading messages. But if a QR code is shared, adding the fingerprint to it makes no harm, so if it's not added we may think that it's on purpose.

It seems that time we decided not to change this. So the question is why using a DC_QR_ADDR QR instead of DC_QR_ASK_VERIFYCONTACT, i.e. put the fingerprint into QR to avoid looking up a wrong contact? If you don't know the contact fingerprint and wrap a mailto link into QR just to parse it by Core, maybe add a separate Core API instead?