Date: prev next · Thread: first prev next last
2021 Archives by date, by thread · List index


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+unsubscribe@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.