diff --git a/developer/choosing-crf-value-for-encoder.md b/developer/going-further/choosing-crf-value-for-encoder.md
similarity index 100%
rename from developer/choosing-crf-value-for-encoder.md
rename to developer/going-further/choosing-crf-value-for-encoder.md
diff --git a/developer/delivery-status.md b/developer/going-further/delivery-status.md
similarity index 100%
rename from developer/delivery-status.md
rename to developer/going-further/delivery-status.md
diff --git a/developer/images/choosing-crf-1080p-1.5mbps-crf22.png b/developer/going-further/images/choosing-crf-1080p-1.5mbps-crf22.png
similarity index 100%
rename from developer/images/choosing-crf-1080p-1.5mbps-crf22.png
rename to developer/going-further/images/choosing-crf-1080p-1.5mbps-crf22.png
diff --git a/developer/images/choosing-crf-1080p-1.5mbps-crf30.png b/developer/going-further/images/choosing-crf-1080p-1.5mbps-crf30.png
similarity index 100%
rename from developer/images/choosing-crf-1080p-1.5mbps-crf30.png
rename to developer/going-further/images/choosing-crf-1080p-1.5mbps-crf30.png
diff --git a/developer/images/choosing-crf-1080p-300kbps-crf28.png b/developer/going-further/images/choosing-crf-1080p-300kbps-crf28.png
similarity index 100%
rename from developer/images/choosing-crf-1080p-300kbps-crf28.png
rename to developer/going-further/images/choosing-crf-1080p-300kbps-crf28.png
diff --git a/developer/images/choosing-crf-1080p-300kbps-crf38.png b/developer/going-further/images/choosing-crf-1080p-300kbps-crf38.png
similarity index 100%
rename from developer/images/choosing-crf-1080p-300kbps-crf38.png
rename to developer/going-further/images/choosing-crf-1080p-300kbps-crf38.png
diff --git a/developer/images/choosing-crf-1080p-6mbps-crf17.png b/developer/going-further/images/choosing-crf-1080p-6mbps-crf17.png
similarity index 100%
rename from developer/images/choosing-crf-1080p-6mbps-crf17.png
rename to developer/going-further/images/choosing-crf-1080p-6mbps-crf17.png
diff --git a/developer/images/choosing-crf-1080p-6mbps-crf23.png b/developer/going-further/images/choosing-crf-1080p-6mbps-crf23.png
similarity index 100%
rename from developer/images/choosing-crf-1080p-6mbps-crf23.png
rename to developer/going-further/images/choosing-crf-1080p-6mbps-crf23.png
diff --git a/developer/images/choosing-crf-436p-1.5mbps-crf22.png b/developer/going-further/images/choosing-crf-436p-1.5mbps-crf22.png
similarity index 100%
rename from developer/images/choosing-crf-436p-1.5mbps-crf22.png
rename to developer/going-further/images/choosing-crf-436p-1.5mbps-crf22.png
diff --git a/developer/images/choosing-crf-436p-1.5mbps-crf30.png b/developer/going-further/images/choosing-crf-436p-1.5mbps-crf30.png
similarity index 100%
rename from developer/images/choosing-crf-436p-1.5mbps-crf30.png
rename to developer/going-further/images/choosing-crf-436p-1.5mbps-crf30.png
diff --git a/developer/images/choosing-crf-436p-300kbps-crf28.png b/developer/going-further/images/choosing-crf-436p-300kbps-crf28.png
similarity index 100%
rename from developer/images/choosing-crf-436p-300kbps-crf28.png
rename to developer/going-further/images/choosing-crf-436p-300kbps-crf28.png
diff --git a/developer/images/choosing-crf-436p-300kbps-crf38.png b/developer/going-further/images/choosing-crf-436p-300kbps-crf38.png
similarity index 100%
rename from developer/images/choosing-crf-436p-300kbps-crf38.png
rename to developer/going-further/images/choosing-crf-436p-300kbps-crf38.png
diff --git a/developer/images/choosing-crf-436p-6mbps-crf17.png b/developer/going-further/images/choosing-crf-436p-6mbps-crf17.png
similarity index 100%
rename from developer/images/choosing-crf-436p-6mbps-crf17.png
rename to developer/going-further/images/choosing-crf-436p-6mbps-crf17.png
diff --git a/developer/images/choosing-crf-436p-6mbps-crf23.png b/developer/going-further/images/choosing-crf-436p-6mbps-crf23.png
similarity index 100%
rename from developer/images/choosing-crf-436p-6mbps-crf23.png
rename to developer/going-further/images/choosing-crf-436p-6mbps-crf23.png
diff --git a/developer/images/choosing-crf-720p-1.5mbps-crf22.png b/developer/going-further/images/choosing-crf-720p-1.5mbps-crf22.png
similarity index 100%
rename from developer/images/choosing-crf-720p-1.5mbps-crf22.png
rename to developer/going-further/images/choosing-crf-720p-1.5mbps-crf22.png
diff --git a/developer/images/choosing-crf-720p-1.5mbps-crf30.png b/developer/going-further/images/choosing-crf-720p-1.5mbps-crf30.png
similarity index 100%
rename from developer/images/choosing-crf-720p-1.5mbps-crf30.png
rename to developer/going-further/images/choosing-crf-720p-1.5mbps-crf30.png
diff --git a/developer/images/choosing-crf-720p-300kbps-crf28.png b/developer/going-further/images/choosing-crf-720p-300kbps-crf28.png
similarity index 100%
rename from developer/images/choosing-crf-720p-300kbps-crf28.png
rename to developer/going-further/images/choosing-crf-720p-300kbps-crf28.png
diff --git a/developer/images/choosing-crf-720p-300kbps-crf38.png b/developer/going-further/images/choosing-crf-720p-300kbps-crf38.png
similarity index 100%
rename from developer/images/choosing-crf-720p-300kbps-crf38.png
rename to developer/going-further/images/choosing-crf-720p-300kbps-crf38.png
diff --git a/developer/images/choosing-crf-720p-6mbps-crf17.png b/developer/going-further/images/choosing-crf-720p-6mbps-crf17.png
similarity index 100%
rename from developer/images/choosing-crf-720p-6mbps-crf17.png
rename to developer/going-further/images/choosing-crf-720p-6mbps-crf17.png
diff --git a/developer/images/choosing-crf-720p-6mbps-crf23.png b/developer/going-further/images/choosing-crf-720p-6mbps-crf23.png
similarity index 100%
rename from developer/images/choosing-crf-720p-6mbps-crf23.png
rename to developer/going-further/images/choosing-crf-720p-6mbps-crf23.png
diff --git a/developer/important-rfcs.md b/developer/going-further/important-rfcs.md
similarity index 100%
rename from developer/important-rfcs.md
rename to developer/going-further/important-rfcs.md
diff --git a/developer/going-further/index.rst b/developer/going-further/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..984d39aa61b0792e607481445081e4024afc2b83
--- /dev/null
+++ b/developer/going-further/index.rst
@@ -0,0 +1,16 @@
+##############
+Going further
+##############
+
+This part of the documentation is dedicated to developers who want to dig
+some more specific topics about Jami.
+
+.. toctree::
+ :maxdepth: 1
+
+ choosing-crf-value-for-encoder
+ delivery-status
+ important-rfcs
+ location-sharing
+ message-displayed-status
+ setting-up-your-own-turn-server
\ No newline at end of file
diff --git a/developer/location-sharing.md b/developer/going-further/location-sharing.md
similarity index 100%
rename from developer/location-sharing.md
rename to developer/going-further/location-sharing.md
diff --git a/developer/message-displayed-status.md b/developer/going-further/message-displayed-status.md
similarity index 100%
rename from developer/message-displayed-status.md
rename to developer/going-further/message-displayed-status.md
diff --git a/developer/setting-up-your-own-turn-server.md b/developer/going-further/setting-up-your-own-turn-server.md
similarity index 100%
rename from developer/setting-up-your-own-turn-server.md
rename to developer/going-further/setting-up-your-own-turn-server.md
diff --git a/developer/index.rst b/developer/index.rst
index 1ce0bf600862f93eaf78314630c5c119d166006d..05068de2f7942d81708fe8bc7df5582fa1db4afa 100644
--- a/developer/index.rst
+++ b/developer/index.rst
@@ -10,39 +10,8 @@ designed and how its various parts work together.
.. toctree::
:maxdepth: 1
- introduction
- apis-of-jami
- account-management
- contact-management
- design-process
- swarm
- drt
- calls
- file-transfer
- message-displayed-status
- setting-up-your-own-turn-server
- synchronizing-profiles
- submitting-your-first-patch
- debugging-tools
feature-requests
- connection-manager
- delivery-status
- calls-in-swarm
- conference-protocol
- synchronization-protocol
- important-rfcs
- improving-quality-of-jami
- libjamiclient-documentation
- name-server-protocol
- protocol
- release-process
- technical-overview
- jami-identifiers
- choosing-crf-value-for-encoder
- banned-contacts
- coding-style
- qt-qml-coding-style
- qt-qml-testing-tools
- working-with-gerrit
- working-with-gerrit-fr
- location-sharing
+ new-developers/index
+ jami-concepts/index
+ going-further/index
+ processes/index
\ No newline at end of file
diff --git a/developer/introduction.md b/developer/introduction.md
deleted file mode 100644
index 1921fbc6a535cab5ed3e64cb7b8f1dd2631df8f2..0000000000000000000000000000000000000000
--- a/developer/introduction.md
+++ /dev/null
@@ -1,63 +0,0 @@
-Introduction
-============
-
-Greetings! In the developer manual of Jami, you will learn about how
-Jami works from the high level, to the low, with some examples.
-
-## Table of contents
-
-1. {doc}`apis-of-jami`
-2. Basic features
- 1. {doc}`account-management`
- 2. {doc}`contact-management`
- 3. {doc}`swarm`
- 3. {doc}`calls`
- 5. {doc}`file-transfer` (deprecated; see {doc}`swarm`)
- 6. {doc}`message-displayed-status`
-
-3. Advanced features
- 1. Manage audio/videos
- 2. Call recording
- 3. [The push notifications system](https://github.com/savoirfairelinux/opendht/wiki/Push-notifications-support)
- 4. What is a DHTProxy
- 5. Supporting SIP
- 6. {doc}`setting-up-your-own-turn-server`
- 8. {doc}`synchronizing-profiles`
-
-4. {doc}`../contribute`
- 1. {doc}`Build instructions <../build/building>`
- 2. {doc}`submitting-your-first-patch`
- 3. {doc}`feature-requests`
-
-5. Group chats in details
- 1. Description
- 2. {doc}`connection-manager`
- 3. DRT
- 4. {doc}`calls-in-swarm`
-
-6. Drafts
- 1. {doc}`conference-protocol`
- 2. {doc}`synchronization-protocol`
-
-## Description
-
-If you are reading this, chances are you'd either like to contribute
-to one of Jami's components/projects, or to implement your own client.
-There are three main layers in this project:
-
-1. [OpenDHT](https://opendht.net), used for the p2p communication.
- You can interact with this library like any C++ library, or using
- the Python wrapper, or via its [REST
- API](https://github.com/savoirfairelinux/opendht/wiki/REST-API).
-
-2. The daemon, which is the main part. It's the part which does all
- the logic for Jami and interacts with OpenDHT, pjsip, FFmpeg, and
- the other libraries, and implements the whole protocol. If you'd
- like to do create a new Jami client, we recommend implementing it
- on top of this daemon, using one of its many APIs (REST, DBus,
- libwrap, or JNI).
-
-3. The client part, which is basically the *frontend*.
-
-The developer manual of Jami will explain the different features from
-all of these layers.
diff --git a/developer/account-management.md b/developer/jami-concepts/account-management.md
similarity index 100%
rename from developer/account-management.md
rename to developer/jami-concepts/account-management.md
diff --git a/developer/banned-contacts.md b/developer/jami-concepts/banned-contacts.md
similarity index 98%
rename from developer/banned-contacts.md
rename to developer/jami-concepts/banned-contacts.md
index 39f5c3ca13b6f05b4887213c0b856d9196e39868..3af1064cd209825b17a001b7a59273dbee11b7eb 100644
--- a/developer/banned-contacts.md
+++ b/developer/jami-concepts/banned-contacts.md
@@ -17,7 +17,7 @@ want to hear from her anymore. Instead of removing Jessica from her Ring
contacts -- which would still allow Jessica to send her contact
requests, Alice *bans* Jessica.
-**So, what does it mean ?**
+**So, what does it mean?**
In the daemon
-------------
diff --git a/developer/calls-in-swarm.md b/developer/jami-concepts/calls-in-swarm.md
similarity index 100%
rename from developer/calls-in-swarm.md
rename to developer/jami-concepts/calls-in-swarm.md
diff --git a/developer/calls.md b/developer/jami-concepts/calls.md
similarity index 100%
rename from developer/calls.md
rename to developer/jami-concepts/calls.md
diff --git a/developer/conference-protocol.md b/developer/jami-concepts/conference-protocol.md
similarity index 100%
rename from developer/conference-protocol.md
rename to developer/jami-concepts/conference-protocol.md
diff --git a/developer/connection-manager.md b/developer/jami-concepts/connection-manager.md
similarity index 100%
rename from developer/connection-manager.md
rename to developer/jami-concepts/connection-manager.md
diff --git a/developer/contact-management.md b/developer/jami-concepts/contact-management.md
similarity index 100%
rename from developer/contact-management.md
rename to developer/jami-concepts/contact-management.md
diff --git a/developer/drt.rst b/developer/jami-concepts/drt.rst
similarity index 97%
rename from developer/drt.rst
rename to developer/jami-concepts/drt.rst
index 6de61ac3fd9d318559bba812eb43c70a0e28a790..3bf7fdbb4d33d58f21f25572feed3f078fe14ab3 100644
--- a/developer/drt.rst
+++ b/developer/jami-concepts/drt.rst
@@ -121,7 +121,7 @@ Implementation
When starting Jami, every conversation initiates the creation of its routing table. The initial step is to establish contact with a first node to begin synchronization with other nodes. This process is known as "bootstrapping" and consists of two main parts.
-The first part involves retrieving all known devices in a conversation. This is accomplished by checking for known certificates in the repository or verifying the presence of certain members on the DHT (Distributed Hash Table). If a TCP connection already exists with any device in the conversation, it will be utilized. Additionally, known nodes are injected into the routing table.
+The first part involves retrieving all known devices in a conversation. This is accomplished by checking for known certificates in the repository or verifying the presence of certain members on the DHT (Distributed Hash Table). If a TCP connection already exists with any device in the conversation, it will be utilized. Additionally, known nodes are injected into the routing table. If no connection is successful, we will try to find new devices by performing a "GET" request on the DHT to get devices for each member.
The routing table is subsequently updated whenever an event occurs on a node.
diff --git a/developer/file-transfer.md b/developer/jami-concepts/file-transfer.md
similarity index 99%
rename from developer/file-transfer.md
rename to developer/jami-concepts/file-transfer.md
index 236dc9fa59b2315fd5d86e40361d2e5e6f102ad1..3a2813a39e95edd18521ac13c34b435056a54b3f 100644
--- a/developer/file-transfer.md
+++ b/developer/jami-concepts/file-transfer.md
@@ -209,6 +209,5 @@ send a file to B or to C (just have to select the correct conversation).
### TODO List
-1. Add unit-tests (https://gerrit-ring.savoirfairelinux.com/\#/c/9365/)
+1. Use libtorrent?
2. Show subtransfers status for outgoing files
-3. Offset resume (for failed transfer)
diff --git a/developer/images/file-transfer-datatransfer-class-diagram.png b/developer/jami-concepts/images/file-transfer-datatransfer-class-diagram.png
similarity index 100%
rename from developer/images/file-transfer-datatransfer-class-diagram.png
rename to developer/jami-concepts/images/file-transfer-datatransfer-class-diagram.png
diff --git a/developer/images/file-transfer-main-schema-diagram.png b/developer/jami-concepts/images/file-transfer-main-schema-diagram.png
similarity index 100%
rename from developer/images/file-transfer-main-schema-diagram.png
rename to developer/jami-concepts/images/file-transfer-main-schema-diagram.png
diff --git a/developer/images/file-transfer-tlssocketendpoint-diagram.png b/developer/jami-concepts/images/file-transfer-tlssocketendpoint-diagram.png
similarity index 100%
rename from developer/images/file-transfer-tlssocketendpoint-diagram.png
rename to developer/jami-concepts/images/file-transfer-tlssocketendpoint-diagram.png
diff --git a/developer/images/global-architecture.png b/developer/jami-concepts/images/global-architecture.png
similarity index 100%
rename from developer/images/global-architecture.png
rename to developer/jami-concepts/images/global-architecture.png
diff --git a/developer/images/iteration-send-message.jpg b/developer/jami-concepts/images/iteration-send-message.jpg
similarity index 100%
rename from developer/images/iteration-send-message.jpg
rename to developer/jami-concepts/images/iteration-send-message.jpg
diff --git a/developer/images/jami-reference-colours.png b/developer/jami-concepts/images/jami-reference-colours.png
similarity index 100%
rename from developer/images/jami-reference-colours.png
rename to developer/jami-concepts/images/jami-reference-colours.png
diff --git a/developer/images/nodes-table-1000.jpg b/developer/jami-concepts/images/nodes-table-1000.jpg
similarity index 100%
rename from developer/images/nodes-table-1000.jpg
rename to developer/jami-concepts/images/nodes-table-1000.jpg
diff --git a/developer/images/nodes-table-10000.jpg b/developer/jami-concepts/images/nodes-table-10000.jpg
similarity index 100%
rename from developer/images/nodes-table-10000.jpg
rename to developer/jami-concepts/images/nodes-table-10000.jpg
diff --git a/developer/images/placing-call-in-swarm-diagram.png b/developer/jami-concepts/images/placing-call-in-swarm-diagram.png
similarity index 100%
rename from developer/images/placing-call-in-swarm-diagram.png
rename to developer/jami-concepts/images/placing-call-in-swarm-diagram.png
diff --git a/developer/images/swarm-chat-classes-diagram.jpg b/developer/jami-concepts/images/swarm-chat-classes-diagram.jpg
similarity index 100%
rename from developer/images/swarm-chat-classes-diagram.jpg
rename to developer/jami-concepts/images/swarm-chat-classes-diagram.jpg
diff --git a/developer/jami-concepts/index.rst b/developer/jami-concepts/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..0c50d56b91893004b378610bc40116a9b7fe7c81
--- /dev/null
+++ b/developer/jami-concepts/index.rst
@@ -0,0 +1,74 @@
+#############
+Jami Concepts
+#############
+
+Jami is a quite complex platform interacting with many different
+components and introducing many new concepts. This manual is intended
+to help you understand how Jami works, how to develop for Jami, and how
+to contribute to the project.
+
+To quickly summarize and help you to find the part of the manual that
+you are looking for, here is a brief overview of the different sections:
+
+Jami is a distributed platform that allows users to communicate without
+the need for a central server. So, a Jami account consists on a chain of
+certificate (CA, Account, Device) that is used to authenticate the user
+and to encrypt the communication. The account is stored on the user's
+device, not on a server.
+
+For this, here is the page that explains how it works:
++ :ref:`account-management`
++ :ref:`jami-identifiers`
+
+After the user account is created, the user can contact other people by
+sending connection requests through a DHT (https://opendht.net) after finding the contact id
+(directly known or by lookup the name server). If both parties
+agree, they will first try to create a p2p TCP link (with the ICE protocol), then
+encrypt it via TLS and use it as a multiplexed socket to transmit data for various
+protocols c.f.:
+
++ :ref:`contact-management`
++ :ref:`banned-contacts`
++ :ref:`connection-manager`
++ :ref:`name-server-protocol`
+
+When both peers are in their contact list, a conversation is created. This conversation
+is called a **Swarm**. A **swarm** is synced between all devices in a conversation via
+the `git` protocol (it's a git repository) and connections across devices in a conversation
+are routed by a component called the **drt** (distributed routing table).
+
++ :ref:`swarm`
++ :ref:`drt`
+
+Then, the connection can be used to send messages, files, or to make calls (1:1 or conferences).
+
++ :ref:`calls`
++ :ref:`calls-in-swarm`
++ :ref:`file-transfer`
++ :ref:`conference-protocol`
+
+.. note::
+ Calls may be fully replaced by call in swarms in the future (except for SIP accounts)
+
+Finally, a user can have multiple devices and a lot of information is synced between them.
+
++ :ref:`synchronizing-profiles`
++ :ref:`synchronization-protocol`
+
+.. toctree::
+ :maxdepth: 1
+
+ account-management
+ banned-contacts
+ calls-in-swarm
+ calls
+ conference-protocol
+ connection-manager
+ contact-management
+ drt
+ file-transfer
+ jami-identifiers
+ name-server-protocol
+ swarm
+ synchronization-protocol
+ synchronizing-profiles
diff --git a/developer/jami-identifiers.md b/developer/jami-concepts/jami-identifiers.md
similarity index 100%
rename from developer/jami-identifiers.md
rename to developer/jami-concepts/jami-identifiers.md
diff --git a/developer/name-server-protocol.md b/developer/jami-concepts/name-server-protocol.md
similarity index 100%
rename from developer/name-server-protocol.md
rename to developer/jami-concepts/name-server-protocol.md
diff --git a/developer/swarm.md b/developer/jami-concepts/swarm.md
similarity index 99%
rename from developer/swarm.md
rename to developer/jami-concepts/swarm.md
index 274230aa156ca02fcbb9554d585a28450b526b12..ab610643690dd97310f292f783e4e00a1f04976a 100644
--- a/developer/swarm.md
+++ b/developer/jami-concepts/swarm.md
@@ -61,7 +61,12 @@ We identified four modes for swarm chat that we want to implement:
Sending a message is pretty simple. Alice writes a commit-message in the following format:
-**TODO format unclear**
+```json
+{
+ "type": "text/plain",
+ "body": "coucou"
+}
+```
and adds her device and CRL to the repository if missing (others must be able to verify the commit). Merge conflicts are avoided because we are mostly based on commit messages, not files (unless CRLS + certificates but they are located). then she announces the new commit via the **DRT** with a service message (explained later) and pings the DHT for mobile devices (they must receive a push notification).
@@ -74,14 +79,14 @@ For pinging other devices, the sender sends to other members a SIP message with
1. *Bob* do a git pull on *Alice*
2. Commits MUST be verified via a hook
3. If all commits are valid, commits are stored and displayed. Then *Bob* announces the message via the DRT for other devices.
-4. If all commits are not valid, pull is canceled. *Alice* must reestablish her state to a correct state. **TODO process*
+4. If all commits are not valid, pull is canceled. *Alice* must reestablish her state to a correct state.
### Validating a commit
To avoid users pushing some unwanted commits (with conflicts, false messages, etc), this is how each commit (from the oldest to the newest one) MUST be validated before merging a remote branch:
Note: if the validation fails, the fetch is ignored and we do not merge the branch (and remove the data), and the user should be notified
-Note2: If a fetch is too big, it's not done (**TODO**)
+Note2: If a fetch is too big, it's not merged
+ For each commits, check that the device that tries to send the commit is authorized at this moment and that the certificates are present (in /devices for the device, and in /members or /admins for the issuer).
+ 3 cases. The commit has 2 parents, so it's a merge, nothing more to validate here
@@ -422,8 +427,6 @@ In case of failure, when a device of the conversation will be back online, we wi
### Call in swarm
-#### TODO: nameserver part
-
#### Idea
A swarm conversation can have multiple rendez-vous. A rendez-vous is defined by the following uri:
@@ -613,7 +616,7 @@ Note: Following notes are not organized yet. Just some line of thoughts.
For a serious group chat feature, we also need serious crypto. With the current design, if a certificate is stolen as the previous DHT values of a conversation, the conversation can be decrypted. Maybe we need to go to something like **Double ratchet**.
-Note: a lib might exist to implement group conversations. TODO, investigate.
+Note: a lib might exist to implement group conversations.
Needs ECC support in OpenDHT
diff --git a/developer/synchronization-protocol.md b/developer/jami-concepts/synchronization-protocol.md
similarity index 100%
rename from developer/synchronization-protocol.md
rename to developer/jami-concepts/synchronization-protocol.md
diff --git a/developer/synchronizing-profiles.md b/developer/jami-concepts/synchronizing-profiles.md
similarity index 100%
rename from developer/synchronizing-profiles.md
rename to developer/jami-concepts/synchronizing-profiles.md
diff --git a/developer/apis-of-jami.md b/developer/new-developers/apis-of-jami.md
similarity index 88%
rename from developer/apis-of-jami.md
rename to developer/new-developers/apis-of-jami.md
index 0ac61c3fd1677a8b4f3680e970629342c6d26705..11008342ae69770f1006bfd7e8f98f8a3e1932e4 100644
--- a/developer/apis-of-jami.md
+++ b/developer/new-developers/apis-of-jami.md
@@ -38,4 +38,9 @@ All the documentation and code for the REST API is located in `jami-daemon/bin/r
### Python wrapper
-A Python wrapper is available in `jami-daemon/tools/jamictrl`. This wrapper uses DBus.
\ No newline at end of file
+A Python wrapper is available in `jami-daemon/tools/jamictrl`. This wrapper uses DBus.
+
+## Plugins
+
+Plugins are a good way to customize Jami if you want to interact with streams (Audio, Video or chat). Several plugins are already available
+through the Plugin Store (in the settings of your Jami application).
\ No newline at end of file
diff --git a/developer/coding-style.md b/developer/new-developers/coding-style.md
similarity index 100%
rename from developer/coding-style.md
rename to developer/new-developers/coding-style.md
diff --git a/developer/debugging-tools.rst b/developer/new-developers/debugging-tools.rst
similarity index 100%
rename from developer/debugging-tools.rst
rename to developer/new-developers/debugging-tools.rst
diff --git a/developer/improving-quality-of-jami.md b/developer/new-developers/improving-quality-of-jami.md
similarity index 100%
rename from developer/improving-quality-of-jami.md
rename to developer/new-developers/improving-quality-of-jami.md
diff --git a/developer/new-developers/index.rst b/developer/new-developers/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..5bd44c6bb8dd64c1c350b2f0fc0d4c7d2f78627b
--- /dev/null
+++ b/developer/new-developers/index.rst
@@ -0,0 +1,19 @@
+##############
+New Developers
+##############
+
+This part of the documentation is intended for new developers who want to
+contribute to the project. It explains the tools, some conventions and some
+tools.
+
+.. toctree::
+ :maxdepth: 1
+
+ apis-of-jami
+ coding-style
+ debugging-tools
+ improving-quality-of-jami
+ qt-qml-coding-style
+ qt-qml-testing-tools
+ submitting-your-first-patch
+ working-with-gerrit
\ No newline at end of file
diff --git a/developer/jami-smoke-tests.ods b/developer/new-developers/jami-smoke-tests.ods
similarity index 100%
rename from developer/jami-smoke-tests.ods
rename to developer/new-developers/jami-smoke-tests.ods
diff --git a/developer/qt-qml-coding-style.md b/developer/new-developers/qt-qml-coding-style.md
similarity index 100%
rename from developer/qt-qml-coding-style.md
rename to developer/new-developers/qt-qml-coding-style.md
diff --git a/developer/qt-qml-testing-tools.md b/developer/new-developers/qt-qml-testing-tools.md
similarity index 100%
rename from developer/qt-qml-testing-tools.md
rename to developer/new-developers/qt-qml-testing-tools.md
diff --git a/developer/submitting-your-first-patch.md b/developer/new-developers/submitting-your-first-patch.md
similarity index 100%
rename from developer/submitting-your-first-patch.md
rename to developer/new-developers/submitting-your-first-patch.md
diff --git a/developer/working-with-gerrit.md b/developer/new-developers/working-with-gerrit.md
similarity index 100%
rename from developer/working-with-gerrit.md
rename to developer/new-developers/working-with-gerrit.md
diff --git a/developer/design-process.md b/developer/processes/design-process.md
similarity index 100%
rename from developer/design-process.md
rename to developer/processes/design-process.md
diff --git a/developer/processes/index.rst b/developer/processes/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..998fafc2d65b82ec9612d11ab19990947c3a53ae
--- /dev/null
+++ b/developer/processes/index.rst
@@ -0,0 +1,12 @@
+#########
+Processes
+#########
+
+This section describes the processes that are used to develop and release the
+software.
+
+.. toctree::
+ :maxdepth: 1
+
+ design-process
+ release-process
\ No newline at end of file
diff --git a/developer/release-process.md b/developer/processes/release-process.md
similarity index 100%
rename from developer/release-process.md
rename to developer/processes/release-process.md
diff --git a/developer/protocol.md b/developer/protocol.md
deleted file mode 100644
index 0c317640be30e6a902e6ea6670c9d579f16c6c16..0000000000000000000000000000000000000000
--- a/developer/protocol.md
+++ /dev/null
@@ -1,245 +0,0 @@
-Protocol
-========
-
-Jami account creation
----------------------
-
-A **Jami account** is defined by an **RSA key pair** with a key length
-of at least 4096 bits.
-
-The standard x509 160-bits fingerprint of the account public key is
-called the **RingID**.
-
-The account public key is used as the subject of an x509 certificate
-that must be valid, have the Certificate Authority flag set, and can be
-self-signed. This certificate is called the **Jami account
-certificate**.
-
-The subject UID field of the account certificate must be the hexadecimal
-form of the public key fingerprint. The issuer UID field must be the
-hexadecimal form of the issuer public key fingerprint.
-
-### Persisting the account
-
-Persisting a Jami account private key and certificate is implementation
-defined.
-
-Access to a saved Jami account private key must be authenticated and
-authorized. Authentication and authorization method to access the
-account private key is implementation defined.
-
-### Adding a device to a Jami account
-
-*See [RFC 5280](https://tools.ietf.org/html/rfc5280)*
-
-A **device** is defined by an RSA key pair with a key length of at least
-4096 bits.
-
-A **device certificate** is defined as an x509 certificate whose subject
-is a device public key, signed with an account private key. The
-certificate MUST be valid. The issuer UID field MUST be the hexadecimal
-form of the account public key fingerprint.
-
-Persisting a device private key and certificate is implementation
-defined. Access to a saved device private key should be authenticated.
-Authentication method to access the device private key is implementation
-defined.
-
-### Removing a device from a Jami account
-
-A device can be "removed" from a Jami account through revocation of the
-device certificate. Revoked device certificates are added to one or more
-standard x509 Certificate Revocation List (CRL). CRLs for revoked device
-must be valid and signed with the corresponding CA key, which is the
-Jami account private key.
-
-### Account transmission format
-
-The **account archive format** defines how to serialize an account
-private key for transmission, for instance to sign a new device
-certificate.
-
-The account archive is an encrypted JSON object with the following
-structure:
-
-```
-{
- "ringAccountKey": (PEM-encoded account private key string),
- "ringAccountCert": (PEM-encoded account certificate string),
- "ringAccountCRL": (PEM-encoded account CRL string)
-}
-```
-
-The JSON object can contain additional implementation-defined key-value
-pairs. Implementation-defined key names shouldn't start with "ring".
-
-The string JSON object is encrypted using a key defined as :
-
-```
-salt = PIN + timestamp
-key = argon2(password, salt)
-```
-
-Where PIN is a random 32bits number in hexadecimal form, "+" is string
-concatenation, timestamp is the current UNIX timestamp divided by 1200
-(20 minutes) and password is a user-chosen password.
-
-The PIN should be shown to the user to be copied manually on the new
-physical device along with the password.
-
-Contacting another account
---------------------------
-
-### ICE descriptor exchange over OpenDHT
-
-- **Listening for incoming calls**
-
-A device listens for incoming call by performing a listen OpenDHT
-operation on
-
-`h("callto"+deviceID)`
-
-where h is SHA1, "+" is the string concatenation and deviceID is the
-hexadecimal form of the deviceID.
-
-Received OpenDHT values that are not encrypted or not properly signed
-must be dropped. The value must be encrypted with the called device
-public key and signed with the calling device private key according to
-OpenDHT specifications.
-
-- **Sending the Initial Offer**
-
-*See [RFC 5245](https://tools.ietf.org/html/rfc5245)*
-
-RFC 5245 defines ICE (Interactive Connectivity Establishment), a
-protocol for NAT traversal.
-
-ICE is used in Jami to establish a peer-to-peer communication between
-two devices.
-
-The calling device gathers candidates and build an Initial Offer
-according to the ICE specifications and starts the ICE negotiation
-process.
-
-The calling device puts the encrypted ICE offer (the Initial Offer) on
-the DHT at h("callto"+deviceID) where deviceID is the hexadecimal form
-of the called deviceID.
-
-- **ICE serialization format**
-
-ICE messages exchanged between peers during a call setup use following
-format. An ICE message is a chunk of binary data, following
-[msgpack](http://msgpack.org/) data format.
-
-This protocol is a compound of msgpack values, successively packed in
-this order:
-
-
-+ an integer giving the version of ICE message format protocol used for the rest of the data. Current defined protocol version is **1**.
-+ a 2-elements array of strings of the ICE local session ufrag and the ICE local session password
-+ an integer giving the number of components in the ICE session
-+ an array of string, of the previous number entries, where each string describe the ICE candidate, formated as an "a=" line (without the "a=" header) described in [rfc5245, section 4.3](https://tools.ietf.org/html/rfc5245#page-26)
-
-- **Sending the Answer**
-
-Upon reception of the encrypted and signed Initial ICE Offer (through
-the listen operation), a called device should perform authorization
-checks of the calling device, identified as the Initial Offer signer.
-Authorization rules are implementation defined, but a typical
-implementation would authorize known or trusted contacts.
-
-If the calling device is not authorized or if for any implementation
-defined reason the called device refuses the incoming connection
-request, the called device must ignore the Initial Offer and may log the
-event.
-
-If the called device authorizes the caller and wish to accept the
-connection it must build an ICE answer, start the ICE negotiation
-process and send the encrypted and signed ICE answer at the same DHT
-key.
-
-### DTLS negotiation
-
-Once a peer-to-peer communication channel has been established, the
-called device listens on it for incoming DTLS connections (acting as a
-DTLS server) while the caller initiates an outgoing DTLS connection
-(acting as a DTLS client).
-
-The DTLS communication must be RFC6347 compliant
-([1](https://tools.ietf.org/html/rfc6347)).
-
-Peers must only support PFS cypher suites. The set of supported cypher
-suites is implementation defined but should include at least
-ECDHE-AES-GCM (TODO: specify the exact suites recommended to support).
-
-During the DTLS handshake, both peers must provide their respective
-device certificate chain and must authenticate the other peer, checking
-that its public key is the same used during the DHT ICE exchange.
-
-### SIP call
-
-*See [Important\_RFC](Important_RFC "wikilink")*
-
-Once an encrypted and authenticated peer-to-peer communication channel
-is available, the SIP protocol [2](https://tools.ietf.org/html/rfc3261)
-must be used to place a call and send messages. The caller might send a
-SIP INVITE as soon as the DTLS channel is established.
-
-The SIP implementation must support ICE and SRTP.
-
-Supported codecs are implementation defined, but Jami clients should
-support the Opus audio coded and the H264 video codec.
-
-SRTP must be used when negotiating media with SIP, using a new random
-key for each media and each negotiation. ICE should be used when
-negotiating media with SIP.
-
-Cryptographic primitives
-------------------------
-
-### Password stretching
-
-*See [Argon2
-specifications](https://github.com/P-H-C/phc-winner-argon2/blob/master/argon2-specs.pdf)*
-
-Passwords are stretched using argon2i using t\_cost = 16, m\_cost =
-2\^16 (64 MiB), mono-threaded, to generate a 512 bits hash.
-
-The result is then hashed again using SHA{1, 256, 512} depending on the
-requested key size.
-
-### Encryption
-
-##### Using a provided key (128, 192 or 256 bits)
-
-Encryption uses standard AES-GCM as implemented by Nettle using a random
-IV for each encryption.
-
-##### Using a text password
-
-The password is stretched to generate a 256 bits key and a random salt
-of 128 bits.
-
-The input data is encrypted using AES-GCM (see above) and the salt is
-appended at the beginning of the resulting cypher-text.
-
-##### During a call
-
-Audio/video data are exchanged using encrypted RTP channels between
-peers.
-
-The protocol is a classic SRTP, with following supported crypto suites:
-
-- Jami account force AES\_CM\_128\_HMAC\_SHA1\_80
-- SIP can use AES\_CM\_128\_HMAC\_SHA1\_80 or
- AES\_CM\_128\_HMAC\_SHA1\_32
-
-The master key and salt is a random number, different for each call. On
-call's master key is constant during the full live of a call.
-
-The keys are exchanged using SDES method: keys are written into the SIP
-SDP messages during the SIP INVITE negotiation. When SDES is used, Ring
-forces the underlaying transport to be secure (encrypted) to not
-disclose these keys. Jami supports DTLS natively for SIP and Ring
-accounts for such. The call cannot be done if this condition is not
-fulfilled.
diff --git a/developer/technical-overview.md b/developer/technical-overview.md
deleted file mode 100644
index a28396acb13a2da7dd12db985b619f48ea60ec76..0000000000000000000000000000000000000000
--- a/developer/technical-overview.md
+++ /dev/null
@@ -1,300 +0,0 @@
-Technical overview
-==================
-
-Concepts
---------
-
-## Jami Account
-
-- A **Jami account** is defined by a cryptographic Jami Identity based
- of **RSA asymmetric key-pair** and managed with **x.509
- certificates** as defined by *[RFC
- 5280](https://tools.ietf.org/html/rfc5280)*.
-- Jami uses the **gnutls** library to generate and manage RSA keys
- and certificates.
-
-### Jami certificate
-
-- This represents the identify of a Jami user.
-- Generated at account creation
-- Contains the Jami account public key.
-- The SHA-1 fingerprint (160-bits) of this public certificate is the
- **JamiId**.
-- Signed by a CA (from an organization or self-signed).
-- The subject UID field must be the hexadecimal form of the JamiId.
-- The issuer UID field must be the hexadecimal form of the issuer
- public key fingerprint (CA).
-- Random RSA key-pair of at least 4096-bits long.
-
-### Device certificate
-
-- This is the identity of one specific device used to run Jami.
-- One per device.
-- Random and 4096-bits long.
-- The SHA-1 fingerprint of the public key becomes the **DeviceId**.
-- Must be signed by the private key that created the Jami certificate.
-- The subject UID field must be the hexadecimal form of the DeviceId.
-- The issuer UID field must be the hexadecimal form of the issuer
- public key fingerprint (JamiId).
-
-### Usages
-
-- The JamiId:
- - It's the DHT key where the list of account devices are published
- and where all devices listen to synchronize on account
- changes (i.e. adding or revoke a device).
-- The Jami certificate RSA keys are used as long-term keys to
- sign/encrypt/decrypt messages sent over the DHT:
- - private key to sign-off and decrypt incoming messages and
- device certificates.
- - public key to encrypt messages (this is done by the message
- issuer using the receiver public key).
-- A device can be "removed" from a Jami account through revocation of
- the device certificate:
- - Revoked device certificates are added to one or more standard
- x509 Certificate Revocation List (CRL).
- - CRLs for revoked device must be valid and signed with the
- corresponding CA key, which is the Jami account private key.
-
-### Long-term Storage
-
-- Why storing data?
-
-<!-- -->
-
-- - Jami needs to load certificates and key-pairs each time the
- application is started.
- - When Jami creates a new device, these information are also
- needed, shared from another trusted device in a secure way.
- - All platforms doesn't provide secure way to store data, Jami
- supports this fact by encrypting data stored outside the
- memory (i.e. on a file-system) using a user defined password
- during the account creation.
-
-<!-- -->
-
-- These files are stored on user device (see below for details):
- - a compressed and encrypted archive with private account data.
- - the public certificates chain as a CRT file
- - the device private key.
-
-#### Jami archive (export.gz)
-
-- Contains private account data.
-- Currently transmitted over the DHT network when device is created
- or revoked.
-- It's a JSON compressed and encrypted file.
-
-<!-- -->
-
-- The current format is (could change at any time):
-
-```
-{
- ringCaKey: <base64 serialized PEM-encoded CA private key>,
- ringAccountKey: <base64 serialized PEM-encoded Jami private key>
- ringAccountCert: <base64 serialized PEM-encoded Jami certificate (public key)>,
- ethKey: <base64 serialized of the optional 160-bits Etherium key used to register the JamiId on a public blockchain>,
- ringAccountCRL: <base64 serialized of packet list of revoked device certificates PEM-encoded>,
- ringAccountContacts: <JSON dictionary to export trusted user contacts>
-}
-```
-
-- The JSON byte-stream is compressed using \*gzip\* algorithm.
-
-<!-- -->
-
-- Then the gzip-stream is encrypted using AES-GCM-256 symmetric cipher
- with a 256-bits key.
- - This key is derived from the user provided password, a PIN and a
- timestamp, using
- [Argon2](https://github.com/P-H-C/phc-winner-argon2) (a password
- stretching and normalizer) as follow:
-
-```
-salt = PIN + timestamp
-key = argon2(password, salt)
- argon2 is the argon2i algorithm using t_cost = 16, m_cost = 2^16 (64 MiB), mono-threaded, to generate a 512-bits key and then hashed with SHA-256 to generate a 256-bits key.
- PIN is a random 32bits number in hexadecimal form.
- + is string concatenation operator.
- timestamp is the current UNIX timestamp divided by 1200 (20 minutes).
- password is a user-chosen password (given at account creation).
-```
-
-- The PIN should be shown to the user to be copied manually on the new
- physical device along with the password to finish the device
- creation process.
-- NOTE: when exporting a file on the DHT or anywhere else, the daemon update the archive first, to write latest contacts. This is the reason why the password is needed when exporting (it's not just a copy of the archive somewhere else)
-
-#### Jami device certificate chain (ring\_device.crt)
-
-- PEM format
-- Includes the Device certificate and parent certificates (Jami device
- certificate and parents)
-
-#### Device private key (ring\_device.key)
-
-- PEM format
-- not encrypted, we let the device file-system protect this file
-
-### The DHT network
-
-Dedicated [ Jami distributed
-network](Ring_distributed_network "wikilink") page.
-
-### Contact Request
-
-- Deprecated in favor of "Conversation requests"
-
-### Conversation request
-
-- Max 64k (a DHT value)
-- Contains a conversation Id
-- Contains the sender URI
-- Can contains optional metadatas (avatar/profile)
-
-### Instant Message
-
-- Mostly used to initiate connections with ICE candidates
-- Can transmit some SIP messages, however SIP channel is preferred
-- SIP messages can be read status, location sharing, messages notifications.
-
-### Outgoing and Incoming calls
-
-- Contactable addresses (i.e. IP addresses) of the user are given to
- peer only:
- - When we call a peer (outgoing call).
- - When a **trusted** peer is calling (incoming call).
-- All combination forms of how a specific device can be contacted is
- summarized by a ICE message:
- - *[RFC 5245](https://tools.ietf.org/html/rfc5245)* defines ICE
- (Interactive Connectivity Establishment), a protocol for
- NAT traversal.
- - ICE is used in Jami to establish a peer-to-peer communication
- between two devices.
-
-#### Making an outgoing call
-
-1. The calling device gathers candidates and build an **Initial Offer**
- according to the ICE specifications.
-2. The calling device puts the encrypted ICE offer (the *Initial
- Offer*) on the DHT at:
- `h("`[`callto:"+DeviceID`](callto:%22+DeviceID)`)` where *h* is
- SHA1, *+* is the string concatenation, *DeviceID* is in
- hexadecimal form.
-3. The calling device waits on the peer answer, with its own ICE
- candidates lists.
-4. At peer answer reception, the calling device starts the
- ICE negotiation.
-5. If the negotiation succeed, the process continues on a client-side
- DTLS session establishment over the created ICE socket (see below).
-
-#### Listening for incoming calls
-
-1. A device listens for incoming calls by performing a listen OpenDHT
- operation on `h("`[`callto:"+DeviceID`](callto:%22+DeviceID)`)`
- where *h* is SHA1, *+* is the string concatenation and *DeviceID* is
- in hexadecimal form.
-2. At ICE *Initial Offer* reception, the called device **must** do a
- security validation of the peer (see below).
-3. If the security validation succeed, the called device starts the
- ICE negotiation.
-4. If the negotiation succeed, the process continues on a server-side
- DTLS session establishment over the created ICE socket (see below).
-
-- *Note: OpenDHT drops values that are not properly encrypted or
- signed, as specified by OpenDHT protocol.*
-
-#### ICE serialization format
-
-- ICE messages exchanged between peers during a call set up use
- following format.
-- An ICE message is a chunk of binary data, following
- [msgpack](http://msgpack.org/) data format.
-
-```
-<8-bits unsigned integer> giving the version of ICE message format protocol used for the rest of the data,
-<C++ std::pair of string> of the ICE local session ufrag and the ICE local session password,
-<8-bits unsigned integer> giving the number of components in the ICE session,
-<array of string> of the previous number entries, where each string describe the ICE candidate, formated as an "a=" line (without the "a=" header) described in [rfc5245, section 4.3](https://tools.ietf.org/html/rfc5245#page-26)
-```
-
-- **Current defined protocol is 1**:
-
-#### Security Validation of the Peer
-
-- Upon reception of the encrypted and signed Initial ICE Offer
- (through the listen operation), a called device should perform
- authorization checks of the calling device, identified as the
- Initial Offer signer.
-- Authorization rules are implementation defined, but a typical
- implementation would authorize known or trusted contacts.
-- If the calling device is not authorized or if for any implementation
- defined reason the called device refuses the incoming connection
- request, the called device must ignore the Initial Offer and may log
- the event.
-- If the called device authorizes the caller and wish to accept the
- connection it must build an ICE answer, start the ICE negotiation
- process and send the encrypted and signed ICE answer at the same
- DHT key.
-
-#### DTLS negotiation
-
-- Once a peer-to-peer communication channel has been established by
- ICE protocol, the called device starts a server-side DTLS session on
- the ICE socket, while the caller starts a client-side DTLS session
- on the other side of the ICE socket.
-- The DTLS communication is
- [RFC6347](https://tools.ietf.org/html/rfc6347) compliant using
- gnutls library.
-- To prevent peer certificates to be displayed in plain-text for the
- call anonymity, the session handshake is done twice:
-
-1. A first handshake in **anonymous mode** to create a secure but
- anonymous transport.
-2. A second handshake in **certificate mode**, over the first one, to
- prove the identity of peers.
-
-- Only PFS cipher suites are supported:
- - The set of supported cipher suites is implementation defined but
- should include at least ECDHE-AES-GCM.
- - The actual cipher suites (in gnutls form) is:
- - anonymous step:
- `SECURE192:-KX-ALL:+ANON-ECDH:+ANON-DH:+SECURE192:-VERS-TLS-ALL:+VERS-DTLS-ALL:-RSA:%SERVER_PRECEDENCE:%SAFE_RENEGOTIATION`
- - certificate step:
- `SECURE192:-VERS-TLS-ALL:+VERS-DTLS-ALL:-RSA:%SERVER_PRECEDENCE:%SAFE_RENEGOTIATION`
-
-#### SIP signaling
-
-- Used over the DTLS session to signaling the call (vcard, media
- negotiation, hangup, instant messaging, ...)
-- Once an encrypted and authenticated peer-to-peer communication
- channel is available, the [SIP
- protocol](https://tools.ietf.org/html/rfc3261) must be used to place
- a call and send messages.
-- The caller might send a SIP INVITE as soon as the DTLS channel
- is established.
-- The SIP implementation must support ICE and SRTP.
-- Supported codecs are implementation defined, but Jami clients should
- support the Opus audio coded and the H264 video codec.
-- SRTP must be used when negotiating media with SIP, using a new
- random key for each media and each negotiation. ICE should be used
- when negotiating media with SIP.
-
-### Presence
-
-- Sent on the DHT
-- DeviceAnnouncement (contains device hash + public key)
-
-
-### Security / Privacy
-
-Jami provides perfect forward secrecy for calls and in call text
-messages with different Eliptic Curve Diffie-Hellman key negociation at
-every call. For out of call messaging single RSA-4096 is used. The
-cryptography library used is GNUTLS
-
-More informations:
-
-- [Technical overview](technical/Technical-overview) of concepts and
- protocols inside Jami
diff --git a/index.rst b/index.rst
index 42ba1fac7a28a77c2f708391f97eb1a2e6e8997f..f3db2ba9953f12a879aeef59ac9d256df4016270 100644
--- a/index.rst
+++ b/index.rst
@@ -15,7 +15,7 @@ modify it under the terms of the `GNU General Public License
<https://www.gnu.org/licenses/gpl.html>`_ as published by the Free
Software Foundation, either version 3 of the License, or (at your
option) any later version. The Jami team :doc:`uses Gerrit for
-development <developer/working-with-gerrit>` and code reviews, and
+development <developer/new-developers/working-with-gerrit>` and code reviews, and
issues and feature requests are :doc:`tracked on the Jami GitLab
<user/bug-report-guide>`. The development of Jami is led by
`Savoir-faire Linux <https://savoirfairelinux.com/en>`_ --- a Canadian
diff --git a/user/bug-report-guide-fr.md b/user/bug-report-guide-fr.md
deleted file mode 100644
index d52e1c6ff7f1179239e0c2ae7abf2744a0f2643c..0000000000000000000000000000000000000000
--- a/user/bug-report-guide-fr.md
+++ /dev/null
@@ -1,186 +0,0 @@
-Rapporter un bug (FR)
-=====================
-
-[Page](bug-report-guide) traduite par la communauté
-
-**Note : Nous sommes actuellement quelques developpeurs actifs sur le projet. Nous ne pouvons pas répondre à chaque question ouverte, mais nous la lisons. Vos questions nous fournissent des retours d'informations importantes et nous vous en remercions, tout retour d'information est apprécié**.
-
-Configurez votre environnement
-----------------------
-
-- Soyez prêt pour une perte de données. Sauvegardez votre compte et liez votre compte à autant d'appareils que possible.
-
-- Installez la dernière version (ou même une version bêta) de Jami. Il est inutile de signaler des bugs sur les anciennes versions.
-
-Comment signaler un bug (dysfonctionnement)
--------------------
-
-0. Créez un compte sur
- [notre dépôt git](https://git.jami.net/users/sign_in)
- (si ce n'est pas déjà fait).
-
-1. Choisissez le bon projet dans lequel poster votre problème :
-
- - {gitlab-project}`Le client Android <jami--client-android>`
- - {gitlab-project}`Le client Qt <jami-client-qt>`
- - {gitlab-project}`Le client GNOME/GTK <jami-client-gnome>`
- - {gitlab-project}`Le client iOS <jami-client-ios>`
- - {gitlab-project}`Le client macOS <jami-client-macos>`
- - {gitlab-project}`Le projet Jami en général (ou si vous n'êtes pas
- sûr) <jami-project>`
- - [Si vous savez ce que vous faites, vous pouvez choisir l'un des
- autres projets](https://git.jami.net)
-
-2. Si vous avez plusieurs problèmes, veuillez remplir des rapports de bogue séparés. Il sera beaucoup plus facile de suivre les bugs de cette façon.
-
-3. Le titre est un résumé explicite du bogue (par exemple, la barre d'en-tête est trop grande en raison de la taille de l'icône).
-
-4. Déterminez les étapes pour reproduire le bogue :
-
-- Si vous avez des étapes précises pour le reproduire - génial ! -vous êtes sur la bonne voie pour créer un rapport de bogue utile.
-
-- Si vous pouvez le reproduire occasionnellement, mais pas après avoir suivi des étapes spécifiques, vous devez fournir des informations supplémentaires pour que le rapport de bogue soit utile.
-
-- Si vous ne pouvez pas reproduire le problème, il n'est probablement pas utile de le signaler, à moins que vous ne fournissiez des informations determinantes sur son apparition.
-
-- Si le bogue conduit à d'autres bogues par la suite que vous ne pouvez pas reproduire d'une autre manière, il n'est probablement pas utile de le signaler.
-
-5. Assurez-vous que votre logiciel est à jour. Idéalement, testez une version en cours de développement pour voir si votre bogue a déjà été corrigé.
-
-6. Essayez d'isoler le problème de l'environnement et de le reproduire (pour ce-faire, testez-le sur différents
-appareils)
-
-7. Décrivez votre/vos environnement(s) en précisant les éléments suivants :
-
-- la version du système d'exploitation
-- modèle précis de l'appareil (important pour les appareils mobiles)
-- si vous utilisez une version bêta
-- quelle version vous utilisez (de ring.cx, F-droid, Play Store, App store, votre propre version...). Si vous avez construit votre propre version de Jami, veuillez spécifier la version exacte de jamid (LibRing ou LibJami ou Daemon) et la version du client (Vous pouvez l'obtenir avec `jamid -v` et `jami-gnome -v`. Mais notez que nos paquets sont mis à jour assez souvent) et le commit Git.
-- les conditions du réseau : Les deux appareils sont-ils sur le même réseau local ? Des réseaux différents ? Est-ce qu'un ou les deux sont derrière NAT ? Utilisez-vous LTE ? Wifi ?
-- D'autres éléments si nécessaire : Fournisseur SIP, matériel...
-
-
-Rédiger un résumé clair
------------------------
-
-Comment décririez-vous le bug en 10 mots environ ? C'est la
-première partie de votre rapport de bogue qu'un développeur verra.
-
-Un bon résumé doit permettre d'identifier rapidement et de manière unique un rapport de bogue. Il doit expliquer le problème, et non la solution que vous proposez.
-Exemples :
-```
-Bon :) "L'annulation d'un transfert de fichier fait planter Jami"
-Pas bon :( "Le logiciel se plante"
-```
-
-```
-Bon :) "Tous les appels raccrochent après 32 secondes"
-Pas bon :( "Impossible d'appeler mes amis"
-```
-
-Rédiger des étapes précises à reproduire
-----------------------------------
-
-* Comment un développeur peut-il reproduire le bogue sur son propre appareil ?
-
-Les étapes à reproduire sont la partie la plus importante de tout rapport de bogue. Si un développeur est capable de reproduire le bogue, il est très probable que le bogue soit corrigé.
-Si les étapes ne sont pas claires, il n'est même pas possible de savoir si le bogue a été corrigé. Nous sommes tout à fait conscients que certains bogues peuvent vous sembler évidents, mais ils sont probablement liés à votre environnement.
-Plus vous serez précis, plus vite le bogue sera corrigé.
-
-* Que devez-vous inclure dans un rapport de bug ?
-
-Indiquez si vous pouvez reproduire le bogue à volonté, occasionnellement ou pas du tout. Décrivez votre méthode d'interaction avec Jami en plus de l'intention de chaque étape. Après vos étapes, décrivez précisément le résultat observé (réel) et le résultat attendu.
-
-Séparez clairement les faits (observations) des spéculations (suppositions).
-
-### Bon :)
-
-Je peux toujours reproduire en suivant ces étapes :
-
-```
-1. Démarrez Jami en cliquant sur l'icône du bureau
-2. Commencez une nouvelle conversation avec n'importe qui
-3. Cliquez sur l'icône de transfert de fichiers
-
-Résultats attendus : Une fenêtre s'ouvre et me demande de choisir un fichier à envoyer.
-Résultats réels : Lorsque je clique sur l'icône de transfert de fichiers, rien ne se passe.
-```
-
-### Pas bon :(
-
-```
-Essayer de transférer un fichier
-Cela ne fonctionne pas.
-```
-
-Résultat obtenu
----------------
-
-Veuillez inclure :
-
-+ Les journaux de débogage du daemon (ou LibJami ou LibRing) et du
- client.
-+ Le core dump s'il a été produit.
-
-Résultat attendu
----------------
-
-Il s'agit d'une description du comportement attendu ou souhaité.
-
-
-Fournir des informations supplémentaires
---------------------------------
-
-Les informations suivantes sont demandées pour la plupart des rapports de bogue. Vous pouvez gagner du temps en fournissant ces informations sous la rubrique Résultats attendus.
-
-### Journaux
-
-#### Client-qt (Windows, GNU/Linux)
-
-Allez dans les paramètres généraux. Dans la section "Dépannage"(Déverminage, Débogage), vous pouvez cliquer sur "Ouvrir les journaux", où vous pourrez obtenir des statistiques ("Show stats") ou commencer à enregistrer des informations via "Journaux reçus". Ensuite, vous pouvez simplement copier le résultat et expliquer votre scénario.
-
-#### Sur GNU/Linux
-
-Journaux classiques (par défaut, seuls les journaux >= warning sont journalisés) :
-
-```
-journalctl --since "24h ago" | grep jamid
-```
-
-Journal complet :
-Puisque l'interface graphique et le démon Jami sont des processus séparés, la manière la plus simple d'obtenir les journaux des deux est de les démarrer un par un, manuellement.
-
-1. Assurez-vous qu'aucune instance du client ou du daemon Jami ne fonctionne avec `ps aux | grep ring``.
- + Jami peut être en cours d'exécution même si aucune fenêtre n'est ouverte, selon vos préférences.
- + Si un client ou un daemon est en cours d'exécution, tuez-les avec `kill PID`.
-2. Sur un terminal, démarrez le démon avec `jamid -d -c`.
- + Cet exécutable n'est normalement pas dans le PATH, et sur les paquets Ubuntu, il est situé dans `/usr/lib/x86_64-linux-gnu/jamid -d -c` ou `/usr/libexec/jamid -d -c`.
-3. Dans un autre terminal, démarrez le client avec (voici un exemple pour Gnome) `jami-gnome -d`.
-
-Pour obtenir un backtrace, vous pouvez exécuter le programme dans gdb :
-
-̀ gdb -ex run jami-gnome` ou `gdb -ex run --args /usr/lib/ring/jamid -cd`.
-
-Lorsqu'il se plante, vous pouvez taper `bt` puis appuyer sur **Enter**. Et copiez le backtrace sur le problème. (ou `thread apply all bt`, c'est encore mieux)
-
-#### Sur Mac OS
-
-Naviguez jusqu'à /Applications/Jami.app/Contents/MacOS/
-
-+ Double-cliquez sur Jami. Cela lancera Jami et imprimera le journal dans le terminal.
-+ Copiez le journal du terminal vers un fichier.
-
-#### Sur Android
-
-+ Vous devez avoir configuré adb sur votre ordinateur.
-+ Lancez Jami sur votre smartphone et exécutez ensuite
-+ ``adb logcat *:D | grep `adb shell ps | egrep 'cx.ring' | cut -c10-15` > logring.txt``
-+ Vous avez maintenant un fichier contenant le log du client
-
-#### Pour Windows
-
-Ouvrez un terminal(cmd.exe) et lancez Jami.exe avec les options suivantes :
-
-+ `-d` pour ouvrir une fenêtre console séparée pour recevoir les logs
-+ `-f` pour écrire les journaux dans `%localappdata%\jami\i.log`
-+ `-c` pour imprimer les journaux directement dans la fenêtre de sortie de débogage de Visual Studio.