Message Tx/Rx API response could be augmented

[robotpie]

In the Message Tx/Rx API:
The response is simply "200 OK" if the message is successfully processed by the relevant DLT channel.

However, it would be potentially useful to return a unique network identifier to identify the DLT channel as well as transaction identifier in order for the receiver or an eventual auditor to be able to independently verify the transaction on the DLT that was involved.

The network identifier is more challenging as it necessitates a (centralized?) table of DLT channels to be maintained, or some methodical way of enumerating them as needed. The transaction identifier could be in the DLT channel's native format.

[monkeypants]

Do you mean here https://edi3.org/specs/edi3-icl/master/#channel-txrx-api ?

We got some staunch negative feedback about the idea of a global routing table (list of DLT channels). My feeling is that it should be possible, but evidently that's not a universal view. I personally think it might be possible to have a meta-ledger where Countries publish their bilateral/multilateral channels (including channel life-cycle management, notarising checkpoint blocks, etc), however it might also be possible to achieve the same outcomes without any kind of global overview. In the interests of keeping things simple, that idea is not in the spec at this stage.

So, network namespaces are challenging. I agree that if we had the network namespace, then the native format transaction ID would probably be adequate (for all the DLT's I've met).

There is a view that the network is actually none of the sender's business. The sender sees a B2G transaction, and the channel routing happens in the G2G domain. End to end, it's a B2G2G2B flow, and each B only sees their G (plus the payload). How two countries agree to share data may or may not be something they each reveal to their constituencies.

However, there is a good reason for the sender to have an ID that uniquely identifies the message. How else could they subscribe to events (PubSub infrastructure) to learn about changes to deliver status (etc)? I don't think we should block the POST until the API is confident the transaction has gone through.

One option would be for the API itself to assign a local TX identifier. Kind of like a unique receipt: "thanks for the message, henceforth we shall currently reffer to this message as XXXXX". This message ID could be assigned by the sending country and injected into the payload, but not accepted in the B2G interface. If you knew the channel and were able to scan it's ledger, you could still use this for audit purpose. Do you think that would work for your case?

[monkeypants]

BTW, I cross posted this to the ICL repo because I think it belongs there (edi3/edi3-igl#29), sorry I might have replied sooner but I didn't find it until tonight.