search

web3-storage / web3.storage

DEPRECATED ⁂ The simple file storage service for IPFS & Filecoin
https://web3.storage
Other
501 stars 122 forks source link

Token scoping #314

Open dchoi27 opened 3 years ago

dchoi27 commented 3 years ago

Issues related to how tokens are scoped (permissions, how users interact with multiple tokens, etc.).

dchoi27 commented 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!

alanshaw commented 3 years ago

Problem

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:

  1. Applications ask users to sign up at web3.storage and obtain a token for use. This is terrible UX.
  2. Application developers create their own API and proxy uploads from their users. This is a lot of work and means that content is funneled through a centralized point that is maybe not as well prepared for the amount of traffic it may receive.

Proposal: Token Scoping and Token Management API

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

Scopes

Public permissions are implied.

  1. Admin
    • Create user token
    • Delete user token
    • List user tokens
    • Upload
    • List all uploads
    • Delete any upload
  2. User
  3. Legacy (existing tokens already created)
    • Upload
    • List all uploads
    • Delete owned upload

Work Involved

Alternative

Leverage 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!

atopal commented 3 years ago

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.

dchoi27 commented 3 years ago

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.

mikeal commented 3 years ago

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.

ryanwolhuter commented 3 years ago

Hey everyone 👋 is anyone working on this currently? I would love to get involved with building the solution here.

farahats9 commented 3 years ago

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.

olizilla commented 2 years ago

@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.

olizilla commented 2 years ago

@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?

farahats9 commented 2 years ago

@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.

ryanwolhuter commented 2 years ago

@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.

codewithpom commented 2 years ago

Any updated on it ?

dchoi27 commented 2 years ago

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.

orvn commented 2 years ago

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.