IPIP-0526: Historic Bitswap Provider Publishing API #526
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
documents the legacy PUT /routing/v1/providers/ endpoint for signed Bitswap provider records, originally introduced for index-provider/IPNI integration. includes CSS styling for historic IPIP state.
🚀 Build Preview on IPFS ready
|
This was referenced Dec 2, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This IPIP
PUT /routing/v1/providers/endpoint that only accepts signed Bitswap provider records, originally introduced for index-provider/IPNI integration in 2022Why?
I spent multiple days over the years discussing this, and explaining all the background and history always takes most of the time.
Now, there is a PR I can link to + this allows us to close all issues related to abandoned #378 and point here as a provisional spec reference if anyone needs to use or discuss this API for legacy reasons.
Should the be merged?
I'm fine either way.
The IPIP has a special state "historic" and clearly states is provided only for archival purposes.
If we are not planning on standardizing this API, but there won't be anything better to replace it any time soon, we could merge it to have SOMETHING people can reference, but also be vary its provisional and limited in scope and support.
If we are planning to create alternative any time soon (EOY 2026), it might be ok to keep it as a draft indefinitely, and close without merging when a modern replacement is defined by a different IPIP.
For now, I'm marking it as a draft, we can decide its fate in 2026.
cc @aschmahmann @gammazero