Open SgtPooki opened 1 year ago
@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 npm run start-node -- "some string"
) and then running the browser example with the same string.
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 https://github.com/ipfs/helia/issues/256
We should remove Estuary. It is no longer supported/maintained.
ACK
Maybe try https://filebase.com/ipfs-pinning/ ?
Failing from nodejs :( -- I just created a table with all pinning services and only web3.storage is succeeding from nodejs currently.
quic
I would reach out to these groups and ask how they test their service. You can also point to your example.
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 https://github.com/ipfs/helia/issues/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:
I believe there are shared slack channels with most/all of these or that ecosystem/outercore can help us get in touch. It's probably worth requesting connections to these groups in #ipfs-ecosystem.
Will request in ipfs-ecosystem.
Is pinning service compliance (https://github.com/ipfs-shipyard/pinning-service-compliance ) showing similar issues that multiple providers don't work (either from the browser or nodejs)?
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.
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 ↗︎
Name | Status | Preview | Comments | Updated (UTC) |
---|---|---|---|---|
verified-fetch | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Oct 10, 2024 11:17am |
Note: the version of @helia/remote-pinning being used here is currently in PR at https://github.com/ipfs/helia-remote-pinning/pull/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.