Skip to content
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

Support announcing provider records #11

Closed
2 tasks
lidel opened this issue Oct 10, 2022 · 4 comments
Closed
2 tasks

Support announcing provider records #11

lidel opened this issue Oct 10, 2022 · 4 comments

Comments

@lidel
Copy link
Member

lidel commented Oct 10, 2022

Someguy is backed by accelerated DHT client and acts as a proxy for other reframe endpoints.
We want light clients to be able to use https://routing.delegate.ipfs.io/reframe (becked by someguy) for publishing provide records (see https://github.com/protocol/bifrost-infra/issues/2142 for more details about that endpoint).

Reframe's ProvideRequest was introduced in ipfs/specs#285

TODO

  • confirm this is enough to cover both DHT and Reframe puts
    • if not, we need to improve reframe specs in ipfs/specs repo
  • implement provide puts
@aschmahmann
Copy link
Contributor

confirm this is enough to cover both DHT and Reframe puts

Unfortunately delegated providing to the IPFS Public DHT is impossible due to how the DHT is constructed libp2p/go-libp2p-kad-dht#584. TLDR:

  1. The DHT only allows announcing "I have X" not "Alice has X" which means you cannot delegate requests
  2. Even if it allowed it there's no way for peer records to announce "Alice has addresses A, B,C" instead addresses are made available by maintaining libp2p connections and utilizing the libp2p identify protocol to send addresses over.

So the question is what types of "puts" would you like to do for routing.delegate.ipfs.io? For example, you could decide to only provide to the Indexer network by delegating all the provides to some instance that will hold the records and deal with the semantics there. IIUC @ischasny is working on such a service and implementation at ipfs-shipyard/ipfs-index-provider#1.

A couple thoughts related to integrating with the reframe-based index provider.

  1. It could be bundled into someguy, but it turns someguy from a service that requires no persistence or database into one that does ... so I would avoid it and just add one more layer of forwarding/delegation.
  2. This service would need to figure out some policy around how it deals with the stored records. Does it store all records forever? Does it require them to be re-put every x hours or else evicted, will the service reach out to the nodes to see if they're alive, hosting some content, etc. If they don't will the service run into problems with the Indexers penalizing it for advertising "bogus" records?

@ischasny
Copy link

Just FYI, implementation of the reframe based index provider can be found here. It's going to be merged and shipped as a part of the index-provider library soon.

Indeed it requires some persistence to track what ads have been sent to the indexers and to be able to figure out diffs between consecutive snapshots to track what CIDs have expired.

@gmasgras
Copy link

gmasgras commented Jan 8, 2023

@lidel is this want still valid/actionable ?

@lidel
Copy link
Member Author

lidel commented Jan 16, 2023

@gmasgras no, Reframe was abandoned, so we need to rewrite someguy first: #12, and to have announcement capability, we need to finalize specification of HTTP PUTs. Closing for now.

@lidel lidel closed this as completed Jan 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants