Skip to content
Snippets Groups Projects
Commit 2a8a9369 authored by Sébastien Blin's avatar Sébastien Blin
Browse files

faq: add common answers for android modes

Change-Id: Idda8a419bd352b6655a485e8a5033c44a3b2b8ba
parent 86a2bddb
No related branches found
No related tags found
No related merge requests found
......@@ -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.
......
......@@ -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
......
......@@ -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.
......
......@@ -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.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment