Feature request: Ability to deny a request to download

[C4Phoenix]

For a project I'm working on I'd like to have longer lived 'protected' blobs persistently available. I was hoping to make an allow list for 'read access' based on a peerID . This way, if the ticket gets leaked the protection is not compromised.

I've tried to look for a way to implement this within the current api but it seems like it's not possible at the moment. I certenly could have overlooked something.

Having a Callback function that determines if a peerID is allowed to access a certain ticket would make this protocol applicable to a lot more applications I think.

I kindly request your opinion.

[rklaehn]

So what you want is some sort of access control callback based on the hash of the data?

Maybe the best way to do this would be in the store trait. For store read operations, have some sort of context, and then the store can decide based on that context if it wants to proceed or not.

I am currently working on multiprovider downloads, so there will be some major changes to the code base soon, and I can't promise anything very quickly. But I will keep it in mind.

Until then I think the best way to proceed would be to write a custom protocol that uses the iroh-blobs ALPN and reuses most of the code from iroh-blobs, but puts in an auth step. I know that is quite complex, so we have to do better in the future.

[rklaehn]

I did a big refactor of the blobs crate. Access control by client is now done via provider events. I guess I could add a similar mechanism for individual requests.

[C4Phoenix]

Yes a mechanism for allowing or denying sending of the data (even if it could not be decrypted) would be great. I'm looking thru the code now to see if it is possible yet, I think it can be done thru multiple addresses now but a more clean solution would indeed be to have a Callback on a event per blob basis I think.

Thanks for reaching out again after some time (and no response on my part). Keep up the good work, I appreciate it.

[rklaehn]

This would be trivially solved by adding a permit hook in the GetRequestReceived case of the ProviderEvent. But I don't want to make the case where everything is open slower, so that needs some work.

Related and would be a solution: #96

[C4Phoenix]

I've never done this kind of code optimization on Rust but I suspect that we could lean on the compiler to make the Callback code disappear if it's not being used. This would depend entirely on the way the api is implemented ofcourse. Im thinking only allowing one Callback function and only during construction of the handler to make sure its not too dynamic for the compiler.

Just wanted to propose another possible 'solution'. I can't judge if its a better idea then the one you've linked but it could be easier to implement.