* feat: config option object_storage.max_attempts
Backblaze recommends to have a high amount of attempts since they've
designed their architecture so that it will return 5xx errors to
indicate that the client should do a new attempt.
https://www.backblaze.com/blog/b2-503-500-server-error/closes#6415
* Rephrase comment
---------
Co-authored-by: Chocobozzz <me@florianbigard.com>
Compat with text/html descriptions
Compat with SPDX for licences
Compat with missing sensitive attribute
Compat with missing tag attribute
Compat with missing video file magnet URI
Compat with missing streaming playlist segmentsSha256Url
Compat with optional comments/likes/dislikes/shares URI in video object
Add more debug logs when the object is not valid
* Comments and videos can be automatically tagged using core rules or
watched word lists
* These tags can be used to automatically filter videos and comments
* Introduce a new video comment policy where comments must be approved
first
* Comments may have to be approved if the user auto block them using
core rules or watched word lists
* Implement FEP-5624 to federate reply control policies
Breaking: YAML config `ip_view_expiration` is renamed `view_expiration`
Breaking: Views are taken into account after 10 seconds instead of 30
seconds (can be changed in YAML config)
Purpose of this commit is to get closer to other video platforms where
some platforms count views on play (mux, vimeo) or others use a very low
delay (instagram, tiktok)
We also want to improve the viewer identification, where we no longer
use the IP but the `sessionId` generated by the web browser. Multiple
viewers behind a NAT can now be able to be identified as independent
viewers (this method is also used by vimeo or mux)
* testing not removing old file and adding columb to db
* implement feature
* remove unnecessary config changes
* use only keptOriginalFileName, change keptOriginalFileName to keptOriginalFilename for consistency with with videoFile table, slight refactor with basename()
* save original video files to dedicated directory original-video-files
* begin implementing object storage (bucket) support
---------
Co-authored-by: chagai.friedlander <chagai.friedlander@fairkom.eu>
Co-authored-by: Ian <ian.kraft@hotmail.com>
Co-authored-by: Chocobozzz <me@florianbigard.com>
More efficient than the current one where instance is not fast enough to
send all viewers if a video becomes popular
The new protocol can be enabled by setting env
USE_VIEWERS_FEDERATION_V2='true'
Introduce a result field in View activity that contains the number of
viewers. This field is used by the origin instance to send the total
viewers on the video to remote instances. The difference with the
current protocol is that we don't have to send viewers individually to
remote instances.
There are 4 cases:
* View activity from federation on Remote Video -> instance replaces
all current viewers by a new viewer that contains the result counter
* View activity from federation on Local Video -> instance adds the
viewer without considering the result counter
* Local view on Remote Video -> instance adds the viewer and send it to
the origin instance
* Local view on Local Video -> instance adds the viewer
Periodically PeerTube cleanups expired viewers. On local videos, the
instance sends to remote instances a View activity with the result
counter so they can update their viewers counter for that particular
video
Chocobozzz
kontrollanten
soonsouth
chagai95