search

derecalliance / protobufs

The format of DeRec messages.
Apache License 2.0
2 stars 0 forks source link

Add `transportUri` to the `PairRequestMessage` protobuf #25

Open zanctor opened 6 months ago

zanctor commented 6 months ago

Currently, a pairing initiator sends a pairing request to a transportUri in the ContactMessage, and tries listening to a response on the same transport. However, it may be impossible to listen to messages on other party's transport in some cases (HTTP/S endpoint, email, etc).

Thus I suggest adding the initiator's transportUri to the PairRequestMessage protobuf, so a responder will know where to send messages. This will greatly improve interoperability since both sides will only need to send messages to communicate.

jorabin commented 6 months ago

In the TBB use case, we anticipate that the initiator will always be the sharer and that that HTTPS will be used, so there isn't a requirement for this as far as we are concerned.

However, in the general case I can see that it is needed if you can't use aspects of the incoming message/connection to send a reply.

I haven't thought much about whether the transport needs to ensure in-sequence delivery, or whether it needs to provide a way to correlate responses to requests, so while not directly part of this issue, I think worth stating what assumptions there are about the properties of the transport including whether the response address is implicit in the request.

zanctor commented 6 months ago

@jorabin, even in TBB case, how is the helper supposed to know where to send a pairing response and other types of responses? A sharer won't be able to listen to the HTTPS endpoint.

jorabin commented 6 months ago

Helper sends it as a reply on the same HTTPS connection as the request arrived on. i.e. Sharer initiates the connection and receives the reply on the same connection it initiated.

zanctor commented 6 months ago

Ah, I see. A typical HTTP request-response sequence. But this won't work for the P2P implementation, where the difference in time between a request and a response might be in days.

zanctor commented 6 months ago

We will implement this to be able to establish the push-based communication, which is required for the P2P case.

lbaird commented 5 months ago

I agree, the pairing request should include the URI for replies. If the original URI is just an https address, then the reply URI can be null. But if they are communicating through some store-and-forward server system, then both sides need to give their address.