Open justin0mcateer opened 1 year ago
@justin0mcateer Thanks for the question.
That method is part of the Kubo RPC API.
Helia will not be supporting the Kubo RPC API. You should use https://github.com/ipfs/js-kubo-rpc-client for that.
As far as supporting pinning remotely via "some" API, I think it would make sense for Helia to support adding a plugin/module system for abstracting away calls to pinning services, but we'll need to wait for @achingbrain to get back before we decide on how to proceed.
Ideally today we could say to use the "pinning API" (e.g., https://github.com/ipfs-shipyard/js-pinning-service-http-client). Unfortunately that won't work because a pinning service won't be able to dial your browser directly yet. This will get fixed as part of https://github.com/ipfs/helia/issues/182.
An alternative path is HTTP data onboarding, but that hasn't been specified or implemented yet (although I hope it happens this year).
The pinning API case should work within NodeJS, and @SgtPooki is going to create a tracking issue for this.
Unfortunately that won't work because a pinning service won't be able to dial your browser directly yet.
Why not? It'd seem like most implementers of the remote pinning API would have WSS (or WebTransport) and relay support in their libp2p implementations which would allow browsers to dial them as is.
Unfortunately that won't work because a pinning service won't be able to dial your browser directly yet.
Why not? It'd seem like most implementers of the remote pinning API would have WSS (or WebTransport) and relay support in their libp2p implementations which would allow browsers to dial them as is.
Good point @aschmahmann . I wasn't accounting for this. Basically this can work as-is today assuming the pinning service returns PinStatus.delegates multiaddrs that the browser can dial. (Correct me I have that wrong.)
Yeah, delegates will do the job.
Additionally, if DCUtR is supported in js-libp2p (I don't recall the status here) and by the pinning service then even if for some reason the pinning service doesn't send delegates if the pinning service speaks the relay protocol, DCUtR and webtransport and the helia node is connected to a relay the helia node can send in origins
its relayed address.
We are using some third party library that does a lot of local pinning, but we need the items also pinned remotely. If the 'Pinning' implementation in Helia were injectable, we could pretty easily whip up something to meet our needs. Would there be any aversion to that approach?
From: Adin Schmahmann @.> Sent: Thursday, July 13, 2023 6:43:48 PM To: ipfs/helia @.> Cc: justin0mcateer @.>; Mention @.> Subject: Re: [ipfs/helia] Remote Pinning Support (Issue #180)
Yeah, delegates will do the job.
Additionally, if DCuTR is supported in js-libp2p (I don't recall the status here) and by the pinning service then even if for some reason the pinning service doesn't send delegates if the pinning service speaks the relay protocol, DCuTR and webtransport and the helia node is connected to a relay the helia node can send in origins its relayed address.
— Reply to this email directly, view it on GitHubhttps://github.com/ipfs/helia/issues/180#issuecomment-1635061296, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAT4Q7KJVOYXKJBAFMWFEZTXQCB3FANCNFSM6AAAAAA2HO3ITA. You are receiving this because you were mentioned.Message ID: @.***>
@justin0mcateer we will be discussing the direction to accomplish this and getting back to you as soon as possible.
@justin0mcateer The plan is going to be to create a package/module that wraps Helia and js-pinning-service-http-client that matches the js-pinning-service-http-client API while calling the Helia methods under the hood to deal with origins & delegates.
We're not using the injectable/plugin approach for any Helia functionality, AFAIK. We will continue to use a wrapper module approach similar to the existing pattern we've established where Helia is injected into isolated functionality modules. See examples of that approach in the README at https://github.com/ipfs/helia#-usage.
@SgtPooki : given we have https://github.com/ipfs/helia-remote-pinning , what is needed to resolve this? Are waiting for a reproducibly working example (https://github.com/ipfs-examples/helia-examples/issues/86 )?
I would love to resolve this given https://github.com/ipfs/helia-remote-pinning exists (we still need to link to it from readme). I don't think we need the example to be merged to succeed, because it works from nodejs with web3.storage.
However, the viability of the library at this moment is very low because of the issues pointed out in https://github.com/ipfs-examples/helia-examples/issues/86, and we should probably wait on closing this as resolved until we know our users have a consistently successful path forward.
I would love to hear from @justin0mcateer on what he thinks about the library and the changes proposed in https://github.com/ipfs/helia-remote-pinning/pull/13, and if he thinks that library solves his needs.
Is there any intention to support Remote Pinning within Helia as was possible previously with js-ipfs (eg. ipfs.pin.remote)? https://github.com/ipfs/js-ipfs/blob/master/docs/core-api/PIN.md#ipfspinremotermalloptions
If not is there any recommendation about which approach to use?