-
Notifications
You must be signed in to change notification settings - Fork 63
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
feat: create helia-remote-pinning example #147
base: main
Are you sure you want to change the base?
Conversation
@achingbrain can you help me figure out how to log incoming dial attempts for the browser example? I can't seem to get it to succeed unless the pinning provider is already aware of the CID (via |
Something like this? helia.libp2p.addEventListener('connection:open', (evt) => {
const conn = evt.detail
if (conn.direction === 'inbound') {
// .. some code here
}
}) |
@achingbrain ok so that will listen for new connections, but I doubt we will get new inbound connections to the browser (currently) because only webrtc can provide that functionality and that doesn't exist in (m)any backend IPFS nodes yet. Does any event fire when a connection comes through on an already open connection with a p2p-circuit relay? I imagine this is where we need to listen for connection attempts to helia browser nodes. |
@SgtPooki : Thanks for doing this. I'll look more a bit later as well, but some initial thoughts:
|
@BigLep No problem.. happy to atleast be narrowing the focus for ipfs/helia#256
ACK
Failing from nodejs :( -- I just created a table with all pinning services and only web3.storage is succeeding from nodejs currently. Some note-able callouts:
With most pinning services leaving something to be desired, I will reach out to them all, point them to this issue, and start work on other tasks. I will consider ipfs/helia#256 blocked until we have some pinning services with webtransport. |
Thanks for the update here @SgtPooki. This is tough to see, but at least we're engaged with reality. A couple of things:
|
Will request in ipfs-ecosystem.
it's showing failures in estuary for pinning content, and crust.io authentication errors, but other services are showing successes primarily because we're using inlineCids. So data retrieval through the IPFS network is not required. IIRC, pinning-service-compliance was primarily intended to validate that services were implementing the pinning-services spec properly, not that the pinning services themselves worked well when doing IPFS network connectivity. |
slack threads or github issues with pinning providers & further discussions.I will link any issues/tickets that come up, but for now, here are some slack threads where I'm trying to get in touch with the teams: |
note: filebase did some updates and the returned delegates are now dialable: ╭─ ~/code/work/protocol.ai/ipfs-shipyard/vole
╰─ ✔ ❯ ./vole libp2p identify /ip4/15.204.161.17/tcp/4001/p2p/12D3KooWErRwP21vdVD7rkaivnMfxXAnXs3djX4D5JNfzAYFmrCM
PeerID: "12D3KooWErRwP21vdVD7rkaivnMfxXAnXs3djX4D5JNfzAYFmrCM"
Protocol version: "ipfs/0.1.0"
Agent version: "kubo/0.19.2/afb27ca/filebase"
Listen addresses:
- "/ip4/15.204.161.17/tcp/4001/p2p/12D3KooWErRwP21vdVD7rkaivnMfxXAnXs3djX4D5JNfzAYFmrCM"
Protocols:
- "/ipfs/bitswap"
- "/ipfs/bitswap/1.0.0"
- "/ipfs/bitswap/1.1.0"
- "/ipfs/bitswap/1.2.0"
- "/ipfs/id/1.0.0"
- "/ipfs/id/push/1.0.0"
- "/ipfs/kad/1.0.0"
- "/ipfs/lan/kad/1.0.0"
- "/ipfs/ping/1.0.0"
- "/libp2p/circuit/relay/0.2.0/stop"
- "/x/"
╭─ ~/code/work/protocol.ai/ipfs-shipyard/vole
╰─ ✔ ❯ ./vole libp2p identify /ip4/141.95.85.123/tcp/4001/p2p/12D3KooWNWgNz5QSL2D2YxfKcYo6HyEpFuRnW2fRYewrDmjWJECi
PeerID: "12D3KooWNWgNz5QSL2D2YxfKcYo6HyEpFuRnW2fRYewrDmjWJECi"
Protocol version: "ipfs/0.1.0"
Agent version: "kubo/0.19.2/afb27ca/filebase"
Listen addresses:
- "/ip4/141.95.85.123/tcp/4001/p2p/12D3KooWNWgNz5QSL2D2YxfKcYo6HyEpFuRnW2fRYewrDmjWJECi"
Protocols:
- "/ipfs/bitswap"
- "/ipfs/bitswap/1.0.0"
- "/ipfs/bitswap/1.1.0"
- "/ipfs/bitswap/1.2.0"
- "/ipfs/id/1.0.0"
- "/ipfs/id/push/1.0.0"
- "/ipfs/kad/1.0.0"
- "/ipfs/lan/kad/1.0.0"
- "/ipfs/ping/1.0.0"
- "/libp2p/circuit/relay/0.2.0/stop"
- "/x/"
╭─ ~/code/work/protocol.ai/ipfs-shipyard/vole
╰─ ✔ ❯ ./vole libp2p identify /ip4/198.244.201.187/tcp/4001/p2p/12D3KooWC9L4RjPGgqpzBUBkcVpKjJYofCkC5i5QdQftg1LdsFb2
PeerID: "12D3KooWC9L4RjPGgqpzBUBkcVpKjJYofCkC5i5QdQftg1LdsFb2"
Protocol version: "ipfs/0.1.0"
Agent version: "kubo/0.19.2/afb27ca/filebase"
Listen addresses:
- "/ip4/198.244.201.187/tcp/4001/p2p/12D3KooWC9L4RjPGgqpzBUBkcVpKjJYofCkC5i5QdQftg1LdsFb2"
Protocols:
- "/ipfs/bitswap"
- "/ipfs/bitswap/1.0.0"
- "/ipfs/bitswap/1.1.0"
- "/ipfs/bitswap/1.2.0"
- "/ipfs/id/1.0.0"
- "/ipfs/id/push/1.0.0"
- "/ipfs/kad/1.0.0"
- "/ipfs/lan/kad/1.0.0"
- "/ipfs/ping/1.0.0"
- "/libp2p/circuit/relay/0.2.0/stop"
- "/x/" |
Some updates:
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Note: the version of @helia/remote-pinning being used here is currently in PR at ipfs/helia-remote-pinning#13
Browser example
NOTE: the browser example does not succeed with web3.storage. There are two problems:
I've tested all the main pinning services I know to try, and they all have errors of some sort:
queued
topinning
but doesn't seem to ever succeed.Node example
The node example seems to work without issue (because tcp transports are available in nodejs)
NOTE: when running
npm run start-node
against filebase, retries needs to be bumped up so that the node is still running when filebase kicks off their task of pulling the content. Joshua Noble on slack "Pinning is not immediate, it goes into a queue."Tests
Not started yet.. I think in order to test this properly, we will need to stand up more than a mock pinning provider that involves delegate and origin dials.