Conversation
Describes the ipni/offer capability and how data is indexed and retrieved without relying on centralized services. This is necessary for the write-anywhere initiative. Depends on storacha/specs#85
hannahhoward
left a comment
hannahhoward
left a comment
There was a problem hiding this comment.
My main ask off the bat is to align with #13, which says location claims don't get made on the client.
Co-authored-by: Irakli Gozalishvili <contact@gozala.io>
|
|
||
| The ipni/offer is optional, and if not invoked, then the user's data is not indexed. | ||
|
|
||
| If opting-in to IPNI indexing, the CAR file and the CARx-index are created by the client. The client may choose which multihashes they want indexed and specify this in the ipni/offer request. |
There was a problem hiding this comment.
Like we do in w3filecoin protocol, we should consider here having a ipni/accept capability. Offer invocation asks the service to do X, service responds saying I got it and soon I will solve this for you, and by the way, here is the CID of the invocation I am working on. Then user can query for the receipt, which will be done when service ends.
A simplified version may exist when we UCAN1.0 + UCAN Invocation Spec, but I think this is the only way for it to land before that cc @Gozala
There was a problem hiding this comment.
If user wants to publish to IPNI, they invoke ipni/offer request:
- Get blob status to check data is stored and get claims bundle CID
- Invoke
ipni/offerwith the claims bundle CID associated with the stored data to index - User gets back a receipt that contains the advertisement ID
- Can be done once at anytime during stored data lifetime
There was a problem hiding this comment.
Once the advertisement CID is returned, then the advertisement has been published to IPNI. I don't think there is a need to make this async. The async part is waiting for IPNI to index the advertisement. That is not something we control, so the client will just have to query IPNI if they want to see when their stuff gets indexed.
hannahhoward
left a comment
hannahhoward
left a comment
There was a problem hiding this comment.
It seems like there is still a small bit of tightening on alignment about location claims, but I think we're basically there. I'm LGTM at this point.
Gozala
left a comment
Gozala
left a comment
There was a problem hiding this comment.
Looks pretty good, I did provide bunch of comments and suggestions, but I'll let it up to you what you want to incorporate and what to ignore.
I think this is probably already very detailed for the RFC and probably good idea to merge and iterate on details in the specs (probably can copy & paste this there too).
I'm still wondering if decoupling content claims from location claims might be a good idea that would allow client querying IPNI to choose which location claim to follow independent from which partition claim to follow.
Other thought I had is that it would a good idea if claim bundle CID was not affected by who made those claims that is issuer, audience, and subject. That way multiple users indexing same data would arrive to same claims bundle as opposed to different ones. That would probably require a lot more thinking how to represent index though, but perhaps it is not a bad idea never the less.
4 participants
HTML View
Describes the ipni/offer capability and how data is indexed and retrieved without relying on centralized services.