diff --git a/technical/2.3.-Swarm.md b/technical/2.3.-Swarm.md
index 3dcd8a885784b724bf66b626e6fe9a5513e1f39e..581d4333bc9e0f23e0f9dbae2fb41a8302561b76 100644
--- a/technical/2.3.-Swarm.md
+++ b/technical/2.3.-Swarm.md
@@ -202,6 +202,15 @@ or
 
 In this case, two conversations are generated. We don't want to remove messages from users or choose one conversation here. So, sometimes two 1:1 swarm between the same members will be shown. It will generate some bugs during the transition time (as we don't want to break API, the inferred conversation will be one of the two shown conversations, but for now it's "ok-ish", will be fixed when clients will fully handle conversationId for all APIs (calls, file transfer, etc)).
 
+### Note while syncing
+
+After accepting a conversation's request, there is a time the daemon needs to retrieve the distant repository. During this time, clients MUST show a syncing view to give informations to the user.
+Note, while syncing:
+
++ ConfigurationManager::getConversations() will return the conversation's id even while syncing
++ ConfigurationManager::conversationInfos() will return {{"syncing": "true"}} if syncing.
++ ConfigurationManager::getConversationMembers() will return a map of two URIs (the current account and the peer who sent the request)
+
 ## Conversations requests specification
 
 Conversations requests are represented by a **Map<String, String>** with the following keys:
@@ -333,6 +342,33 @@ Moreover editing messages will be possible! (`commit --fixup`)
  - CRLs
 ```
 
+
+## File transfer
+
+Swarm massively changes file transfer. Now, all the history is syncing, allowing all devices in the conversation to easily retrieve old files. This changes allow us to move from a logic where the sender pushed the file on other devices, via trying to connect to their devices (This was bad because not really resistant to connections changes/failures and needed a manual retry) to a logic where the sender allow other devices to download. Moreover, any device having the file can be the host for other devices, allowing to retrieve files even if the sender is not there.
+
+### Protocol
+
+The sender adds a new commit in the conversation with the following format:
+
+```
+value["tid"] = "RANDOMID";
+value["displayName"] = "DISPLAYNAME";
+value["totalSize"] = "SIZE OF THE FILE";
+value["sha3sum"] = "SHA3SUM OF THE FILE";
+value["type"] = "application/data-transfer+json";
+```
+
+and creates a link in `${data_path}/conversation_data/${conversation_id}/${file_id}` where `file_id=${commitid}_${value["tid"]}.${extension}`
+
+Then, the receiver can now download the files by contacting the devices hosting the file by opening a channel with `name="data-transfer://" + conversationId + "/" + currentDeviceId() + "/" + fileId` and store the info that the file is waiting in `${data_path}/conversation_data/${conversation_id}/waiting`
+
+The device receiving the connection will accepts the channel by verifying if the file can be sent (if sha3sum is correct and if file exists). The receiver will keep the first opened channel, close the others and write into a file (with the same path as the sender: `${data_path}/conversation_data/${conversation_id}/${file_id}`) all incoming data.
+
+When the transfer is finished or the channel closed, the sha3sum is verified to validate that the file is correct (else it's deleted). If valid, the file will be removed from the waiting.
+
+In case of failure, when a device of the conversation will be back online, we will ask for all waiting files by the same way.
+
 ### Attacks?
 
 + Avoid git bombs
@@ -370,10 +406,6 @@ https://www.hindawi.com/journals/complexity/2018/9104720/. But need calculations
 
 Note: to optimize the socket numbers, a socket will be given by a **ConnectionManager** to get multiplexed sockets with a given hash. This means that if we need to transmit several files and chat with someone, only one socket will be used.
 
-## File transfer (libtorrent?)
-
-**TODO**
-
 ## Network activity
 
 ### Process to invite someone