5 ms·

> Please don't install PeerTube for production on a small device behind a low bandwidth connection (example: a Raspberry PI behind your ADSL link) because it co

> Please don't install PeerTube for production on a small device behind a low bandwidth connection (example: a Raspberry PI behind your ADSL link) because it could slow down the fediverse. Sounds like PeerTube is vulnerable to a sorts of denial of service attack from bad actors that would join and then limit the bandwidth to extreme amounts. Hasn’t this been solved already in other P2P protocols? Couldn’t they have built upon an existing protocol that protected them against this?

amelius 8y ago
Regardless of that specific problem, it would be wise to build upon an existing protocol (e.g. IPFS), because it would help prevent future problems AND it would increase traction of federated content sharing. The more people use a single protocol, the more all applications benefit in latency, speed, availability; but also in future development.
- detaro 8y ago
  It wisely is building on existing protocols.
  - deleted 8y ago
    [deleted]
- maeln 8y ago
  It use ActivityPub for the federation part and WebTorrent (which just implement the BitTorrent protocol over websocket if I remember correctly). It is using already using existing protocol.
  - aiham 8y ago
    WebTorrent uses WebRTC, not WebSocket.
    - nathcd 8y ago
      This is the part that I find somewhat unfortunate about Peertube. This means that only ActivityPub clients that support WebRTC will be able to access Peertube media. Right now, I think this basically means just modern web browsers. It bothers me somewhat that an early, potentially major ActivityPub service is going to limit full functionality to the few existing major web browsers. That's the opposite of what I want from a federated protocol. (Someone correct me if I've got any of this wrong.) Regardless, Peertube seems awesome, and I hope we keep seeing more and more services built on ActivityPub.
      - rigelk 8y ago
        ActivityPub defines federation messages server to server and client to server. It is not a protocol per se, and rather a message exchange standard, which could perfectly be used only between servers, as is the case with federation of videos between PeerTube instances, and more recently for video comment feeds, that can interact with the larger fediverse (Hubzilla and Mastodon so far were tested). In no way it defines how you access media. That is defined by the use of WebRTC, which is supported by a growing number of browsers, and anyway provides a fallback to direct streaming (HTTP), so that any browser can interact.
        nathcd 8y ago
        > and anyway provides a fallback to direct streaming (HTTP), so that any browser can interact. Ah, that's awesome. That definitely assuages my fears somewhat. > [ActivityPub] In no way it defines how you access media. ActivityStreams (which ActivityPub builds on) does define an attachment property for messages [1]. Is this not a standard mechanism for clients to access ActivityPub media (via the attachment's type and url)? [1] https://www.w3.org/TR/activitystreams-vocabulary/#dfn-attachment https://www.w3.org/TR/activitystreams-vocabulary/#dfn-attach...
        rigelk 8y ago
        It is, but I don't see how web browsers would need to interact directly with ActivityPub. That's just a way to settle on a json structure everyone will be using in their web application (that acts as AP client), as is the case in Mastodon. Here with PeerTube the client interface doesn't interact with AP to watch videos or get them. It just requests the list directly to the server.
- gnarbarian 8y ago
  https://d.tube https://d.tube uses ipfs
- dingdingdang 8y ago
  This issue (i.e. not building upon an existing protocols such as IPFS or bit torrent tech) is persistent within the alt-net / distributed-net community and means that MANY services have fickle/hacked-together (in the bad way) feel to them. Even stuff like Riot.im (which is built on top of the Matrix protocol) has a sluggish/react-js-overload feel to it.. plus the deep&wide stack makes it incredibly hard to understand/trust the system in a meaningful way. Also, I believe that part reason for the success of Hacker News and Reddit is largely their extremely simple, non-intrusive and non-animated interfaces - making flashy front-ends for distributed-net apps is a lost cause. Bittorrent took off because the tech was right; not because of a animated web interface that could correctly scale to mobile.
  - Arathorn 8y ago
    So speaking from the Riot/Matrix perspective, this is a really interesting phenomenon which we are painfully aware of. For context: we built centralised comms apps before creating Matrix. So we have a direct side by side comparison, and reckon it’s about 6x more effort to do the decentralised equivalent. On the UX side, our centralised apps were actually pretty polished and lightweight - sadly they are gone now (hence in part Matrix), but you can get an idea from stuff like https://web.archive.org/web/20170102145839/http://blah.com/ https://web.archive.org/web/20170102145839/http://blah.com/. So, how come decentralised apps can end up with worse UX than their centralised equivalents? My theory is: * Harder tech means that more resources get focused on the decentralisation bit * Harder to find UI/UX designers who understand the decentralisation requirements (although this is changing thanks to blockchain hype) * Decentralised early users tend to be geeky and push the product in a geeky direction But the key thing is that pre-decentralisation we probably had a 1:3 ratio of backend to frontend work. Then in Matrix it’s like 1:1, and the dilution on the frontend notices. That said, this can be fixed, and obviously it’s critical to Riot to fix it. We’ve contracted a proper UI/UX designer at last a few weeks ago and are hunting for more frontend devs. And evidence it can work: a good example of a decentralised project with decent UX is Mastodon.
    - Arathorn 8y ago
      (just to be clear: I’m responding to the “UX of decentralised apps is crap” bit of the parent post rather than “build on existing protocols”, given peertube and riot and mastodon etc all build on well defined protocols.)
kuzko_topia 8y ago
What's more it's a bit sad that only a small part of the content can't be served by those small peers making them useful instead of harmful to the network...
maeln 8y ago
The Tor network does some network metric on each Tor relay and give them a weight to each node based on their performance. It's not flawless but implementing something similar in WebTorrent might be possible and mitigate this form of attacks.
- woah 8y ago
  If their goal is to be "decentralized" that might not fit the bill (depending on your definition of decentralized). I wouldn't consider Tor to be decentralized.
