Igor Cota [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-09 📝 Original message: Hi all, On 9 April 2018 ...
📅 Original date posted:2018-04-09
📝 Original message:
Hi all,
On 9 April 2018 at 11:47, Corné Plooy via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
>
> 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.
Igor
> 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 at ip:port
> >
> > It seems eclair only supports the format hex at 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
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
*Igor Cota*
Codex Apertus Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180409/eb71167a/attachment.html>;
📝 Original message:
Hi all,
On 9 April 2018 at 11:47, Corné Plooy via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
>
> 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.
Igor
> 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 at ip:port
> >
> > It seems eclair only supports the format hex at 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
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
*Igor Cota*
Codex Apertus Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180409/eb71167a/attachment.html>;