Hi @elek,
I agree with Nick and see a 4th option that you may want to consider for your PR.
The 4th option is based on the information in this thread:
https://forum.rclone.org/t/tardigrade-storj-vs-s3-remote-for-the-same/26574
indicating that StorJ may fully support the rclone S3 backend hereby eliminating the need for a specific StorJ backend.
Proposed steps for option 4:
- Verify full StorJ S3 compatibility by running the automated S3 backend test against an S3 TestDrive having StorJ as endpoint. The detailed steps are here: https://github.com/rclone/rclone/blob/master/CONTRIBUTING.md#backend-testing
- Add StorJ to the list of S3 providers on this page:
https://github.com/rclone/rclone/blob/master/docs/content/s3.md - Make a deprecation warning and point to the S3 replacement on this page:
https://github.com/rclone/rclone/blob/master/docs/content/tardigrade.md - Eventually (sometime in the future), remove all code and documentation for Tardigrade.
Benefits:
- StorJ users get a better rclone backend due to the higher number of users (and developers) on the S3 backend.
- rclone complexity is slightly reduced by having fewer specialised backends. This eases maintenance which typically leads to increased overall robustness/stability.
Drawbacks:
- None that I can see (with my very limited knowledge of Tardigrade/StorJ)