refactor: remove pdp in sdk

[hugomrdias]

• remove pdp in sdk
• take File as upload input
• reorganize sp/pdp actions in core
• add sp response validation

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

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

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	synapse-dev	ae45545	Commit Preview URL Branch Preview URL	Feb 10 2026, 05:14 PM

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	p-defer@​4.0.1
	iso-web@​2.1.0
	playwright-test@​14.1.12
	dnum@​2.17.0
	chai@​6.2.2

View full report

[rvagg]

It would have been good if you had have separated these out, removal of pdp is fine, but this needs discussion:

const file = new File([new Uint8Array([1, 2, 3, 4, 5])], "foo.txt");
const result = await synapse.storage.upload(file);

I'd like to understand why we need to require a File. The main DX problem with this pattern is that it implies sematic meaning of "foo.txt". Why would we require you wrap your bytes in a File if we're just going to extract your bytes from the File and throw away the metadata?

[rvagg]

why PdpDataSet / get-pdp-data-set? are you worried about the confusion with pdp/get-data-set? cause I'm not sure putting "pdp" in front really helps the case. maybe you have to accept "extended" or "enhanced" here .. cause that's what it is.

[hugomrdias]

no, sp/get-data-set will go away when we clean up the pieceStatus

theres:

• warmstorage.getDataSet which is the barebones contract call
• warmstorage.getPdpDateSet that adds pdp verifier data and PDP sp to the object

[rvagg]

this is going to hurt for users like filecoin-pin demo, I wouldn't be surprised if it breaks for that case

[hugomrdias]

why, too many calls ?
we were already doing all theses calls before

[hugomrdias]

the sdk does not use this action

[rvagg]

hah, are you sure you want to do this? this feels like opt-in behaviour to me, the pieces are still there, they're only scheduled for removal and won't be removed from on-chain or on the SP until the next proving period

[hugomrdias]

that why theres the getActivePieces action with no dedupe same output

[rvagg]

changing convention here, not a firm objection but I think you should stick to the existing convention of withCDN unless you're planning on changing all of the instances and causing even more breakage

[rvagg]

k, I've done a review, my biggest objection is requiring File here and removing the other optionality. Some generic streaming option that doesn't require hoops is my preference, ReadableStream<Uint8Array> is fine.

In #593 I have Uint8Array | ReadableStream<Uint8Array>, can we just stick File in that list to? And is it really that big a deal to allow users to pass in Uint8Array at the SDK level and we fix it up for them? We don't even need .from() cause it's a simple case. In fact, I believe that taking data: Uint8Array | File | ReadableStream<Uint8Array> and normalising to ReadableStream<Uint8Array> internally is this easy:

const stream =
  data instanceof ReadableStream ? data :
  data instanceof File ? data.stream() :
  new ReadableStream({ start(c) { c.enqueue(data); c.close(); } });

You could push that all the way down to uploadPieceStreaming but then those new options.data.size need to be optional, IMO they definitely should be. I know that a lot of places we will have .size, but there are going to be places where it's too awkward to have one. The streaming CAR is one of those places - it's really expensive to pre-generate a CAR, "don't duplicate my data" has been a fundamental complaint of our IPFS stack and we can avoid it easily if we don't have to have the bytes ready before we start.

Other items as mentioned:

• PdP included in DataSet feels a bit weird, is it necessary?
• getPieces filtering out scheduled deletions might seem right, but it's not protocol-correct, I think it should be opt-in behaviour and documenting it is a good chance for protocol communication.
• cdn and withCDN mix / change feels unnecessary and potentially footgunny
• The nonce creation timing for createDataSet and createDataSetAndAddPieces

Zod is good, endpoint -> serviceURL is good, normalistaion of some of the synapse-core patterns like OutputType is good. Removing PDPServer class from SDK is reasonable.

PR could have been titled better! Probably best if it's not squash merged with that change. OTY