-
Notifications
You must be signed in to change notification settings - Fork 26
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
Proposal: IPNS pinning #85
Comments
FYSA there is a proposal and discussion around "IPNS Pinning Service" at ipfs/devgrants#142 (@mrodriguez3313) |
@RangerMauve could you add a link to your project and or proposal? I would love to see the progress and roadmap |
@mrodriguez3313 Yup, we're posting updates about it on this github issue: ipfs/devgrants#129 The relevant bit is Milestone 5: https://github.com/RangerMauve/devgrants/blob/ef3ac96d6aab4d498b2ecd4cd9f7d99fb29ba2a1/open-grants/open-proposal-agregore-mobile.md#milestone-5-ipfs-pinning-service-ui--integration At the moment we're planning on supporting both the regular IPFS pinning service API for IPFS URls, and also supporting the IPFS Cluster pinning API for IPNS. |
Quick brain dump on our options "how to represent We need to create rules and conventions around pinning (1) cryptographic IPNS names and (2) human-readable DNSLink names.
|
Thinking about point 1) and having gone through the pinning service spec. Since, with ipns records, there are two "types" of pinning. I feel like it would make sense to differentiate that in the spec. That being Record Tracking and Record Republishing Record Tracking, that is allowing a service to track the record you have alive Record Republishing, that is trustlessly allowing a third party to republish your record. Like @RangerMauve was saying in the ipfs/devgrants#142 (comment) it would be nice to for a user to be able to specify how long they want their record to live before expiring. I just personally don't know if that would be specified in the spec? (I'm just not an architect genius, thoughts on where this would be best to have?) Maybe that could be as part of the Im sure you've thought of these things already @lidel @aschmahmann. Just wanted to bring them up here and see if you can offer an insight to the questions in this post or any follow up? |
Cross posting from another thread on encoding DNSLink domains as CIDs: Hmmm. Personally, the CIDs for DNS Name approach seems like it'll add a lot more burden for pinning service client implementations since they'd need to include CID libraries in whatever code they're writing (I'm a dependency minimalist 🤪). Have you considered alternatives to CIDs like URLs? e.g. instead of passing a CID, clients could specify a |
@mrodriguez3313 the longer we talk about this, the more sense it makes to separate "dynamic/following/tracking" pinning from "static / one time" pinning. You have good insights! I agree with @RangerMauve that forcing DNSLink into Perhaps we should frame this work around separating static pins ( What if..
A separate endpoint would:
My usual north star here is for people to be able to use pinning for keeping valuable datasets alive, even when the original publisher is gone. If a user pinned an IPNS name, they expect the service to keep it alive (republish record, reprovide CIDs/data behind the record) until the pin is removed by the user. To illustrate, you don't have private IPNS keys for, but want to keep last IPNS snapshot of Wikipedia, press articles, historical scientific datasets alive. Data (CIDs) is always reprovided. Sure, the record may be expired, and sure, DHT/pubsub IPNS clients may ignore puts for it, but the pinned data should be around for clients that are ok with an older, expired record as the ultimate fallback.
Pinning service takes multiaddrs from
Right now, AFAIK, there is no trustless way for a third party to create a new, signed IPNS record with an update expiration date. |
Regarding expiration I think we should encourage users to use a high value for the lifetime parameter in Although I hate to admit it, I'm +1 to having an optional private key field in the new API. 🤷 Also, I'd like to point out that in the IPFS-cluster API they have two paths for adding IPFS/IPNS pins |
Yeah that is where my opinion lies as well.
So if I understand correctly, this issue is for local development of pinning and by extension of what people want in a remote pinning service as well. But after reading it, I realized the command I can think of two scenarios which can both be described as "following a record". The first is closer to what is being described in issue 4435. Which is that the users want to recieve updates on their own node from the original publisher (OP). Now this described in the issue is something that ideally they want baked into IPFS. Then they can circumvent any need for scripting to "follow" their content. So the command could also mean that they want to recieve updates of a certain record from the service? The second scenario, would be to actually pin a record to the remote service (what we want to do). Where we tell a service to "follow" a record aka periodically resolve it to check back for updates. Do you think that this necessitates differentiating and adding to the IPNS spec? The first scenario is not necessarily pinning, and if it were to be included in the spec, then it seems like this functionality would have to be added into go-ipfs?? So I would think
Will do! Thank you.
Yes I agree. Definitely requires a more dedicated and focused game plan.
Right right I know what you mean. Since people will imagine the pinning service to be like static ones or operate them like DBs. They may forget about their records after 24-36hrs and not be online at that time and the record will expire. And since we want the default functionality to keep the expired record available. The security implications would be present and so we should lay those out for the user to educate them.
Can you elaborate on this? |
So to be a little more concrete and think publicly. It makes sense to have those added fields in the Pin object. So lets say that
Basically we want similar results like Edit: 9/7/22 |
At the moment, I don't think IPNS is supported by some pinning services, and I'm not sure if everyone is in sync on what the behavior would actual look like.
It'd be nice if we could standardize how IPNS should be handled by pinning services (including DNSLink functionality, how updates work).
The text was updated successfully, but these errors were encountered: