diff --git a/developer/file-transfer.md b/developer/file-transfer.md index 6d7d9cba28ca2095322c07a28e04dc583ebed96a..8b33d138213b89d498b6f44ade3739c4e2bc8a62 100644 --- a/developer/file-transfer.md +++ b/developer/file-transfer.md @@ -86,7 +86,7 @@ The following method is used: 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: ``` +-----------+----------------+-----------------------+ + STUN + TLS data + TLS data + -+-----------+----------------+-----------------------+ ++-----------+----------------+-----------------------+ + RFC 4571 (RTP) + RFC 6062 (TURN TCP) + +----------------------------+-----------------------+ + TCP + @@ -196,7 +196,7 @@ incorrect) Future ------ -For now, if a file transfer fails when ongoing, the sender can't resume +For now, if a file transfer fails when ongoing, the sender can not resume the transfer and must relaunch the whole transfer. In the future, there will be a retry button for resuming the transfer. diff --git a/developer/swarm.md b/developer/swarm.md index 79e45608d58b328091059c6aeb043ec85283943d..4f70b95cc81c476edd4b54d3de58b4eed5cfa700 100644 --- a/developer/swarm.md +++ b/developer/swarm.md @@ -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 ### Another dedicated DHT diff --git a/user/bug-report-guide.md b/user/bug-report-guide.md index 85f8ebe469abb59d1bc8fad609ec75de50787a70..0dd64a2e52452ffd2f089c22cd5d785728999d30 100644 --- a/user/bug-report-guide.md +++ b/user/bug-report-guide.md @@ -53,7 +53,7 @@ one already. - If you can reproduce occasionally, but not after following specific steps, please provide additional information about the issue to help others understand and try to reproduce it. -- If you can't reproduce the problem, there may be little chance of it +- If you can not reproduce the problem, there may be little chance of it being reasonably fixable. If you do report it, please try your best to provide as much information/clues about its occurrence as possible. diff --git a/user/faq.rst b/user/faq.rst index aea8e8ed97ec4f06b7d0d5802e97aa1b2cac41f0..afbbd86c65d0271d2522b1aef847f196743241fe 100644 --- a/user/faq.rst +++ b/user/faq.rst @@ -34,7 +34,7 @@ Please see the :doc:`bug-report-guide`. What makes Jami different from other communication platforms? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Jami doesn't work like most communication platforms because it is +Jami does not work like most communication platforms because it is *distributed*: .. image:: ../_static/network-topology.svg @@ -318,7 +318,7 @@ There are two ways to back up your account: Can I retrieve my username without my keys? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If you used the default name server at ``ns.jami.net``, **you can't**. +If you used the default name server at ``ns.jami.net``, **you can not**. There is no way to prove it's your username without your key. If you use a different name server, there may be a way to move a @@ -331,7 +331,7 @@ For more information about name servers, see Can I recover my account if I forget my password? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -No. There can't be a traditional account recovery process; you are +No. There can not be a traditional account recovery process; you are the only person with access to your data. If you are worried about forgetting your password, please use a password manager. @@ -424,7 +424,7 @@ The default one in Jami is ``bootstrap.jami.net``. What is a TURN server? What is STUN? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A TURN server is a relay, and is generally used when two peers can't +A TURN server is a relay, and is generally used when two peers can not contact to each other due to some firewall restriction, have NAT without any opened port, and no IPv6. @@ -440,6 +440,36 @@ your information to you. Thus, it is the server that will be active on the DHT and will participate in the network, and no longer the target device. Multiple devices can register on the same DHT proxy. +Generally, to transfer data between two peers, there are 3 steps: + +1. Exchange candidates (IPs) via the DHT +2. Negotiate the best p2p channel between the peers +3. Transfer data on this socket. + +The DHT is only used for the first step. + +What if I disable the DHT proxy on Android and what about push notifications? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +There is basically 3 modes on how to use the Android application: + ++ With push notifications (DHT proxy must be enabled). This mode supports +notifications for Android (via Google/Firebase, and soon Unified Push or Apple/APN). +This decrease battery usage, by removing the sync needed with the DHT and without +any socket always alive. ++ Without push notifications but with DHT proxy enabled. This avoids the application + synchronizing with other nodes, but "Run in background" MUST be enabled to avoid the + operating system killing the application. ++ Without DHT proxy. In this case, "Run in background" MUST be enabled to avoid the operating +system killing the application. The application will synchronize with the other DHT nodes. + +I still have issues with the Android application even if battery optimization is disabled +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Please read https://dontkillmyapp.com for more details. +If it does not solve your issue, you can open a bug report (ideally with a scenario to help +us to reproduce and/or logs). + How does the username registration service work? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -523,7 +553,7 @@ mandatory to avoid IP leaking. Moreover, even if it's my answer, you can choose to not trust my answer and check the code, or use wireshark or other tools. Generally, I (and as far as I know most other Jami developers) use the -first scenario (sometimes the second one), and we surely can't test +first scenario (sometimes the second one), and we surely can not test all the possible networks configurations we would like to, so if you discover a bug, please :doc:`open an issue <bug-report-guide>`. @@ -600,7 +630,7 @@ Tor - Send a message -Tor basically doesn't supports UDP. This means that you can't use your +Tor basically does not supports UDP. This means that you can not use your DHT node locally, you MUST use a DHTProxy. That proxy will see the Exit node. @@ -649,7 +679,7 @@ Note that medias will not work cause it only supports UDP. So for ufw, we recommend running ``sudo ufw default allow outgoing``. -For now, you can't specify a specific range to configure ports used by +For now, you can not specify a specific range to configure ports used by Jami. The inbound traffic can be controlled without issue, Jami should work and can use a TURN server if needed.