Open dchoi27 opened 3 years ago
@alanshaw know you had some thoughts related to token permissions, feel free to make a new issue and add to this epic!
At the moment, developers building web applications are likely to bundle a Web3.Storage token together with the app. This allows users to interact directly with the Web3.Storage service from their browser. However it has some issues:
The alternatives to bundling a token currently are:
Developers simply have to implement an API in their app that creates "user" scoped tokens. It uses an "admin" scoped token to do this. The "user" token may be stored in local storage
for use by the web app. It is a centralized component of the user's app, but avoids token bundling, asking the user for a token and allows uploads listings that are filtered to the token that performed the upload.
This feature has been requested by users in: #371
Public permissions are implied.
scope
param that allows magic.link tokens to create "admin" or "user" scoped tokensLeverage magic.link's blockchain auth and allow authentication using metamask, allowing an account and token to be created on Web3.Storage entirely from the browser.
This flow requires users to install the metamask plugin which is a hurdle and may not be preferable to all dapp developers.
We should do this alternative also though!
My hunch is that the issue is having to run a back-end service at all. Browser only apps would still have to ship with the admin token or ask users to create a web3.storage account. That said, I'd say let's go for it, because the current practice is indeed problematic, even for those who want to run their own back-end as a service, and this proposals solves a problem for them.
How problematic is it for the developer to run a back-end service in-and-of-itself? Ideally they don't have to, but is most the value captured by allowing the user to directly send data to web3.storage rather than the back-end service touching the data? We should test this.
Another alternative to consider is to allow our users to give us their magic link application token to use instead of ours so that we authenticate their users in out backend. Then they wouldn’t need a backend at all, and we can add the user data from the token to each upload.
This only works if they are a magic link user, which would be a good recommendation at hackathons but won’t help with a lot of our partners.
This might be a great step forward in making nft.storage a “client” of web3.storage.
Hey everyone 👋 is anyone working on this currently? I would love to get involved with building the solution here.
I have been wondering about this too, it would be awesome if I could make a token that allows adding files and not delete existing files.
@farahats9 the good news is: that's how it works currently. We're not going to allow deleting via an API token until users are able to create scoped tokens, and tokens created before we supported scoping will never be able to delete. Tokens you create with web3.storage today can upload files and list all the uploads for an account.
@ryanwolhuter great! no one is working on this right now, as we are in the middle of an epic refactor to switch out our db, see: #388 which is blocking other things that would need to save state to the db. Are you keen to work on the token scoping issue specifically or are you interested in hacking on web3.storage more generally?
@olizilla thank you for the explanation, if the token cannot delete then its good enough for my use case. It would've been better if we can also control the "list" permission but for now its ok, I will encrypt the uploaded data anyways.
@olizilla I am keen on hacking in the most general sense! My project Ferry is using web3.storage right now to great success (finalists in HackFS) and we're super invested in growth here. I have permission to dedicate some of my work hours to helping out on building Web3.Storage, if you'll have me. I'd love to chat you about how I can be most helpful.
Any updated on it ?
Hey, we are kicking off work on implementing UCAN-based auth in Web3.Storage in the coming weeks. (https://github.com/web3-storage/web3.storage/issues/261#issuecomment-1004139752) This should handle the whole uploads side of token scopes out of the box, and then things like delete tokens can follow after.
For the scoping of tokens (here and #300), note that the Pinning Services API table retrieves using a single user-generated token. So if tokens become scoped and the user has multiple tokens, not all pins will be visible.
Issues related to how tokens are scoped (permissions, how users interact with multiple tokens, etc.).