feat(core): preserve non-standard SP registry capabilities in PDPOffering by rvagg · Pull Request #687 · FilOzone/synapse-sdk

rvagg · 2026-03-23T02:56:25Z

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.

…ring There's potentially useful signals in here downstream from our consumption of the capabilities providers publish.

cloudflare-workers-and-pages · 2026-03-23T03:05:14Z

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	synapse-dev	`62b69fb`	Mar 30 2026, 04:02 PM

rvagg · 2026-03-23T03:17:19Z

CI failing due to ABI changes, fixing that separately #688

Copilot

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 decodePDPCapabilities to 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.

Copilot · 2026-03-27T15:50:59Z

packages/synapse-core/src/utils/pdp-capabilities.ts

+    ipniIpfs: zHex.optional(),
+    ipniPeerId: zHex.optional(),
+  })
+  .passthrough()


PDPOfferingSchema uses .passthrough(), which means any non-standard capability values are accepted without validation. Since extraCapabilities is exposed as Record<string, Hex>, consider switching to .catchall(zHex) (or otherwise validating unknown keys) so extra capability values are guaranteed to be valid hex strings.

Suggested change

.passthrough()

.catchall(zHex)

Copilot · 2026-03-27T15:51:00Z

packages/synapse-core/src/utils/pdp-capabilities.ts

  const parsed = PDPOfferingSchema.safeParse(capabilities)
  if (!parsed.success) {
    throw new ZodValidationError(parsed.error)
  }
-  return decodePDPCapabilities(parsed.data)
+  return decodePDPCapabilities(parsed.data as Record<string, Hex>)


parsed.data is being cast to Record<string, Hex> before calling decodePDPCapabilities. With .passthrough() this can mask invalid extra capability values (typed as unknown by Zod) and silently violate the Hex contract. Prefer adjusting the schema typing/validation (e.g., .catchall(zHex)) so this cast can be removed.

Copilot · 2026-03-27T15:51:00Z

packages/synapse-core/src/utils/pdp-capabilities.ts

+  const extraCapabilities: Record<string, Hex> = {}
+  let hasExtra = false
+  for (const key of Object.keys(capabilities)) {
+    if (!KNOWN_CAPABILITY_KEYS.has(key)) {
+      extraCapabilities[key] = capabilities[key]
+      hasExtra = true


extraCapabilities is built with a normal object literal and then assigned arbitrary, provider-controlled keys. Keys like __proto__/constructor can trigger prototype mutation in JS objects. Consider using Object.create(null) for extraCapabilities (or explicitly guarding against these keys) to avoid prototype-pollution style issues when consuming or serializing this map later.

+1 to the copilot request

SgtPooki · 2026-03-27T15:57:13Z

sorry i didn't get to this. heading on vacation so i wont be able to look until 2026 APR 8+

hugomrdias

LGTM but copilot's first suggestion seems to be good

juliangruber · 2026-03-30T15:59:06Z

packages/synapse-core/src/utils/pdp-capabilities.ts

+  const extraCapabilities: Record<string, Hex> = {}
+  let hasExtra = false
+  for (const key of Object.keys(capabilities)) {
+    if (!KNOWN_CAPABILITY_KEYS.has(key)) {
+      extraCapabilities[key] = capabilities[key]
+      hasExtra = true


+1 to the copilot request

juliangruber · 2026-03-30T16:00:06Z

packages/synapse-core/src/utils/pdp-capabilities.ts

+  let hasExtra = false
+  for (const key of Object.keys(capabilities)) {
+    if (!KNOWN_CAPABILITY_KEYS.has(key)) {
+      extraCapabilities[key] = capabilities[key]
+      hasExtra = true
+    }
+  }
+
+  return { ...required, ...optional, ...(hasExtra ? { extraCapabilities } : {}) }


Suggested change

let hasExtra = false

for (const key of Object.keys(capabilities)) {

if (!KNOWN_CAPABILITY_KEYS.has(key)) {

extraCapabilities[key] = capabilities[key]

hasExtra = true

}

}

return { ...required, ...optional, ...(hasExtra ? { extraCapabilities } : {}) }

for (const key of Object.keys(capabilities)) {

if (!KNOWN_CAPABILITY_KEYS.has(key)) {

extraCapabilities[key] = capabilities[key]

}

}

return { ...required, ...optional, ...({ extraCapabilities }) }

this produces a more stable schema and is a simpler implementation

juliangruber · 2026-03-30T16:00:38Z

packages/synapse-core/test/pdp-capabilities.test.ts

+
+      const result = decodePDPCapabilities(capabilities)
+
+      assert.strictEqual(result.extraCapabilities, undefined)


Suggested change

assert.strictEqual(result.extraCapabilities, undefined)

assert.deepStrictEqual(result.extraCapabilities, {})

(if you merge above suggestion)

juliangruber · 2026-03-30T16:02:28Z

packages/synapse-core/src/utils/pdp-capabilities.ts

 }

+/** 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])


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?

hugomrdias · 2026-04-01T16:19:13Z

i will rebase and finish this tomorrow

feat(core): preserve non-standard SP registry capabilities in PDPOffe…

318a694

…ring There's potentially useful signals in here downstream from our consumption of the capabilities providers publish.

rvagg requested a review from SgtPooki March 23, 2026 02:56

rvagg requested a review from hugomrdias as a code owner March 23, 2026 02:56

github-project-automation bot moved this to 📌 Triage in FOC Mar 23, 2026

github-project-automation bot added this to FOC Mar 23, 2026

rvagg mentioned this pull request Mar 23, 2026

dealbot should be able to enable/disable testing against specific SPs FilOzone/dealbot#364

Open

BigLep moved this from 📌 Triage to 🐱 Todo in FOC Mar 23, 2026

BigLep moved this from 🐱 Todo to 🔎 Awaiting review in FOC Mar 27, 2026

BigLep assigned rvagg Mar 27, 2026

BigLep requested a review from Copilot March 27, 2026 15:47

Copilot started reviewing on behalf of BigLep March 27, 2026 15:48 View session

Copilot AI reviewed Mar 27, 2026

View reviewed changes

rjan90 added this to the M4.2: mainnet GA milestone Mar 30, 2026

rvagg requested a review from juliangruber March 30, 2026 11:05

Merge branch 'master' into rvagg/extra-capabilities

62b69fb

hugomrdias approved these changes Mar 30, 2026

View reviewed changes

github-project-automation bot moved this from 🔎 Awaiting review to ✔️ Approved by reviewer in FOC Mar 30, 2026

juliangruber requested changes Mar 30, 2026

View reviewed changes

github-project-automation bot moved this from ✔️ Approved by reviewer to ⌨️ In Progress in FOC Mar 30, 2026

rjan90 assigned hugomrdias Apr 1, 2026


		const result = decodePDPCapabilities(capabilities)

		assert.strictEqual(result.extraCapabilities, undefined)

	assert.strictEqual(result.extraCapabilities, undefined)
	assert.deepStrictEqual(result.extraCapabilities, {})

Conversation

rvagg commented Mar 23, 2026

Uh oh!

cloudflare-workers-and-pages bot commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying with Cloudflare Workers

Uh oh!

rvagg commented Mar 23, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Mar 27, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 27, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 27, 2026

Choose a reason for hiding this comment

Uh oh!

juliangruber Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SgtPooki commented Mar 27, 2026

Uh oh!

hugomrdias left a comment

Choose a reason for hiding this comment

Uh oh!

juliangruber Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

juliangruber Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

juliangruber Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

juliangruber Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

hugomrdias commented Apr 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

cloudflare-workers-and-pages bot commented Mar 23, 2026 •

edited

Loading

juliangruber Mar 30, 2026 •

edited

Loading

juliangruber Mar 30, 2026 •

edited

Loading