Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal inbox protocol #24

Open
Gozala opened this issue Dec 8, 2022 · 2 comments
Open

Proposal inbox protocol #24

Gozala opened this issue Dec 8, 2022 · 2 comments

Comments

@Gozala
Copy link
Collaborator

Gozala commented Dec 8, 2022

This is an idea that came up during the call today:

  • We already think of an account as just an email address that user owns
    • They can login and claim all the capabilities that were delegated to it
    • They can be delegated capabilities even when they aren't our user yet
  • What if we take fact that account is email address step further
    • Allow anyone to send you an upload without any authentication step
      curl -X PUT https://api.web3.storage/inbox/[email protected] -T file.txt
    • Upload like that ends up in user inbox
    • It's like expiring message it falls out after predetermined time unless accepted by the user
    • When something lands into inbox we send them an email
      • Email owner may not be our user yet, but they can become one because clicking a link onboards them (it's no different from login flow described in account protocol)
      • If email bounced, we can delete upload immediately
      • Email we send should also have "Stop bothering me" button so we don't allow unsolicited messages

Why do this ?

  1. This makes web3.storage the easiest way to get content online!
  2. This makes it possible to use web3.storage without UCANs or anything other than native HTTP stack
  3. Allows ppl to use service first than become a user as opposed to having to become a user first, removing all the hurdles

What not do this ?

  1. This could become a malware distribution mechanism
    • Perhaps we could mitigate this by keeping expiry short enough
      • If content is only served for 5 mins unless accepted by recipient
      • Recipient can accept within 7 days
@jchris
Copy link

jchris commented Dec 8, 2022

I think this was also in the context of @mikeal saying we could treat attestations by a site that the current session is owned by user with email [email protected] as enough to start the process you describe here. So I guess we might limit access to the PUT api to trusted users?

In the context of user-owned user-paid spaces (like w3ui default flow) maybe we could use the idea of a temporary space to allow users to upload and interact before they click the email link.

@Gozala
Copy link
Collaborator Author

Gozala commented Dec 8, 2022

I think this was also in the context of @mikeal saying we could treat attestations by a site that the current session is owned by user with email [email protected] as enough to start the process you describe here. So I guess we might limit access to the PUT api to trusted users?

It was in the context, however I was making a case that we don’t need that hurdle. As I mentioned in the call I can already email you a file if I know your address and I don’t anyone’s permission to do so.

Why not make web3.storage just as easy and convenient. That way it could be used in contexts where user doesn’t even need to be logged into anything, suddenly making it perfect fit far all the open source projects out there

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants