Open Gozala opened 2 years ago
how do we enforce Client SHOULD NOT reuse keypair across multiple upload sessions.
? block pub keys in the kv ?
how do we enforce
Client SHOULD NOT reuse keypair across multiple upload sessions.
? block pub keys in the kv ?
To be clear it's not inherently wrong to reuse keys, it's just going to replace existing upload associated with key with another, which I don't think what we want right now. I do not think we need to enforce that we should just generate new keypair for every upload until we're further along in the mutable land
Looks like ‘revision’ name is also controversial, so I propose to bikeshed on this further here. While renaming Pin to Revision I have considered following alternatives:
Ref
protocol (Personally not a fan but idea is to update refs so maybe it works)IPTM (Inter Planetary Transactional Memory)
- There is quite a bit of overlap with STMs so maybe we could lean into it more.Record
protocol - Too genericAccount protocol
- I actually like this, but I also recognize that the name might be confusing especially when used in context of blockchains etc…Chronicle
- Emphasizing fact that it’s a chain of events.@mikeal suggested Session protocol
, which I find misleading, because even though for file uploads it will act like a session, I do hope that it would also enable interesting uses for mutability in web3.storage where it will not correspond to session, but rather to a revision history of the mutable DAG.
I also would like to emphasize transactionalitiy more than anything. So here are few other ideas
Please (ranked) vote and/or propose alternatives.
I like IPTM :)
IPTM and IPTS make the most sense to me, with IPTM being my favorite between the two.
This is current draft of the pin protocol proposal.
We could implement simplified version of this to remove "root cid" requirement. In "simplified" version
proof
fields can be message signatures (with private key of pin id), so that we do not have to block on UCAN work.Simplified version
Client for the large upload would:
Pin
id (or session identifier).Transaction
block with links to other blocks in the CAR.Commit
transaction with last set of blocks and root CID.On the backend I imagine we would do following:
PATH /
API endpoint that expects CAR encoded transactions.Pin
id (a.k.a session public key).root
CID to the list of uploads (we can work on incomplete upload states and listing by pin id in the future).