diff options
Diffstat (limited to 'README.md')
-rw-r--r-- | README.md | 101 |
1 files changed, 101 insertions, 0 deletions
diff --git a/README.md b/README.md new file mode 100644 index 000000000..5f44d1189 --- /dev/null +++ b/README.md | |||
@@ -0,0 +1,101 @@ | |||
1 | # PeTube | ||
2 | |||
3 | Prototype of a decentralized video streaming platform using P2P (bittorent) directly in the web browser with [webtorrent](https://github.com/feross/webtorrent). | ||
4 | |||
5 | [![js-standard-style](https://cdn.rawgit.com/feross/standard/master/badge.svg)](https://github.com/feross/standard) | ||
6 | |||
7 | ## Features | ||
8 | |||
9 | - [ ] Join a network | ||
10 | - [X] Generate a RSA key | ||
11 | - [X] Ask for the friend list of other pods and make friend with them | ||
12 | - [ ] Get the list of the videos owned by a pod when making friend with it | ||
13 | - [ ] Post the list of its own videos when making friend with another pod | ||
14 | - [X] Upload a video | ||
15 | - [X] Seed the video | ||
16 | - [X] Send the meta data to all other friends | ||
17 | - [X] Remove the video | ||
18 | - [X] List the videos | ||
19 | - [X] Search a video name (local index) | ||
20 | - [X] View the video in an HTML5 page with webtorrent | ||
21 | - [ ] Manage user accounts | ||
22 | - [ ] Inscription | ||
23 | - [ ] Connection | ||
24 | - [ ] Account rights (upload...) | ||
25 | - [ ] Make the network auto sufficient (eject bad pods etc) | ||
26 | - [ ] Manage API breaks | ||
27 | - [ ] Add "DDOS" security (check if a pod don't send too many requests for example) | ||
28 | |||
29 | ## Front compatibility | ||
30 | |||
31 | * Chromium | ||
32 | * Firefox (>= 42 for MediaSource support) | ||
33 | |||
34 | |||
35 | ## Usage | ||
36 | |||
37 | ### Dependencies | ||
38 | |||
39 | * NodeJS >= 0.12 | ||
40 | * Grunt-cli (npm install -g grunt-cli) | ||
41 | * OpenSSL (cli) | ||
42 | * MongoDB | ||
43 | * xvfb-run (for electron) | ||
44 | |||
45 | ### Test It! | ||
46 | |||
47 | $ git clone https://github.com/Chocobozzz/PeerTube | ||
48 | $ cd PeopleTube | ||
49 | # npm install -g electron-prebuilt | ||
50 | $ npm install | ||
51 | $ npm start | ||
52 | |||
53 | ### Test with many 3 fresh nodes | ||
54 | $ scripts/clean_test.sh | ||
55 | $ scripts/run_servers.sh | ||
56 | |||
57 | Then you will can access to the three nodes at http://localhost:900{1,2,3}. If you call "make friends" on http://localhost:9002, the pod 2 and 3 will become friends. Then if you call "make friends" on http://localhost:9001 it will become friend with the pod 2 and 3 (check the configuration files). Then the pod will communicate with each others. If you add a video on the pod 3 you'll can see it on the pod 1 and 2 :) | ||
58 | |||
59 | ## Why | ||
60 | |||
61 | We can't build a FOSS video streaming alternatives to YouTube, Dailymotion, Vimeo... with a centralized software. | ||
62 | One organization alone cannot have enought money to pay bandwith and video storage of its server. | ||
63 | So we need to have a decentralized network (as [Diaspora](https://github.com/diaspora/diaspora) for example). | ||
64 | But it's not enought because one video could become famous and overload the server. | ||
65 | It's the reason why we need to use a P2P protocol to limit the server load. | ||
66 | Thanks to [webtorrent](https://github.com/feross/webtorrent), we can make P2P (thus bittorrent) inside the web browser right now. | ||
67 | |||
68 | ## Architecture | ||
69 | |||
70 | ### Backend | ||
71 | |||
72 | * The backend whould be a REST API | ||
73 | * Servers would communicate with each others with it | ||
74 | * Each server of a network has a list of all other servers of the network | ||
75 | * 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" | ||
76 | * Each server has its own users who query it (search videos, where the torrent URI of this specific video is...) | ||
77 | * 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 | ||
78 | * Each server has a RSA key to encrypt and sign communications with other servers | ||
79 | * A server is a tracker responsible for all the videos uploaded in it | ||
80 | * Even if nobody watches a video, it is seeded by the server where the video was uploaded | ||
81 | * A server would run webtorrent-hybrid to be a bridge with webrtc/standard bittorrent protocol | ||
82 | * A network can live and evolve by expelling bad pod (with too many downtimes for example) | ||
83 | |||
84 | See the ARCHITECTURE.md for more informations. Do not hesitate to give your opinion :) | ||
85 | |||
86 | Here are some simple schemes: | ||
87 | |||
88 | ![Decentralized](http://lutim.cpy.re/aV2pawRz) | ||
89 | |||
90 | ![Watch a video](http://lutim.cpy.re/AlOeoVPi) | ||
91 | |||
92 | ![Watch a video P2P](http://lutim.cpy.re/fb0JH6C3) | ||
93 | |||
94 | ![Join a network](http://lutim.cpy.re/ijuCgmpI) | ||
95 | |||
96 | ![Many networks](http://lutim.cpy.re/iz8mXHug) | ||
97 | |||
98 | ### Frontend | ||
99 | |||
100 | 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...). | ||
101 | The backend uses bittorent protocol, so users could use their favorite bittorent client to download/play the video after having its torrent URI. | ||