feat(core): preserve non-standard SP registry capabilities in PDPOffering - #687
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
synapse-dev | eca0ad8 | Commit Preview URL Branch Preview URL |
Apr 02 2026, 10:21 AM |
|
CI failing due to ABI changes, fixing that separately #688 |
There was a problem hiding this comment.
Pull request overview
This PR updates PDP capability decoding to preserve non-standard Service Provider Registry capability entries (e.g., serviceStatus) so downstream consumers can access them without needing synapse-core to explicitly model every possible capability.
Changes:
- Allow unknown capability keys through PDP offering schema validation and surface them via
PDPOffering.extraCapabilities. - Add logic in
decodePDPCapabilitiesto separate known/typed capability fields from extra/untyped ones. - Add tests to verify extra capabilities are preserved and omitted when none exist.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| packages/synapse-core/src/utils/pdp-capabilities.ts | Allows unknown capabilities through validation and returns them in extraCapabilities during decode. |
| packages/synapse-core/src/sp-registry/types.ts | Extends PDPOffering with optional extraCapabilities field. |
| packages/synapse-core/test/pdp-capabilities.test.ts | Adds unit tests covering preservation/omission/filtering of extraCapabilities. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
sorry i didn't get to this. heading on vacation so i wont be able to look until 2026 APR 8+ |
hugomrdias
left a comment
hugomrdias
left a comment
There was a problem hiding this comment.
LGTM but copilot's first suggestion seems to be good
github-project-automation
Bot
moved this from 🔎 Awaiting review
to ✔️ Approved by reviewer
in FOC
|
|
||
| const result = decodePDPCapabilities(capabilities) | ||
|
|
||
| assert.strictEqual(result.extraCapabilities, undefined) |
There was a problem hiding this comment.
| assert.strictEqual(result.extraCapabilities, undefined) | |
| assert.deepStrictEqual(result.extraCapabilities, {}) |
(if you merge above suggestion)
| } | ||
|
|
||
| /** Capability keys that are decoded into typed PDPOffering fields, derived from the schema */ | ||
| const KNOWN_CAPABILITY_KEYS = new Set([...Object.keys(PDPOfferingSchema.shape), CAP_IPNI_PEER_ID_LEGACY]) |
There was a problem hiding this comment.
This array likely becomes a maintenance burden, and is hard to test in integration.
Would it be easier to expose all capabilities in one object, and not differentiate standard and non-standard capabilities?
There was a problem hiding this comment.
I think that'd be a downgrade, standard fields give us a well formed struct with proper decoding, flattening them would mean a Record<string, something> bucket to go fishing through. At least we can type the known keys and they match the contract; we can expect to find required keys and may expect to find the non-required but known keys, the rest are a wild west.
There was a problem hiding this comment.
Some examples of where we'd lose fidelity: provider.pdp.minPieceSizeInBytes (and max) are decoded as bigint, provider.pdp.paymentTokenAddress as Address, provider.pdp.ipniPiece / ipniIpfs as boolean; we know this and when they don't decode like this something is wrong, and it also means we can offer a typed struct for consumers of known fields.
github-project-automation
Bot
moved this from ✔️ Approved by reviewer
to ⌨️ In Progress
in FOC
|
i will rebase and finish this tomorrow |
…ring There's potentially useful signals in here downstream from our consumption of the capabilities providers publish.
62b69fb to
eca0ad8
Compare
|
Rebased and addressed all of the suggestions except for the suggestion to flatten everything; we should be clear with the known keys as the other parts of the system are - the registry and Curio |
github-project-automation
Bot
moved this from ⌨️ In Progress
to ✔️ Approved by reviewer
in FOC
We shouldn't have been stripping theses, there's potentially useful signals in here downstream from our consumption of the capabilities providers publish. One example is FilOzone/dealbot#364 where the "serviceStatus" capability still has some use, but there's plenty more where clients have needs that align with what service providers want to dump in their capabilities field that we don't know or care about.