feat: introduce http/put capability #116
Conversation
w3-blob.md
Outdated
| "url": "https://r2.cloudflare.com/ipfs/bafy...", | ||
| "headers": {} |
There was a problem hiding this comment.
should we wrap this with an address key to be consistent with Allocate receipt?
w3-blob.md
Outdated
| "url": "https://r2.cloudflare.com/ipfs/bafy...", | ||
| "headers": {} |
There was a problem hiding this comment.
I now realize that this is not great :/ We can iterate after, but in the world of write to anywhere where in allocate we could look async for write targets to write, we now need to know these right away. I wonder what would be the downside of just passing the content, as service will always need to validate it
Co-authored-by: Vasco Santos <[email protected]>
w3-blob.md
Outdated
| cmd: "/http/put" | ||
| sub: DID | ||
| args: { | ||
| content: Multihash |
There was a problem hiding this comment.
can we make this a Blob instead? when we receive a http/put having the blob allows us to invoke blob/accept right away. Otherwise, we need to look at state to find it out
There was a problem hiding this comment.
| content: Multihash | |
| body: Blob |
Something like this you mean ?
There was a problem hiding this comment.
yes, body or Blob is good for me
Amend spec per agreements last Thursday, few notes:
ucan/concludecapability as opposed toucan/receipt, although we could go with receipt route if it is more preferred. Either one will likely differ from where spec will end up, but current version is likely to be closer than version withucan/receipt.await/okin theoutfield may change slightly as we're discussing doing something like{ 'ucan/await': ['.ok.claim', { "/": ... }] }so you could drill down deeper, however there is no agreement in UCAN WG on exact schema yet.