The same structure is used to receive files, but the method changes a bit:
1. The `JamiAccount` class is used to receives messages from the DHT, because the first thing received will be the DHT request.
2. Then, this message is given to `DhtPeerConnector: onRequestMessage()` through the eventLoop.
2. Then, this message is given to `DhtPeerConnector: onRequestMessage()` through the eventLoop.
3. The `DhtPeerConnector::Impl::answerToRequest` will try to connect to the TURN server (if not connected) and initialize the ICE transport. This method open 2 control connections to a TURN server (one to authorize IPv4 peers, another one for IPv6 peers, due to **RFC 6156**) if it's not already open and permit Peer public addresses to connect. Then, if the SDP received doesn't contains ICE candidates, will use the TURN and craft the SDP answer to wait for the peer. If the SDP contains ICE candidates, the method will try to negotiate the link (or fallback on the TURN) and then answer the SDP (with ICE candidates or not).
4. Once the links are ready, like the sender, a TLS link is negotiated and given to the `PeerConnection` given to the `IncomingFileTransfer` as an input. The headers of the file will come and the client is now able to accept or cancel the transfer.
...
...
@@ -135,7 +135,7 @@ Note that the stack for the file transfer is:
@@ -9,7 +9,7 @@ A *swarm* is a group able to discuss without any central authority in a resilien
So, the *swarm* is defined by:
1. Ability to split and merge following the connectivity.
2. Syncing of the history. Anyone must be able to send a message to the whole group.
3. No central authority. Can't rely on any server.
3. No central authority. Can not rely on any server.
4. Non-repudiation. Devices must be able to verify old messages' validity and to replay the whole history.
5. PFS on the transport. Storage is managed by the device.
...
...
@@ -124,7 +124,7 @@ Note2: If a fetch is too big, it's not done (**TODO**)
*Alice, Bob, Carla, Denys are in a swarm. Alice bans Denys*
This is one of the most difficult scenarios in our context. Without central authority we can't trust:
This is one of the most difficult scenarios in our context. Without central authority we can not trust:
1. Timestamps of generated commits
2. Conflicts with banned devices. If multiple admin devices are present and if Alice can speak with Bob but not Denys and Carla; Carla can speak with Denys; Denys bans Alice, Alice bans Denys, what will be the state when the 4 members will merge the conversations.
...
...
@@ -135,7 +135,7 @@ Similar systems (with distributed group systems) are not so much, but these are
+[mpOTR doesn't define how to ban someone](https://www.cypherpunks.ca/~iang/pubs/mpotr.pdf)
+ Signal, without any central server for group chat (EDIT: they recently change that point), doesn't give the ability to ban someone from a group.
This voting system needs a human action to ban someone or must be based on the CRLs info from the repository (because we can't trust external CRLs)
This voting system needs a human action to ban someone or must be based on the CRLs info from the repository (because we can not trust external CRLs)
### Remove a device from a conversation
...
...
@@ -170,7 +170,7 @@ Note: Alice MUST be admins to vote
## How to specify a mode
Modes can't be changed through time. Or it's another conversation. So, this data is stored in the initial commit message.
Modes can not be changed through time. Or it's another conversation. So, this data is stored in the initial commit message.
The commit message will be the following:
...
...
@@ -366,7 +366,7 @@ Each conversation will be a git repository. This choice is motivated by:
#### Limits
History can't be deleted. To delete a conversation, the device has to leave the conversation and create another one.
History can not be deleted. To delete a conversation, the device has to leave the conversation and create another one.
However, non-permanent messages (like messages readable only for some minutes) can be sent via a special message via the DRT (like Typing or Read notifications).
...
...
@@ -575,7 +575,7 @@ A certificate for a group that sign user with a flag for a role. Adding or revok
Group chat can be based on the same work we already have for multi-devices (but here, with a group certificate). Problems to solve:
1. History sync. This needs to move the database from the client into the daemon.
2. If nobody is connected, the synchronization can't be done, and the person will never see the conversation
2. If nobody is connected, the synchronization can not be done, and the person will never see the conversation