websocket address type: allow transport over RFC6455

[rustyrussell]

trafficstars

~And allow transparent upgrade~.

Allows you to advertize an alternate port. This allows a wider range of software to interact with the lightning network.

[TheBlueMatt]

Is this better off done via a bridge instead? Last I heard there weren’t any decent websocket implementations that weren’t huge, which (maybe incorrectly) led me to understand that it was reasonably complicated. In either case, it seems if the only options are fresh code or huge dependency, it’s probably a bad idea for us to recommend users integrate it instead of simply using one of the websocket bridge services.

On Jul 27, 2021, at 01:31, Rusty Russell @.***> wrote:

 And allow transparent upgrade. This allows a wider range of software to interact with the lightning network.

You can view, comment on, or merge this pull request online at:

https://github.com/lightningnetwork/lightning-rfc/pull/891

Commit Summary

option_websocket: allow transport over RFC6455 File Changes

M .aspell.en.pws (2) M 08-transport.md (47) M 09-features.md (2) Patch Links:

https://github.com/lightningnetwork/lightning-rfc/pull/891.patch https://github.com/lightningnetwork/lightning-rfc/pull/891.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[kristapsk]

@TheBlueMatt has a valid point here, we used https://github.com/novnc/websockify at my old workplace.

[Roasbeef]

Last I heard there weren’t any decent websocket implementations that weren’t huge, which (maybe incorrectly) led me to understand that it was reasonably complicated.

Go has its own implementation that's packaged as part of the standard library, so we effectively get this for free. The advantage of simply letting a node advertise that it supports doing the brontide handshake over WS is that you can avoid needing to use a proxy all together.

[TheBlueMatt]

I feel like this would be a good candidate for a bLIP - I don't think we will reasonably consider this something that "most nodes should implement", but instead a totally-optional cool thing for those for whom its easy.

[rustyrussell]

I was originally going to add a new address type, but a single bit is cheaper. I'll see what I can do there, though....

[rustyrussell]

Is this better off done via a bridge instead? Last I heard there weren’t any decent websocket implementations that weren’t huge, which (maybe incorrectly) led me to understand that it was reasonably complicated. In either case, it seems if the only options are fresh code or huge dependency, it’s probably a bad idea for us to recommend users integrate it instead of simply using one of the websocket bridge services.

Yes, I was looking for implementations and had the same sinking feeling. But it's actually just modern software which sucks ass. This is a minimal proxy implementation which I made from reading the RFC; it's 350 well-commented lines:

https://github.com/ElementsProject/lightning/pull/4685/files#diff-5397f54245a40c2eb2457fe205631701dba00e4ea957793f8545674758b38603

[m-schmoock]

We have a clash here with https://github.com/lightningnetwork/lightning-rfc/pull/911 DNS descriptors. Which should have priority? We need to consider that an implementation is forced to ignore all descriptors after it encoutered the first unknown (not implemented / supported) type...

[m-schmoock]

@rustyrussell @TheBlueMatt Do we need to limit the number of allowed type 6 similar to https://github.com/lightning/bolts/pull/911/commits/3e88d0344d7dd210a7346648e0573b4805af33b0 as currently being discussed in https://github.com/lightning/bolts/pull/911 ?

[rustyrussell]

Plan is to update to DNS-record style (TLS!) instead....