4 files changed, 10 insertions, 10 deletions
diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
index c7779000d..78a914abc 100644
--- a/.github/CONTRIBUTING.md
+++ b/.github/CONTRIBUTING.md
@@ -5,7 +5,7 @@ Interesting in contributing? Awesome :)
 **Quick Links:**
  * [Give your feedback](#give-your-feedback)
-  * [Develop on the Server side}(#develop-on-the-server-side)
+  * [Develop on the Server side](#develop-on-the-server-side)
  * [Develop on the Client side](#develop-on-the-client-side)
  * [Write documentation](#write-documentation)
diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md
index 65dd5b49d..1454f9427 100644
--- a/ARCHITECTURE.md
+++ b/ARCHITECTURE.md
@@ -42,9 +42,9 @@
  * All the requests are retried if they failed
  * The requests are made at regular intervals to all pods of the network with a limit of parallel requests: if there are 1000 pods in the networks, the server won't make more than 10 requests in parallel
  * If there are no informations to send (no video addition/removal), no requests are made
-  * The requests are grouped: for example if the interval is 1 hour and an user upload 2 videos there will be only 1 request that contains the 2 videos informations
+  * The requests are grouped: for example if the interval is 1 hour and a user$ upload 2 videos there will be only 1 request that contains the 2 videos informations
-  * The requests in the group are ordered: if an user add a video and remove it, we need to transmit these informations to the other pods in the same order
+  * The requests in the group are ordered: if a user add a video and remove it, we need to transmit these informations to the other pods in the same order
-  * The requests are grouped with a limit: if an user uploads 100 videos at a time, the information could be propagated in a few hours to do not make too big requests
+  * The requests are grouped with a limit: if a user uploads 100 videos at a time, the information could be propagated in a few hours to do not make too big requests
  * If a grouped request fails the score is decreased by x points
  * If a grouped request is a success the score is increased by x points
  * The maximum of points would be defined
@@ -56,8 +56,8 @@
  * A pod has different user accounts that can upload videos
  * All pods have an index of all videos of the network (name, origin pod url, small description, uploader username, magnet Uri, thumbnail name, created date and the thumbnail file). For example, a test with 1000000 videos with alphanum characters and the following lengths: name = 50, author = 50, url = 25, description = 250, magnerUri = 200, thumbnail name = 50 has a mongodb size of ~ 4GB. To this, we add 1 000 000 thumbnails of 5-15 KB so 15GB maximum
  * After having uploaded a video, the server seeds it, adds the meta data in its database and makes a secure request to all of its friends
-  * If an user wants to watch a video, he asks its pod the magnetUri and the frontend adds the torrent (with WebTorrent), creates the HTML5 video tag and streams the file into it
+  * If a user wants to watch a video, he asks its pod the magnetUri and the frontend adds the torrent (with WebTorrent), creates the HTML5 video tag and streams the file into it
-  * An user watching a video seeds it too (bittorent) so another user who is watching the same video can get the data from the origin server and the user 1 (etc)
+  * A user watching a video seeds it too (bittorent) so another user who is watching the same video can get the data from the origin server and the user 1 (etc)
 ## Ideas
diff --git a/README.md b/README.md
index c5911bc6d..1a3470711 100644
--- a/README.md
+++ b/README.md
@@ -189,7 +189,7 @@ See [ARCHITECTURE.md](https://github.com/Chocobozzz/PeerTube/blob/master/ARCHITE
    * Each server of a network has a list of all other servers of this network
    * When a new installed server wants to join a network, it just has to get the servers list through a server that is already in the network and tell "Hi I'm new in the network, communicate with me and share me your servers list please". Then the server will "make friend" with each server of this list
    * Each server has its own users who query it (search videos, where the torrent URI of this specific video is...)
-    * If an user upload a video, the server seeds it and sends the video informations (name, short description, torrent URI...) to each server of the network
+    * If a user upload a video, the server seeds it and sends the video informations (name, short description, torrent URI...) to each server of the network
    * Each server has a RSA key to encrypt and sign communications with other servers
  * A server is a tracker responsible for all the videos uploaded in it
  * Even if nobody watches a video, it is seeded by the server where the video was uploaded
diff --git a/support/doc/server/code.md b/support/doc/server/code.md
index d49d120e9..351461242 100644
--- a/support/doc/server/code.md
+++ b/support/doc/server/code.md
@@ -49,7 +49,7 @@ The `NODE_ENV=test` is set to speed up communications between pods (see [constan
 `npm run help` give you all available commands.
-If you want to test the decentralization feature, you can easily run 3 pods by runnin `npm run play`. The pods password are `test1`, `test2` and `test3`.
+If you want to test the decentralization feature, you can easily run 3 pods by running `npm run play`. The pods password are `test1`, `test2` and `test3`.
 ## Architecture
@@ -64,9 +64,9 @@ The seperate Electron process has the goal to seed videos through WebRTC because
 ![Architecture scheme](https://github.com/Chocobozzz/PeerTube/blob/master/support/doc/server/upload-video.png)
-When an user upload a video, the rest API asks the Electron process to seed it (communicate with IPC) and then adds it to its Mongo database.
+When a user upload a video, the rest API asks the Electron process to seed it (communicate with IPC) and then adds it to its Mongo database.
-If an user wants to watch the video, the tracker will indicate all other users that are watching the video + the Electron process.
+If a user wants to watch the video, the tracker will indicate all other users that are watching the video + the Electron process.
 ## Newcomers

diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index c7779000d..78a914abc 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md
@@ -5,7 +5,7 @@ Interesting in contributing? Awesome :)
5	Quick Links:	5	Quick Links:
6		6
7	* [Give your feedback](#give-your-feedback)	7	* [Give your feedback](#give-your-feedback)
8	* [Develop on the Server side}(#develop-on-the-server-side)	8	* [Develop on the Server side](#develop-on-the-server-side)
9	* [Develop on the Client side](#develop-on-the-client-side)	9	* [Develop on the Client side](#develop-on-the-client-side)
10	* [Write documentation](#write-documentation)	10	* [Write documentation](#write-documentation)
11		11


diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index 65dd5b49d..1454f9427 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md
@@ -42,9 +42,9 @@
42	* All the requests are retried if they failed	42	* All the requests are retried if they failed
43	* The requests are made at regular intervals to all pods of the network with a limit of parallel requests: if there are 1000 pods in the networks, the server won't make more than 10 requests in parallel	43	* The requests are made at regular intervals to all pods of the network with a limit of parallel requests: if there are 1000 pods in the networks, the server won't make more than 10 requests in parallel
44	* If there are no informations to send (no video addition/removal), no requests are made	44	* If there are no informations to send (no video addition/removal), no requests are made
45	* The requests are grouped: for example if the interval is 1 hour and an user upload 2 videos there will be only 1 request that contains the 2 videos informations	45	* The requests are grouped: for example if the interval is 1 hour and a user$ upload 2 videos there will be only 1 request that contains the 2 videos informations
46	* The requests in the group are ordered: if an user add a video and remove it, we need to transmit these informations to the other pods in the same order	46	* The requests in the group are ordered: if a user add a video and remove it, we need to transmit these informations to the other pods in the same order
47	* The requests are grouped with a limit: if an user uploads 100 videos at a time, the information could be propagated in a few hours to do not make too big requests	47	* The requests are grouped with a limit: if a user uploads 100 videos at a time, the information could be propagated in a few hours to do not make too big requests
48	* If a grouped request fails the score is decreased by x points	48	* If a grouped request fails the score is decreased by x points
49	* If a grouped request is a success the score is increased by x points	49	* If a grouped request is a success the score is increased by x points
50	* The maximum of points would be defined	50	* The maximum of points would be defined
@@ -56,8 +56,8 @@
56	* A pod has different user accounts that can upload videos	56	* A pod has different user accounts that can upload videos
57	* All pods have an index of all videos of the network (name, origin pod url, small description, uploader username, magnet Uri, thumbnail name, created date and the thumbnail file). For example, a test with 1000000 videos with alphanum characters and the following lengths: name = 50, author = 50, url = 25, description = 250, magnerUri = 200, thumbnail name = 50 has a mongodb size of ~ 4GB. To this, we add 1 000 000 thumbnails of 5-15 KB so 15GB maximum	57	* All pods have an index of all videos of the network (name, origin pod url, small description, uploader username, magnet Uri, thumbnail name, created date and the thumbnail file). For example, a test with 1000000 videos with alphanum characters and the following lengths: name = 50, author = 50, url = 25, description = 250, magnerUri = 200, thumbnail name = 50 has a mongodb size of ~ 4GB. To this, we add 1 000 000 thumbnails of 5-15 KB so 15GB maximum
58	* After having uploaded a video, the server seeds it, adds the meta data in its database and makes a secure request to all of its friends	58	* After having uploaded a video, the server seeds it, adds the meta data in its database and makes a secure request to all of its friends
59	* If an user wants to watch a video, he asks its pod the magnetUri and the frontend adds the torrent (with WebTorrent), creates the HTML5 video tag and streams the file into it	59	* If a user wants to watch a video, he asks its pod the magnetUri and the frontend adds the torrent (with WebTorrent), creates the HTML5 video tag and streams the file into it
60	* An user watching a video seeds it too (bittorent) so another user who is watching the same video can get the data from the origin server and the user 1 (etc)	60	* A user watching a video seeds it too (bittorent) so another user who is watching the same video can get the data from the origin server and the user 1 (etc)
61		61
62	## Ideas	62	## Ideas
63		63


diff --git a/README.md b/README.md index c5911bc6d..1a3470711 100644 --- a/README.md +++ b/README.md
@@ -189,7 +189,7 @@ See [ARCHITECTURE.md](https://github.com/Chocobozzz/PeerTube/blob/master/ARCHITE
189	* Each server of a network has a list of all other servers of this network	189	* Each server of a network has a list of all other servers of this network
190	* When a new installed server wants to join a network, it just has to get the servers list through a server that is already in the network and tell "Hi I'm new in the network, communicate with me and share me your servers list please". Then the server will "make friend" with each server of this list	190	* When a new installed server wants to join a network, it just has to get the servers list through a server that is already in the network and tell "Hi I'm new in the network, communicate with me and share me your servers list please". Then the server will "make friend" with each server of this list
191	* Each server has its own users who query it (search videos, where the torrent URI of this specific video is...)	191	* Each server has its own users who query it (search videos, where the torrent URI of this specific video is...)
192	* If an user upload a video, the server seeds it and sends the video informations (name, short description, torrent URI...) to each server of the network	192	* If a user upload a video, the server seeds it and sends the video informations (name, short description, torrent URI...) to each server of the network
193	* Each server has a RSA key to encrypt and sign communications with other servers	193	* Each server has a RSA key to encrypt and sign communications with other servers
194	* A server is a tracker responsible for all the videos uploaded in it	194	* A server is a tracker responsible for all the videos uploaded in it
195	* Even if nobody watches a video, it is seeded by the server where the video was uploaded	195	* Even if nobody watches a video, it is seeded by the server where the video was uploaded


diff --git a/support/doc/server/code.md b/support/doc/server/code.md index d49d120e9..351461242 100644 --- a/support/doc/server/code.md +++ b/support/doc/server/code.md
@@ -49,7 +49,7 @@ The `NODE_ENV=test` is set to speed up communications between pods (see [constan
49		49
50	`npm run help` give you all available commands.	50	`npm run help` give you all available commands.
51		51
52	If you want to test the decentralization feature, you can easily run 3 pods by runnin `npm run play`. The pods password are `test1`, `test2` and `test3`.	52	If you want to test the decentralization feature, you can easily run 3 pods by running `npm run play`. The pods password are `test1`, `test2` and `test3`.
53		53
54		54
55	## Architecture	55	## Architecture
@@ -64,9 +64,9 @@ The seperate Electron process has the goal to seed videos through WebRTC because
64		64
65	![Architecture scheme](https://github.com/Chocobozzz/PeerTube/blob/master/support/doc/server/upload-video.png)	65	![Architecture scheme](https://github.com/Chocobozzz/PeerTube/blob/master/support/doc/server/upload-video.png)
66		66
67	When an user upload a video, the rest API asks the Electron process to seed it (communicate with IPC) and then adds it to its Mongo database.	67	When a user upload a video, the rest API asks the Electron process to seed it (communicate with IPC) and then adds it to its Mongo database.
68		68
69	If an user wants to watch the video, the tracker will indicate all other users that are watching the video + the Electron process.	69	If a user wants to watch the video, the tracker will indicate all other users that are watching the video + the Electron process.
70		70
71	## Newcomers	71	## Newcomers
72		72