On 9 April 2018 at 11:47, Corné Plooy via Lightning-dev <
> Is this really only about reducing the size of QR codes? How many
> percent reduction do you think you can accomplish with your approach? I
> think, when it comes to reducing QR code size, it makes more sense to
> think of a better way to encode the node ID. Hexadecimal isn't exactly
> the most space-efficient encoding.
We'd save 33 bytes by not using hex. Makes the QR code a bit rarer
(whatever is opposite of dense).
I intend to support both approaches, if there are 33 bytes before the '@'
it's raw, 66 it's hex.
> Op 07-04-18 om 17:17 schreef Robert Olsson:
> > Hello all,
> > I seem to not find a bolt regarding the QR code of node@ip:port
> > It seems eclair only supports the format hex@ip:port format, and i
> > haven't tried any other mobile wallets.
> > I thought there would be support for bech32 nodeid:s to keep the QR
> > small, but it doesn't seem that way.
> > If it isn't standardized yet, i think we should do it soon so all
> > wallets will support it from start and we can avoid bulky QR codes.
> > To fully utilize QR it should work with charset in text-mode, so i
> > would suggest a format like
> > lightning:ln1bech32nodeid/ipnumber/port
> > where /port is optional if port is 9735
> > this is to avoid @ and confusion of : in ipv6 and :portnumber
> > (skip '[' and ']' in ipv6)
> > another approach would be to encode ip and portnumber in bech32 as
> > well. my opinion is that everything coded entirely in bech32 shouldn't
> > need a protocol so the 'lightning:' part could possibly be omitted as
> > well.
> > or did i just miss a bolt somewhere?
> > best regards
> > Robert Olsson
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightningfirstname.lastname@example.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> Lightning-dev mailing list
Codex Apertus Ltd
Lightning-dev mailing list