Websocket address type: attempt 2

[benthecarman]

#891 seemed to be dead and does not properly support things like TLS.

This is a re-attempt to bring back the proposal while addressing the concerns. It is mostly the same as @rustyrussell's but changed it so be the same as the DNS hostname address descriptor so things like TLS can be supported and doesn't require scanning all the other network addresses.

[TheBlueMatt]

A few things we need to consider here: (a) We really need to support wss as well, to do this we need a hostname to check the TLS cert against, (b) if we weren't supporting wss we'd probably not want a hostname at all here but rather simply a feature flag indicating that WS is supported. These two goals are somewhat contradictory, sadly, so I'm not sure what the right design is, maybe a feature flag indicating websockets are supported for all connection modes but also a wss hostname type? Or maybe a ws hostname type that has a secure bit in it? I'm open to either, but we need to support wss somehow.

[rustyrussell]

My plan was to abandon #891 altogether. Allowing a websocket is cool, advertising it less so. In particular, I have no plans to support wss in CLN, so it will be hard to get two interoperable implementations. And in fact a standalone connector to Apache / nginx probably makes more sense than existing implementations doing it.

I have a patch (missed this release, will be in next) to drop advertising the websocket.

[TheBlueMatt]

Are there popularly available wrappers which map websockets to TCP? IIUC the majority of relevant wrappers just apply TLS over unencrypted websockets, so the node software also needs to support websockets (I assume you mean you're going to stop announcing, but keep the websocket code itself?)

I do disagree that we shouldn't announce wss - if a node wants to accept connections from browser nodes (or browser extension wallets, which are a common request), they have to put the hostname they accept TLS on somewhere, and imo it might as well be in the gossip.