feat: add offline adr #28
Conversation
dhemutton
force-pushed
the
feat/add-offline-verification
branch
from
5fa68a6
to
aa5dd0e
Compare
dhemutton
force-pushed
the
feat/add-offline-verification
branch
from
aa5dd0e
to
521a158
Compare
| const qrCodeObj = decodeQrCode(doc.rawDocument.links.self.href); | ||
| const uri = qrCodeObj.payload.uri; | ||
|
|
||
| return axios({ |
There was a problem hiding this comment.
why does push the doc to storage is needed for ? (I'm sorry I cant figure the corect way for this question, can help my englosh ? XD)
For preview ?
There was a problem hiding this comment.
Ohh this is for the QRcode verification of a document! The document creator automatically does this for us so that when we click a link we can easily access the document and send it to the verifier.
offline_verifying.md
Outdated
| When the child window is ready, it will send a SYN message to the parent through: | ||
|
|
||
| ```js | ||
| window.opener.postMessage({ messageType: "SYN" }); |
There was a problem hiding this comment.
Will be useful to use something like state action pattern to transmit information. An example:
{
type: "READY"
}{
type: "LOAD_DOCUMENT",
payload: { document }
}This will following the universal actions quite closely too (https://github.com/Open-Attestation/adr/blob/master/universal_actions.md)
offline_verifying.md
Outdated
| When the parent receives the SYN message, he will send out a SYNACK message to its child: | ||
|
|
||
| ```js | ||
| if (event.data.messageType == "SYN") { | ||
| childWin.postMessage({ messageType: "SYNACK" }); | ||
| } | ||
| ``` | ||
|
|
||
| When the child receives the SYNACK message, he will send out an ACK message back to its parent: | ||
|
|
||
| ```js | ||
| if (event.data.messageType == "SYNACK") { | ||
| window.opener.postMessage({ messageType: "ACK" }); | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Understand that this is borrowed from the TCP/IP handshake, I then ask myself the question what was the value of a 3 way handshare.
Turns out the value of a 3-way handshake is to establish the initial sequence number (ISN) which is random in TCP/IP situation. And that a 2 way handshake will only guarantee the ISN reciept of one party. See discussion here: https://networkengineering.stackexchange.com/questions/24068/why-do-we-need-a-3-way-handshake-why-not-just-2-way.
Comparing it to this situation I dont see a 3 way handshake being necessary because there is no need for a sequence number for packet re-assembly at the recipient side, and that we dont even break our message in multiple separate packets.
So, I think we can drop the 3 way handshake in favor of a more direct and simpler architecture where the sequence will look like:
- Child sends "READY"
- Parent sends "LOAD_DOCUMENT" with payload
Open a .tt file in another browser tab offline (without uploading to backend first).
This is a research piece to see if it's possible for one to open a .tt file which is loaded in the current application in another tab without uploading it temporarily to a server (user may not have consented to an upload).
This PR is related to this story.