[evilclats]

Last time I checked the way that webtorrent/peertube queries for peers watching same video is centralised over websockets to a a select few webtorrent trackers, I think theirs only 2 or 3 running, meaning if you wanted to take down peertubes p2p functionality all you would have to hit would be their webtorrent trackers with a ddos and the platform would go down, I'm not 100% about sibil protections but I do know that peertubes webtorrent trackers verify the structure of an announce, and if it is in invalid format bans you from the tracker, compared to the other webtorrent trackers which are more happy to accept something less strict as an announce

[southerntofu]

> over websockets to a a select few webtorrent trackers, I think theirs only 2 or 3 running

Maybe you're talking about STUN servers? There's only 2 hardcoded STUN servers for the moment [0] indeed, but that's only for WebRTC discovery and will be easy to fix. It does not prevent server-side redundancy because every peertube instance runs its own tracker, from my understanding on the protocol (let me know if i've got that wrong), but taking those STUN servers down would indeed prevent p2p seeding, except for publicly-routable clients (not behind NAT).

[0] https://github.com/Chocobozzz/PeerTube/issues/3177

[evilclats]

I'm reasonably confident that the protocol I was working with was json over websocket https://openwebtorrent.com/ tracker this was a few months ago now so peertube could be running something different So each peertube instance runs its own openwebtorrent compatible tracker, which then has its own protocol inforced at the wire level, compared to when i looked at the other openwebtorrent implementations depending on the server didn't enforce the wire format and you could send json over the wire, the trackers seemed to just be a sort of pubsub system where announces would get resent to other connected clients under the same infohash or whatever they used