RSS-Bridge
Only 16 bridges are available after installing RSS-Bridge with Docker !
Hello, the public instances of RSS-Bridge display lists of several hundred bridges e.g.: https://rssbridge.flossboxin.org.in/
While the docker image contains only 16 bridges only. There is no documentation to find or add the community list of additional bridges.
Why limit users to these 16 bridges?
How can we easily integrate the community bridges that are available in public bodies?
To activate all bridges, follow the instructions provided at https://rss-bridge.github.io/rss-bridge/For_Hosts/Whitelisting.html.
The default list of enabled bridges is in the default config.
We could show all bridges by default I guess. Needs deliberation
@tillcash I dont have this file, I dont have any files in mounted config. The instruction are very bad. To fix it, I had manualy download this file and mount it by hand.
i dont use docker much. too much complexity for my taste.
but yes instructions probably need improvement.
@tillcash I dont have this file, I dont have any files in mounted config.
The docker-compose section mentions it. Otherwise it is rather undocumented: You need to create a that you add as a volume called /config. You can drop custom bridges and configuration files that will be copy to the right place whenever you (re)start the container.
Copy the file config.default.ini.php into your volume. Rename it to config.ini.php. You can either enable all bridges by replace all lines starting with enabled_bridges[] = by a single line enabled_bridges[] = *. Or you can make a custom list of bridges.
pls someone improve the docker docs. perhaps add a
docker-compose.ymlfile?
@dvikan something like this? https://github.com/RSS-Bridge/rss-bridge?tab=readme-ov-file#install-with-docker-compose
We could show all bridges by default I guess. Needs deliberation
It's better to display all bridges by default. We can remove the volumes section from docker-compose.yml to simplify the setup, making it more user-friendly and providing all features upfront. Power users can still access volume settings and fine-tune configurations as needed.
im okay with enabling all bridges by default.
however, people who upgrade an existing installation might be negatively surprised by that.
but could write a note in release notes
It would also be beneficial to include options to block certain bridges. This feature would help those hosting public instances by allowing them to control which bridges are accessible, especially if only a few need to be blocked.
It would also be beneficial to include options to block certain bridges. This feature would help those hosting public instances by allowing them to control which bridges are accessible, especially if only a few need to be blocked.
+1. To do this, maybe the application could interpret a starting bang ! as disabling a named bridge? Rather than introducing a new and separate config option for this.
e.g.,
enabled_bridges[] = *
enabled_bridges[] = !YouTubeCommunityTabBridge
