proposal to combine exchange and link status handling

[quartzjer]

There is growing complexity around handling exchange and link state independently and I believe they may be simpler when unified while also enabling the use of URI data, JWTs, bitcoin transactions, etc to accompany a handshake in order to validate it before processing.

This is just a stub as I explore what this looks like :)

[quartzjer]

Ok, this turned out even better than expected, and will be a pretty significant reduction in the complexity in both JS and C libs.

It also makes the terminology cleaner, a mesh and link are purely aggregate software concepts/interfaces, at the protocol level it's just handshakes, messages, exchanges.

Unless there's any big concerns I'd like to merge this and implement it yet this weekend :)

[fd]

LGTM.

My only concern is: How can a the receiver of multiple handshake messages/packets know it received all handshake message types? Some of the message/packets may have been dropped and as a result the receiver will never know about them.

Maybe the first handshake message should include a list of all the message types to expect. Then the receiver can buffer the messages until all types have been received (or a timeout is reached).

This should also make it easier to group all the messages together and pass them to the Application for verification/acceptance.

[quartzjer]

Upon receiving any additional message that is part of the handshake, the current set is given to the app. Only the app can recognize that the set may be incomplete and it should then just ignore it until it becomes complete, by the very nature of being a "silent" handshake (don't reveal yourself until valid) the recipient just has to re-validate any incomplete sets until they succeed, as the sender has to continue to re-send the entire set until it either times out or succeeds.

I'll expand on this some more, I'm excited about this approach! :)

[fd]

don't reveal yourself until valid

I didn't think about that. Does this CR mean that the link channel will be removed from the spec? If so, what would differenciate an exchange without a link/session from an exchange with a link/session?

[quartzjer]

That's right, the link is removed here, and the exchange/session/link are now all the same thing :)

[fd]

exchange/session/link are now all the same thing

Ah great. that will simply stuff significantly.

[quartzjer]

Finally getting to this this weekend, started the JS conversion and is going well :)

[quartzjer]

This went so well w/ the js conversion, extremely excited and happy about it, significant reduction in complexity. I'm going to merge this and then work on getting c up to date.