Minutes interim-2023-satp-01: Tue 15:00
minutes-interim-2023-satp-01-202303141500-00

Claire: Someone needs to own the editing of the terminology doc. Alex and Denis
have volunteered. Thomas: we need to talk about session id and context id.
Happy to have that discussion. Denis: sessions defines transactions between two
gateways. Thomas: each session will be unique. Denis: instance of transfer
between two gateways. If we define the context we can include the session id
inside. Thomas: which one gets created first. Denis: When we initiate a
transfer, it can be a composite thing. context also contains the session id.
Thomas: if network one uses some variant to elect gateway Denis: What are the
things that we transfer. Including the session id. Thomas: need to avoid the
chicken and egg problem. Denis: Shared sequence diagram. goal is to start the
satp protocol. Work from source to target but also target to source. alice
wants to send something to bob. the client goes to the gateway and receives
back the context which was identified by the private key of the gateway. This
is the negotiation before satp starts. Claire: this is staging, showing the
events that could happen before the SAT protocol. Denis: the client goes to the
gw and the gw gives back a context and recognizes that it comes from a
particular gw. the transfer context belongs to gw 1. gateway binds to a
specific context. Rafael: whats the format of the context. Denis: some part of
the context should be standardized and include the session id. I initiate the
transfer and I create the session id and unique across all transfers. propose
have a transfer id that refers to the context. Rama: does the transfer context
tell the system that there is a gateway available. Denis: correct. this asset
is bound to this transfer context. One gateway that will do the transfer. Rama:
does transfer context expire. Denis: could be. the dlt can intentionally pull
out from the transfer at any moment. Claire: is this something we should solve.
Denis: All should be part of satp. Denis: I would like to initiate a transfer
and here's my context and you can begin the transfer whenever you want. there's
no effect on the dlt because there's no asset yet. when bob says I have a
context from a remote app. gateway 2 will say i am the other gateway and i'm
connecting with you and giving you the context you have request. two gw's then
connected and one can initiate sat. the client that goes back and say what
happened at the app level. Alexandru: we are assuming the clients are
different, it could be alice trying to transfer to themselves on another
network. Denis: you should know the other end even if alice is on another
network. we are having two parties that would like to transfer an asset and
should be explicit transfer from sender to receiver. Claire: we have assumed
clients that have a method to communicate with each other. dont want to spend
too much time before sat is initiated. the wg is based on a specific set of
criteria. need to focus on satp. we can then extend it to certain use cases.
Denis: not about extended but about not specified. some things that are not
specified. Claire: is that a suggestion that you would like to add to satp on
how clients identify each other? Denis: yes, what happens in the beginning. the
bootstrapping should be defined. Thomas: in the sat core, there are 3 api types
but we never talk about type one between app and gw. we focus on type 2 between
gateways. Rama: it puts the gw's in the appropriate state to start on satp. so
this bootstrapping should be part of satp scope. The outcome should be in scope
of satp charter. Denis: there are several steps necessary for satp to begin a
transfer. A lot of magic before the transfer. Thomas: are you happy if satp
core starts with an assuming that there is already a session id between
gateways. Denis: context or session something that defines the instance of the
transfer. If you see it as protocol steps there are preconditions of satp. what
is the output of state 0. Claire: that should meet the requirements of the
document. Denis: I'll use the mailing to describe stage 0. Claire: last call
that we have published our agenda for 116. Thomas: been asked if the interim's
time zone can be flip flopped. Claire: yes we can gain consensus on that. Rama:
is there something you need from me. Claire: any documents please send by
wednesday the 29th. the vocabulary and any draft to discuss. we have two hours
to meet in Yokohama.


Summary of outcomes:

-- The flows in both the Architecture draft and SATP-Core (ODAP) draft are now
the same as v16 of the color message flow diagrams in our GitHub repo
(https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbit.ly%2F3TeeaxA&data=05%7C01%7Cclaire.facer%40quant.network%7C803c0d64799d40e0024608db24a8e412%7C70500bf4d41742598a6eb7a550c6d120%7C0%7C0%7C638144080021059395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N6nD2jOHPJz6IU6xhPcpxUB1Peutc97LX9cNlNHXvcg%3D&reserved=0).
The SATP-Core message flows now include a Session-ID.

-- Two additional terms
were added (Session-ID and Context-ID), which the expectation that all these
terms will be collected into a separate Terminology draft.

-- Between gateways
G1 and G2 the message flow now use Lock Assertions and Receipt Assertion.

--
The group should consider an optional payload/body at the end the Lock
Assertions, as means for network-specific parameters or data to be communicated
to gateway G2.  The assumption is that G2 understands how to parse through the
payload.  Other gateways can ignore it if they are unable to parse & understand
the payload.