From 82e624233f22eba0230383c7de8a9ed3b69791a6 Mon Sep 17 00:00:00 2001
From: Chocobozzz <florian.bigard@gmail.com>
Date: Fri, 7 Oct 2016 11:01:28 +0200
Subject: Update documentations now we use webseed instead of electron/webrtc

---
 .github/ISSUE_TEMPLATE.md           |   2 +-
 ARCHITECTURE.md                     |  10 +++-------
 README.md                           |  20 +++++++++-----------
 support/doc/server/code.md          |  14 ++++++--------
 support/doc/server/upload-video.png | Bin 58712 -> 56458 bytes
 5 files changed, 19 insertions(+), 27 deletions(-)

diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md
index c19c3cf8f..74ea70939 100644
--- a/.github/ISSUE_TEMPLATE.md
+++ b/.github/ISSUE_TEMPLATE.md
@@ -1,5 +1,5 @@
 <!--
-  Problem with the demonstration server? 
+  Problem with the demonstration server?
     -> Please retry in a few hours or send me directly an email: https://github.com/Chocobozzz
   Bug?
     -> Please check first you're running on the latest version of Firefox/Chromium
diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md
index 1454f9427..cc6864fac 100644
--- a/ARCHITECTURE.md
+++ b/ARCHITECTURE.md
@@ -5,7 +5,7 @@
   - **Network:** several servers communicating each others with this software compose a network
   - **Pod:** a server of the network (inspired from Diaspora, no really signification)
   - **Friend:** a pod that communicates with yours
-  - **Origin pod:** the pod on which the video was uploaded and which is seeding the video
+  - **Origin pod:** the pod on which the video was uploaded and which is seeding (throught WebSeed protocol) the video
   - **Make friend:** the action of a server which will join a network (and so become friend with all pods that compose this network)
 
 ## Base
@@ -55,9 +55,9 @@
   * A pod has an administrator that can add/remove users, make friends and quit friends
   * 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
+  * After having uploaded a video, the server seeds it (WebSeed protocol), adds the meta data in its database and makes a secure request to all of its friends
   * 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
-  * 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)
+  * A user watching a video seeds it too (BitTorrent) so another user who is watching the same video can get the data from the origin server and the user 1 (etc)
 
 ## Ideas
 
@@ -65,10 +65,6 @@
    user asks its pod -> user pod asks origin video pod -> origin video pod responds with the informations -> user pod responds to the user (and puts in cache the informations ?). We could extend this scheme with other informations
   * Redondance: if the origin pod is down, the video is not accessible anymore (no tracker/seeds). We could imagine a redondance between pods that keep seeding the video
   * Server could transcode the video to lower qualities (cost in CPU and disk space)
-  * Server could seed at the demand: for now the server seeds all the videos but it has two drawbacks:
-    - Seeding has a cost (if a pod has 1000 videos it could be an issue)
-    - After a restart the server has to reseed all the videos (with 1000 videos it could long)
-  If this solution is choosen, the frontend has to notify the origin pod that it has to seed the video
   * Add subtitles to videos
   * Avoid stocking friends URL schemes (http/https)
 
