You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ?
This makes web3.storage the easiest way to get content online!
This makes it possible to use web3.storage without UCANs or anything other than native HTTP stack
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 ?
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
The text was updated successfully, but these errors were encountered:
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.
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
This is an idea that came up during the call today:
curl -X PUT https://api.web3.storage/inbox/[email protected] -T file.txt
Why do this ?
What not do this ?
The text was updated successfully, but these errors were encountered: