Mailbox-Protocol.md

@@ -23,8 +23,6 @@ Depending on the TYPE, a Request may have a response.
 ### OFFER
 An OFFER request indicates that the connected peer wants to send a chunked file to the recipient. 
 
-+ **RESPONSE:** yes
-
 + **BODY:** [FILE_ID, NUM_CHUNKS ,CONTACT_ID]
   + **FILE_ID:** *[BDF raw]* A unique identifier which specifies the offered file. *NOTE: The identifier is the encrypted stream's sha256 sum and is also used to verify the file*
   
@@ -32,15 +30,28 @@ An OFFER request indicates that the connected peer wants to send a chunked file
 
   + **CONTACT_ID:** *[BDF long/null]* Either `Null`, if the contact's id is identified by the connection (A contact of the owner connecting to the owner's mailbox is only allowed to store their own streams) or `Integer` to indicate for which id the stream should be stored (Used by the owner storing streams for contacts without their own mailbox) 
 
++ **RESPONSE:** yes
+  + **BODY:** [MISSING_CHUNKS]
+    + **MISSING_CHUNKS:** *[list of BDF long]* Missing chunk indices
+
 ### CHUNK
 A CHUNK request contains a chunk of a previously *offered* file. *Note: Since the OFFER request already specifies the contact's Id, we do add the contact's id to the CHUNK request*
 
-+ **RESPONSE:** yes
-
 + **BODY:** [CHUNK_INDEX, CHUNK]
   + **CHUNK_INDEX:** *[BDF long]* Defines the chunk's index in the chunked file
   + **CHUNK:** *[BDF raw]* chunk 
 
++ **RESPONSE:** yes (Functions as ACK)
+  + **BODY:** ``null`
+
+### CHUNK_FIN
+A CHUNK_FIN request indicates that the last ACK for the given file id's chunk requests has been received. The recipient is then able to confidently delete the file. *NOTE: Without the CHUNK_FIN request a file could theoretically be resent if the last ACK request is lost.*
+
++ **BODY:** [FILE_ID]
+  + **FILE_ID:** *[BDF raw]* file id 
+
++ **RESPONSE:** no
+
 ### SYNC
 SYNC requests are used to carry [BSP](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md) messages between the mailbox and the connected client.