mirror of
https://github.com/asapach/peerflix-server.git
synced 2026-04-25 06:35:48 +03:00
[GH-ISSUE #173] Built-in block list ? #356
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Coriou on GitHub (Nov 4, 2019).
Original GitHub issue: https://github.com/asapach/peerflix-server/issues/173
I think it'd be great to have sensible block list defaults. I've looked at the block list implementation in torrent-stream which is kinda meh.
I think it'd make sense to implement the block list at this application's level. I've prototyped an implementation using blocklist-ipsets which works nicely. It introduces no external dependencies and uses
torrent-stream's "block" feature.What I'm not sure about though is should we pull the IP list at each engine load (potentially overkill really) or do we have a script loading the IPs periodically to block and saving them to a file locally ?
Thoughts ?
Here's a demo implementation
@asapach commented on GitHub (Nov 5, 2019):
I'd rather keep it simple and let the users provide their own blocklist file. This could be done by convention: e.g. on start we look for the file called
~/.config/peerflix-server/blocklist; if it exists we parse it and pass totorrent-stream. Optionally we could watch for the file changes and update as necessary, if there is an external process which updates the file.@Coriou commented on GitHub (Nov 5, 2019):
Sounds good to me ! I'll work on it, maybe tomorrow, should be easy enough.
Should we ship a default blocklist ?
@asapach commented on GitHub (Nov 5, 2019):
Only if there is one which is relatively static and small.
@Coriou commented on GitHub (Nov 5, 2019):
Thought about a way of doing this, and all are really bad:
Most blocklists don't come as a list of IPs, but usually as ranges so the users would first need to parse those lists into an array of unique IPs
The IPs would need to be loaded one by one, potentially loading millions of IPs for each torrent-stream engine
I think a better way would be to implement it at the torrent-stream level actually ... I've mentioned it there, let's see