Delta Chat supports importing vCards already.
There is a scheme called MeCard that contains a single vCard: MeCard (QR code) - Wikipedia
It should be easy to implement it at least to add unencrypted contacts. For encrypted contacts the QR code may be large because of the key inside and nobody generates such QR codes anyway.
I just checked the sizes of couple of DC generated vcards (for encrypted contacts, with keys).
If there is no picture, the size is usually around 700 bytes.
E.g. libqrencode manual says the capacity of QR Code is up to 4000 characters.
With embedded picture vcard size card can go up to 60+ kbytes (or even higher - I just tested small amount, and not looked ad DC app code).
IMHO it’s better to include the code and downscale the picture (and maybe encode it to PNG with reduced color pale) to fit into 4000 chars.
May I ask, what are the advantages over current vcard format?
An open standard for contact QR codes would be nice. I am not familiar with MeCards. They look decent except for the name field; of all places for software to make cultural assumptions about name ordering, Japan?
I think opgpcard produces QR codes of VCards containing key fingerprints and a keyserver link; you can also just omit fields. This makes them resonably compact – I’ve got one at 255 bytes – but the dependency on the server is undesirable.
Maybe MECARD is not the worst idea.
Found this: Barcode Contents · zxing/zxing Wiki · GitHub
BTW quote:
It’s interesting to note that, actually, QR Codes can encode data more efficiently in some cases if only uppercase letters are used. That’s because it has a special encoding mode for text consistent of only (uppercase) letters, numbers, and common symbols. It may be advantageous to encode a URL like HTTP://MYSITE.COM/FOO… rather than http://mysite.com/foo… for this reason. However, this depends upon the web server responding to requests correctly when the URI is uppercased. It’s not necessarily true that URIs and paths are treated as case-insensitive by a web server, since URIs are technically case sensitive. Don’t try this unless you test it to know it works.
Deltachat’s contact URLs are emphatically case-sensitive, because the codes in them are mixed-case (and would otherwise presumably need to be longer).
I didn’t think about the invite URL…
In example URL:
https://i.delta.chat/#A1B2C3....99FFFF&a=username%40domain.tld&n=xxxx&i=yyYYyyYY&s=zzZZzzZZ
Maybe mostly-uppercased URL will result in ‘shorter’ (better readable) QR.
& symbol is not available in “alphanumeric” mode, so invite link cannot use it even if you uppercase all the letters.
Just a note for future reference to all those who are messing with my email address. While a domain name is case insensitive, the localpart of the email address must be treated as case sensitive in almost all cases and some existing servers actually refuse it if you lowercase it upon delivery. Even on hosts where such localparts are folded upon reception, it is very handy as a subaddress tag for the user upon registration to various third parties.
To clear another common misconception: the localpart may be up to 64 bytes long and can contain a rich set of characters:
Also a message for anyone trying to (and failing to properly) validate my email address with ad-hoc regexp: stop doing it already!
A QR code may be spliced up from multiple sequences of payloads encoded in different encoding modes. It is quite expensive to switch between modes back & forth, but it can be reasonable if your payload is already long and you can solve your use case with just a few mode switches. Not that I advocate for MeCard in particular, but I thought some may find this optimization useful.
In hindsight, the choice for “&” as a separator was a huge mistake. I acknowledge that it is a convention for server side CGI arguments, but nothing forced DC to use this in the client side anchor, especially if it was known to be encoded to QR codes almost always. Major sections of the information are embedded as base-16 and base-64 encoded at 8 bits/character. I estimate that as a result, DC URL & QR are generally about 30% bigger than they would need to be with a more optimal representation.