diff --git a/README.md b/README.md
index 777df6d7d..f9d60855a 100644
--- a/README.md
+++ b/README.md
@@ -121,14 +121,13 @@ Thanks to [WebTorrent](https://github.com/feross/webtorrent), we can make P2P (t
 
 #### Debian
 
-  * Install NodeJS 4.2: [https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions](https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions)
+  * Install NodeJS 4.x (actual LTS): [https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions](https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions)
   * Add jessie backports to your *source.list*: http://backports.debian.org/Instructions/
   * Run:
 
         # apt-get update
-        # apt-get install ffmpeg mongodb openssl xvfb curl sudo git build-essential libgtk2.0-0 libgconf-2-4 libnss3 libasound2 libxtst6 libxss1 libnotify-bin
+        # apt-get install ffmpeg mongodb
         # npm install -g npm@3
-        # npm install -g electron
 
 #### Other distribution... (PR welcome)
 
@@ -201,9 +200,8 @@ See [ARCHITECTURE.md](https://github.com/Chocobozzz/PeerTube/blob/master/ARCHITE
     * 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
+  * Even if nobody watches a video, it is seeded by the server (throught [WebSeed protocol](http://www.bittorrent.org/beps/bep_0019.html)) where the video was uploaded
   * A network can live and evolve by expelling bad pod (with too many downtimes for example)
-  * A server **would** run webtorrent-hybrid to be a bridge with webrtc/standard bittorrent protocol
 
 See the ARCHITECTURE.md for more informations. Do not hesitate to give your opinion :)
 
@@ -211,19 +209,19 @@ Here are some simple schemes:
 
 <p align="center">
 
-<img src="https://lutim.cpy.re/Q7mnNdJP" alt="Decentralized" />
+<img src="https://lutim.cpy.re/isWwz8tt" alt="Decentralized" />
 
-<img src="https://lutim.cpy.re/0riSzAp1" alt="Watch a video" />
+<img src="https://lutim.cpy.re/VLheltQk" alt="Watch a video" />
 
-<img src="https://lutim.cpy.re/OzMSOtxG" alt="Watch a P2P video" />
+<img src="https://lutim.cpy.re/worHQwKv" alt="Watch a P2P video" />
 
-<img src="https://lutim.cpy.re/uVjNNRa9" alt="Join a network" />
+<img src="https://lutim.cpy.re/MyeS4q1g" alt="Join a network" />
 
-<img src="https://lutim.cpy.re/udTMqcb0" alt="Many networks"
+<img src="https://lutim.cpy.re/PqpTTzdP" alt="Many networks"
 
 </p>
 
 ### Frontend
 
 There already is a frontend (Angular 2) but the backend is a REST API so anybody can build a frontend (Web application, desktop application...).
-The backend uses bittorrent protocol, so users could use their favorite bittorrent client to download/play the video with its torrent URI.
+The backend uses BitTorrent protocol, so users could use their favorite BitTorrent client to download/play the video with its torrent URI.
diff --git a/support/doc/server/code.md b/support/doc/server/code.md
index 130d30136..652bd53df 100644
--- a/support/doc/server/code.md
+++ b/support/doc/server/code.md
@@ -9,8 +9,7 @@ The server is a web server developed with [NodeJS](https://nodejs.org)/[Express]
   * [MongoDB](https://www.mongodb.com/) -> Database
   * [Express](http://expressjs.com) -> Web server framework
   * [Mongoose](http://mongoosejs.com/) -> MongoDB object modeling
-  * [WebTorrent](https://webtorrent.io/) -> BitTorrent over WebRTC
-  * [Electron](http://electron.atom.io/) -> To make WebRTC inside NodeJS
+  * [WebTorrent](https://webtorrent.io/) -> BitTorrent tracker and torrent creation
   * [Mocha](https://mochajs.org/) -> Test framework
 
 
@@ -45,7 +44,7 @@ Uses [JavaScript Standard Style](http://standardjs.com/).
   * Run MongoDB
   * Run `npm run dev` to compile the client and automatically run the server. If the client files are already compiled you can simply run `NODE_ENV=test node server`
 
-The `NODE_ENV=test` is set to speed up communications between pods (see [constants.js](https://github.com/Chocobozzz/PeerTube/blob/master/server/initializers/constants.js#L71)).
+The `NODE_ENV=test` is set to speed up communications between pods (see [constants.js](https://github.com/Chocobozzz/PeerTube/blob/master/server/initializers/constants.js)).
 
 `npm run help` gives you all available commands.
 
@@ -56,17 +55,16 @@ If you want to test the decentralization feature, you can easily run 3 pods by r
 
 The server is composed by:
 
-  * a REST API
+  * a REST API (throught Express framework)
   * a WebTorrent Tracker
-  * A separate Electron process
 
-The seperate Electron process has the goal to seed videos through WebRTC because WebRTC directly in NodeJS is not usable for now.
+A video is seeded by the server throught the [WebSeed](http://www.bittorrent.org/beps/bep_0019.html) protocol (HTTP).
 
 ![Architecture scheme](https://github.com/Chocobozzz/PeerTube/blob/master/support/doc/server/upload-video.png)
 
-When a user uploads 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 uploads a video, the rest API create the torrent file and then adds it to its Mongo database.
 
-If a 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 HTTP url for the WebSeed.
 
 ## Newcomers
 
diff --git a/support/doc/server/upload-video.png b/support/doc/server/upload-video.png
index b3a867a42..730e68cc4 100644
Binary files a/support/doc/server/upload-video.png and b/support/doc/server/upload-video.png differ
-- 
cgit v1.2.3