- * All the communications between pods are signed, encrypted with a RSA key and a symetric encryption in a POST request (body)
- * 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 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 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 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
- * A pod which receives a request checks if the signature corresponds to the pod it has in its database. Then, it decrypts the body (or ignores it if the signature is not valid) and process the requests in the same order
-
-### Actions on a pod
- * A pod is a websocket tracker which is responsible for all the video uploaded in it
- * 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
- * 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)
-
-## Ideas
-
- * A video could have more information (detailed description etc) that are not sent on other pods. The user who wants to see these informations has to ask its pod:
- 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)
-
-## Debate
-
- * Is an ex-friend should be blacklisted for the future?
- * Handle API breaks in a network. If a major update breaks the API: we need the entire network update to the same major version. We could specify a limit date (2, 3 weeks after the release?) after which all the updated pod would switch to the new version of the API. The non updated pod will then be ejected of the network because would not implement the new API
+ * All the communication between the instances are signed with [Linked Data
+ Signatures](https://w3c-dvcg.github.io/ld-signatures/) with the private key
+ of the account that authored the action.
+ * We use the [ActivityPub](https://www.w3.org/TR/activitypub/) protocol (only
+ server-server for now). Object models could be found in
+ [shared/models/activitypub
+ directory](/shared/models/activitypub).
+ * All the requests are retried several times if they fail.
+
+### Instance
+ * An instance has a websocket tracker which is responsible for all the video
+ uploaded in it.
+ * An instance has an administrator that can follow other instances.
+ * An instance can be configured to follow back automatically.
+ * An instance can blacklist other instances (only used in "follow back"
+ mode).
+ * An instance cannot choose which other instances follow it, but it can
+ decide to **reject all** followers.
+ * After having uploaded a video, the instance seeds it (WebSeed protocol).
+ * If a user wants to watch a video, they ask its instance the magnet URI and
+ the frontend adds the torrent (with WebTorrent), creates the HTML5 video
+ player and streams the file into it.
+ * A user watching a video seeds it too (BitTorrent). Thus another user who is
+ watching the same video can get the data from the origin server and other
+ users watching it.