Transport layer proposal

[ZmnSCPxj-jr]

No description provided.

[ZmnSCPxj-jr]

TODO: What happens if the client disconnects before the LSP can respond to a request?

[ZmnSCPxj-jr]

Added text on what happens if connection lost.

[ZmnSCPxj-jr]

Added section on implementing LSPS0, also changed how disconnections / reconnections should be handled.

[ZmnSCPxj-jr]

@johncantrell97 taught me how feature bits can be added for LDK-based LSP software. Anyone up for writing how to implement LSPS0 for LND?

[SeverinAlexB]

TODO: What happens if the client disconnects before the LSP can respond to a request?

Client or LSP can just ignore the message in this case IMO.

[SeverinAlexB]

I pinged LL on the implementation timeline for setting custom feature bits.

[ZmnSCPxj-jr]

No response from LL; also current LSPS0 requires init feature bits, but it seems only custom node_announcement feature bits are planned.

[SeverinAlexB]

@carlaKC responded, she is working on it including the init feature bits. So from a compatibility POV, this shouldn't be an issue. Thx Carla 🙏

[ZmnSCPxj-jr]

@SeverinAlexB wrote:

Client or LSP can just ignore the message in this case IMO.

What I wanted to think on was the id field; if you are doing a naive counter-based id you could potentially reuse it on restart. I have since added a section requiring that clients use high-entropy id fields so that if it cannot remember the previous id it could just ignore it, since a high-entropy id field is unlikely to be reused.

[ZmnSCPxj-jr]

Recent changes: fixed typos reported by @tnull, added short section on implementation for LND.

[SeverinAlexB]

Adding this for completion of the gzip discussion:

gzip/zip can cause so called zip bombs. A small zipped file can bloat up to terabytes of data. This was the issue LN devs run into previously according to Christian Decker. This is of course a problem. In the unlikely case we need compression in the future, we can prevent such bombs by adding an uncompressed payload_bytes field to the message that stops the decompression as soon as decompressed_data > payload_bytes.

[SeverinAlexB]

I did a second review. All in all great work @ZmnSCPxj-jr. I got some open questions about error messages but otherwise this is an ACK.

[SeverinAlexB]

Complete ACK from my side.

[ZmnSCPxj-jr]

Added "Status" field, as well as specification of this "Status" field, as per @SeverinAlexB suggestion during the meeting.

[tnull]

Generally looks good to me!

Excuse the delay, finally came around to have a closer look. I have only a few comments/questions that would be nice to clarify, but nothing major really.

I also did some proofreading and added a ton of wording suggestions/nits, feel free to regard anything with the "nit:" prefix as non-blocking suggestions, i.e., feel free to ignore if you don't agree.

[ZmnSCPxj-jr]

Modified as per @tnull feedback.

[ZmnSCPxj-jr]

Changes: Added rationale for n.lsps namespace, added short text on LSPS specification versioning.

[tnull]

Changes LGTM.

I think I am ACK on this, provided the larger group comes to alignment on using the JSON-RPC approach.

[ZmnSCPxj-jr]

Changes: Describe how other LSPS specifications should design their APIs so they are resilient against the client crashing and aborting the flow or process, explicitly state that feature bit 729 be set if LSP supports LSPS0 at minimum.

[ZmnSCPxj-jr]

Changes: remove n. prefix for notifications, give justification for the client not bothering with 37913 messages to the LSP if the LSP gives a bad message until it reconnection since the reconnection might mean the LSP has been bugfixed.

[ZmnSCPxj-jr]

Change: remove comment param of listprotocols.