@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:

1. Thanks for summarizing the situation. Rough that none work...
2. We should remove Estuary. It is no longer supported/maintained.
3. Maybe try https://filebase.com/ipfs-pinning/ ?
4. I would reach out to these groups and ask how they test their service. You can also point to your example.

@BigLep No problem.. happy to atleast be narrowing the focus for ipfs/helia#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.

Some note-able callouts:

• web3.storage is the only successful pinning service from NodeJS in this example.
• pinata can be connected to, but pinning doesn't succeed. Also, their handling of "origins" is flagging valid multiaddrs as invalid, so i have to explicitly filter out all multiaddrs containing quic
• 4everland can be connected to, but pinning doesn't succeed. They're running a very old version of go-ipfs
• scaleway & filebase: pinning providers' returned delegates cannot be connected to from Helia nor the latest kubo version, nor ipfs-shipyard/vole
• crust.io requires web3 wallet and i need new credentials to investigate further

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 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:

1. 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.
2. 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)?

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.

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:

• web3.storage is discontinuing support for the Pinning API spec (source)
• Estuary is discontinued
• Unclear whether nft.storage will continue supporting the pinning API spec. I think they're running on the same infra as web3.storage, so it may also be discontinued.

The latest updates on your projects. Learn more about Vercel for Git ↗︎