diff options
| -rw-r--r-- | README.md | 17 |
1 files changed, 9 insertions, 8 deletions
| @@ -172,17 +172,18 @@ See [ARCHITECTURE.md](https://github.com/Chocobozzz/PeerTube/blob/master/ARCHITE | |||
| 172 | 172 | ||
| 173 | ### Backend | 173 | ### Backend |
| 174 | 174 | ||
| 175 | * The backend whould be a REST API | 175 | * The backend is a REST API |
| 176 | * Servers would communicate with each others with it | 176 | * Servers communicate with each others through it |
| 177 | * Each server of a network has a list of all other servers of the network | 177 | * A network is composed by servers that communicate between them |
| 178 | * When a new installed server wants to join a network, it just has to get the list of the servers via one server and tell them "Hi I'm new in the network, communicate with me too please" | 178 | * Each server of a network has a list of all other servers of this network |
| 179 | * 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 | ||
| 179 | * Each server has its own users who query it (search videos, where the torrent URI of this specific video is...) | 180 | * Each server has its own users who query it (search videos, where the torrent URI of this specific video is...) |
| 180 | * Server begins to seed and sends to the other servers of the network the video information (name, short description, torrent URI) of a new uploaded video | 181 | * 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 |
| 181 | * Each server has a RSA key to encrypt and sign communications with other servers | 182 | * Each server has a RSA key to encrypt and sign communications with other servers |
| 182 | * A server is a tracker responsible for all the videos uploaded in it | 183 | * A server is a tracker responsible for all the videos uploaded in it |
| 183 | * Even if nobody watches a video, it is seeded by the server where the video was uploaded | 184 | * Even if nobody watches a video, it is seeded by the server where the video was uploaded |
| 184 | * A server would run webtorrent-hybrid to be a bridge with webrtc/standard bittorrent protocol | ||
| 185 | * A network can live and evolve by expelling bad pod (with too many downtimes for example) | 185 | * A network can live and evolve by expelling bad pod (with too many downtimes for example) |
| 186 | * A server **would** run webtorrent-hybrid to be a bridge with webrtc/standard bittorrent protocol | ||
| 186 | 187 | ||
| 187 | See the ARCHITECTURE.md for more informations. Do not hesitate to give your opinion :) | 188 | See the ARCHITECTURE.md for more informations. Do not hesitate to give your opinion :) |
| 188 | 189 | ||
| @@ -204,5 +205,5 @@ Here are some simple schemes: | |||
| 204 | 205 | ||
| 205 | ### Frontend | 206 | ### Frontend |
| 206 | 207 | ||
| 207 | There would be a simple frontend (Bootstrap, AngularJS) but since the backend is a REST API anybody could build a frontend (Web application, desktop application...). | 208 | There already is a frontend (Angular 2) but the backend is a REST API so anybody can build a frontend (Web application, desktop application...). |
| 208 | The backend uses bittorrent protocol, so users could use their favorite bittorrent client to download/play the video after having its torrent URI. | 209 | The backend uses bittorrent protocol, so users could use their favorite bittorrent client to download/play the video with its torrent URI. |