Hi Emiliano,
On Mon, 20 Dec 2021 at 22:52:39 +0100, Emiliano Vavassori wrote:
> some Directors would like to know Infra's team understanding around having a
> PeerTube instance hosted at TDF to serve the videos that are now served from
> elsewhere (e.g. the ones from the Conferences).
That came up several times last year, including in BoD+team calls and
LibOCon preparation calls. I argued last spring it sounded more like a
problem in search of a solution:
| […] what's the advantage of using PeerTube then? If the aim is to offer
| a YouTube-independent solution for our viewers, and if we have to serve
| it all ourselves, then a native <video/> element would do just just fine
| and be a lot simpler to manage. Playlists are possible too. The thing
| we'll loose is subscription and comments, but AFAICT our videos are not
| meant to be standalone; they're attached to blogposts or website/wiki
| pages.
|
| It's a bit like asking for full-fledged GitLab instance for a single
| read-only repository (no ACLs, no issue tracker, no wiki, no CI/CD, no
| nothing). Works, but clearly overkill :-)
ACLs and neat interface aside, the other nice thing about Peertube is
the ability to serve chunks in a peer-to-peer fashion. However this has
privacy implications which AFAICT have never been clarified:
| I'm not familiar with with the PeerTube internals, […] how is this
| scheme immune to Sybil attacks like any other typical DHT? (There are
| Sybil-resistant DHT implementations, but AFAICT those are typically used
| in anonymisation software not in torrent libraries).
|
| It seems to me that the attack vector is real — and quite different than
| us sending/forwarding users to a selected set of 3rd parties (eg, our
| mirror network, or resources from Twitter, YouTube, Google, whatever) —
| if we can't control where users are downloading from.
Will ask attendees tomorrow during the call, but FWIW here is where I
stand personally:
> To be more specific, we are interested in:
> 1 - the level of usefulness/likeliness you would see (totally needed, nice
> to have, completely useless, dangerous, counterproductive, etc.)
Overkill / useless in the way I foresee it being used: no P2P, no
complex ACLs, only embedded videos / playlists.
> 2 - the actual level of knowledge in supporting such instance ("no
> knowledge" to "we created the software, so we can do whatever we need to")
No prior knowledge.
> 3 - willingness to support it (don't want to/prefer not to/more than happy
> to do it)
It definitely has a use case but I don't think it's useful for TDF and
therefore am not thrilled to add more arguably unnecessary complexity on
our plate.
> 4 - Eventual (estimated) expenses in knowledge building;
No idea.
> 5 - Eventual (estimated) expenses for extra virtual
> hardware/bandwidth/workforce to implement and support such instance;
No exact cost on top of my head, but bandwidth would be on par with a
simpler solution serving videos natively, but with a non-negligible
overhead in terms of computer and human resources.
--
Guilhem.
--
To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy
