With current Access Grants setting, downloads can only be limited by time.
However there are plausible use cases where a limit by the number of downloads would be a better fit for a customer.
Example use case could be a media professional who uses Tardigrade to make one of his movies available for a festival to download but is not interested in spreading his work further.
In such cases a limit by the number of downloads is an additional security step to make sure that a file can only be downloaded for a specific intended purpose.
Another reason for a limit by number is cost control. A time limit does not limit the number of downloads, thus if a link gets spreaded in an unintended way, it could result in hundreds and thousands of unwanted downloads which the customer would have to pay for. If a user can set a download limit, he can limit this financial risk very efficiently.
As last point if you look at sharing websites it is very common in the meantime that downloads can be restricted by the number of downloads, so the requested feature might simply be expected by Tardigrade users.
In a perfect world a user would be notified by email when the limit number of downloads has been reached and then he would be able to set a new limit, reset the limit or let it expire or maybe even switch between different limit type (time based / quantity based).
That´s great! I haven´t thought about this until now. I´ve always thought about the limit by number as a security measure and I really like it! But now, as a cost control, I like it even more. The only disadvantage I see is the “amount of time” it could required if someone doesn´t see that the limit number of downloads has been reached (until they set a new limit it could pass minutes or hours so sometimes this could make things more difficult and slower)
Here are my initial thoughts on where problems could arise with this proposal.
A timed access grant might work slightly better in this scenario.
The main issue, is that not all users who click “download” end up actually downloading it, and it may end up being partially downloaded. For whatever reason a users network drops and reconnects – this to the server could end up looking like two “download” requests.
The alternative would be here to instead set a cap on allocated bandwidth instead of a number of downloads. Of course tying this into the APIKey might be even worse for performance, since “size of the object” and “api key” are in different tables.
The main issue here would be performance. All writes to the database need to be distributed across a database cluster, so there’s a performance penalty to it. It would be possible to make it “per api key” feature, but it could add a ton of writes to api key (or some other table). This might lead to needing some additional caches making the system more complex.
Thanks for coming back to this and serious consideration.
Maybe it is not the best example, but I don’t think so. What does a festival do? They have to download the movie to their projector. I believe allowing a limited number of downloads work better than agreeing on specific time frames as to when the download has to take place.
I believe an option to limit the number of downloads is a valuable security option, which is very important for media creators to keep control over their work in such way as to how many times it can be downloaded so that sensitive content cannot spread further than originally intended.
I believe while sourcing links for my suggestions for Storj Labs business development that limiting the number of downloads was part of a security consideration of software for media professionals, but I did not find the link anymore.