piegames
piegames
Hm, do you have an example of a protocol that might make use of that close behavior on the happy path? I understand your proposal, but it adds some significant...
Actually, Dilated file transfer can use that same mechanism on the Dilation level: closing the control channel will already do the closing/closed dance and then once the control channel is...
> cases where we've never actually succeeded at opening a Dilation channel -- which may never succeed That's why I was specifically talking about the happy path. On the unhappy...
Could we make the feature optional so that applications may use either depending on what they need? I'd be in for the change of giving the current CLOSE signal stronger...
When the send side abandons before ever seeing the other side and then the other side joins, it will be stuck currently. This could be avoided. Probably also helps fixing...
Actually I think there might be some issues about a `close` phase that we need to think through first: - All phases except `pake` are encrypted, but a `close` message...
Going back to this, I'd like to explore a solution that works with the `close` message some more. And I think we can make it work so that the mailbox...
This is a tricky one, especially because the relay should also support Dilation which as a different handshake. It's no big deal we can just implement both, but I'd really...
Honestly, I am slightly reconsidering my position on the "translate the framing" problem due to this. Maybe having a redundant length field and a bit more complexity on the client...
Whichever way I look at it, if we want to keep the current behavior and a simple relay server then clients will have to implement some logic to extract framed...