nugi 8y ago
There goes my primary use case. Small devices behind crappy connections is most people streaming video ime.

amelius 8y ago

Regardless of that specific problem, it would be wise to build upon an existing protocol (e.g. IPFS), because it would help prevent future problems AND it would increase traction of federated content sharing. The more people use a single protocol, the more all applications benefit in latency, speed, availability; but also in future development.

detaro 8y ago
It wisely is building on existing protocols.
- deleted 8y ago
  [deleted]
maeln 8y ago
It use ActivityPub for the federation part and WebTorrent (which just implement the BitTorrent protocol over websocket if I remember correctly). It is using already using existing protocol.
- aiham 8y ago
  WebTorrent uses WebRTC, not WebSocket.
  - nathcd 8y ago
    This is the part that I find somewhat unfortunate about Peertube. This means that only ActivityPub clients that support WebRTC will be able to access Peertube media. Right now, I think this basically means just modern web browsers. It bothers me somewhat that an early, potentially major ActivityPub service is going to limit full functionality to the few existing major web browsers. That's the opposite of what I want from a federated protocol. (Someone correct me if I've got any of this wrong.) Regardless, Peertube seems awesome, and I hope we keep seeing more and more services built on ActivityPub.
    - rigelk 8y ago
      ActivityPub defines federation messages server to server and client to server. It is not a protocol per se, and rather a message exchange standard, which could perfectly be used only between servers, as is the case with federation of videos between PeerTube instances, and more recently for video comment feeds, that can interact with the larger fediverse (Hubzilla and Mastodon so far were tested). In no way it defines how you access media. That is defined by the use of WebRTC, which is supported by a growing number of browsers, and anyway provides a fallback to direct streaming (HTTP), so that any browser can interact.
      - nathcd 8y ago
        > and anyway provides a fallback to direct streaming (HTTP), so that any browser can interact. Ah, that's awesome. That definitely assuages my fears somewhat. > [ActivityPub] In no way it defines how you access media. ActivityStreams (which ActivityPub builds on) does define an attachment property for messages [1]. Is this not a standard mechanism for clients to access ActivityPub media (via the attachment's type and url)? [1] https://www.w3.org/TR/activitystreams-vocabulary/#dfn-attachment https://www.w3.org/TR/activitystreams-vocabulary/#dfn-attach...
        rigelk 8y ago
        It is, but I don't see how web browsers would need to interact directly with ActivityPub. That's just a way to settle on a json structure everyone will be using in their web application (that acts as AP client), as is the case in Mastodon. Here with PeerTube the client interface doesn't interact with AP to watch videos or get them. It just requests the list directly to the server.
gnarbarian 8y ago
https://d.tube https://d.tube uses ipfs
dingdingdang 8y ago
This issue (i.e. not building upon an existing protocols such as IPFS or bit torrent tech) is persistent within the alt-net / distributed-net community and means that MANY services have fickle/hacked-together (in the bad way) feel to them. Even stuff like Riot.im (which is built on top of the Matrix protocol) has a sluggish/react-js-overload feel to it.. plus the deep&wide stack makes it incredibly hard to understand/trust the system in a meaningful way. Also, I believe that part reason for the success of Hacker News and Reddit is largely their extremely simple, non-intrusive and non-animated interfaces - making flashy front-ends for distributed-net apps is a lost cause. Bittorrent took off because the tech was right; not because of a animated web interface that could correctly scale to mobile.
- Arathorn 8y ago
  So speaking from the Riot/Matrix perspective, this is a really interesting phenomenon which we are painfully aware of. For context: we built centralised comms apps before creating Matrix. So we have a direct side by side comparison, and reckon it’s about 6x more effort to do the decentralised equivalent. On the UX side, our centralised apps were actually pretty polished and lightweight - sadly they are gone now (hence in part Matrix), but you can get an idea from stuff like https://web.archive.org/web/20170102145839/http://blah.com/ https://web.archive.org/web/20170102145839/http://blah.com/. So, how come decentralised apps can end up with worse UX than their centralised equivalents? My theory is: * Harder tech means that more resources get focused on the decentralisation bit * Harder to find UI/UX designers who understand the decentralisation requirements (although this is changing thanks to blockchain hype) * Decentralised early users tend to be geeky and push the product in a geeky direction But the key thing is that pre-decentralisation we probably had a 1:3 ratio of backend to frontend work. Then in Matrix it’s like 1:1, and the dilution on the frontend notices. That said, this can be fixed, and obviously it’s critical to Riot to fix it. We’ve contracted a proper UI/UX designer at last a few weeks ago and are hunting for more frontend devs. And evidence it can work: a good example of a decentralised project with decent UX is Mastodon.
  - Arathorn 8y ago
    (just to be clear: I’m responding to the “UX of decentralised apps is crap” bit of the parent post rather than “build on existing protocols”, given peertube and riot and mastodon etc all build on well defined protocols.)

kuzko_topia 8y ago

What's more it's a bit sad that only a small part of the content can't be served by those small peers making them useful instead of harmful to the network...

maeln 8y ago

The Tor network does some network metric on each Tor relay and give them a weight to each node based on their performance. It's not flawless but implementing something similar in WebTorrent might be possible and mitigate this form of attacks.

woah 8y ago
If their goal is to be "decentralized" that might not fit the bill (depending on your definition of decentralized). I wouldn't consider Tor to be decentralized.

nugi 8y ago

There goes my primary use case. Small devices behind crappy connections is most people streaming video ime.