-
Notifications
You must be signed in to change notification settings - Fork 0
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
IPTM proposal #1
base: main
Are you sure you want to change the base?
Conversation
how do we enforce |
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:
@mikeal suggested 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is super cool. I feel like we're almost there!
codec: CBOR, | ||
hasher: sha256 | ||
}) | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you take this further please? Want to see what it looks like when you append to a replica that isn't genesis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have an observable with bunch more examples that I plan on linking as well.
type Publish { | ||
type "publish" | ||
id ID | ||
-- Entry of the DAG (Must be contained by origin) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Entry of the DAG? What does this mean - the root CID?
-- DAG representation | ||
origin &Replica | ||
-- Shard containing root (Must be contained by origin) | ||
shard optional &Shard |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this optional?
|
||
```ts | ||
type Replica<Change> { | ||
prior?: Link<Replica<Change>> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is helping my understanding! 😜
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change
in this context meant to be Append | Join
, more broadly speaking it should be closed set of operations.
Co-authored-by: Brooklyn Zelenka <[email protected]>
Co-authored-by: Alan Shaw <[email protected]>
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).