IPTM proposal

[Gozala]

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:

1. Generate ed25519 keypair and use public key as Pin id (or session identifier).
2. Client should store private keys only so that in the future it would be possible to mutate Pin or publish web3 name.
3. Client SHOULD use same keypair for single upload session.
4. Client SHOULD NOT reuse keypair across multiple upload sessions.
5. Client will encode CARs where root block is Transaction block with links to other blocks in the CAR.
6. Client will finalize upload by sending Commit transaction with last set of blocks and root CID.

On the backend I imagine we would do following:

1. Expose PATH / API endpoint that expects CAR encoded transactions.
2. Associate uploaded CARs with Pin id (a.k.a session public key).
3. On final chunk upload add transactions root CID to the list of uploads (we can work on incomplete upload states and listing by pin id in the future).

[hugomrdias]

how do we enforce Client SHOULD NOT reuse keypair across multiple upload sessions. ? block pub keys in the kv ?

[Gozala]

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

[Gozala]

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:

1. Ref protocol (Personally not a fan but idea is to update refs so maybe it works)
2. IPTM (Inter Planetary Transactional Memory) - There is quite a bit of overlap with STMs so maybe we could lean into it more.
3. Record protocol - Too generic
4. Account protocol - I actually like this, but I also recognize that the name might be confusing especially when used in context of blockchains etc…
5. 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

6. Update protocol
7. Mutation protocol
8. Transactional update protocol
9. Transaction protocol
10. IPTS (Inter Planetary Transaction System)

Please (ranked) vote and/or propose alternatives.

[mikeal]

I like IPTM :)

[the-simian]

IPTM and IPTS make the most sense to me, with IPTM being my favorite between the two.

[alanshaw]

This is super cool. I feel like we're almost there!

[alanshaw]

Can you take this further please? Want to see what it looks like when you append to a replica that isn't genesis.

[Gozala]

I have an observable with bunch more examples that I plan on linking as well.

[alanshaw]

Entry of the DAG? What does this mean - the root CID?

[alanshaw]

Why is this optional?

[alanshaw]

Why does prior have to be a link to a replica of the same type of change as here. This one could be an append, but the prior could have been a join (or something else) right?

[alanshaw]

I'm not sure this is helping my understanding! 😜

[Gozala]

Change in this context meant to be Append | Join, more broadly speaking it should be closed set of operations.