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.