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.


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

Reply via email to