# upload-api in CF

Create signed urls to have users put CARs to a CF worker (again). It verifies every block from every car and writes the complete indexes to R2, DUDEWHERE style.

- We now have a "hash-on-write" guarantee, and combined with the CAR CIDs we can shuffle the data around inside the system safe in the knowledge that we dont have to recheck the individual blocks.
- We also have a complete index of all blocks in R2 so w3s.link can serve **all** requests from R2. We can stop the slow and expensive w3s.link -> ipfs.io -> E-IPFS readspipe. see [w3s.link redirect](/0LstFiLdT8-JakVqMX4nSw)
- We can give [hoverboard 🛹](/pBOP9hsnQx25SS_jxKpX2g) full indexes, so it has full info to serve any bitswap request from R2 only

**However**

We moved away from PUTs via a worker so that we could remove limitations. We would be back to
- limiting uploaded CARs to max 100MiB again.
- *we alreadys split CARS at 100MiB*
- _we should revisit streaming writes to r2 via a worker_
- incurring a worker cost for uploaded data.
- *if we do it async we still have this cost.* the only saving is not doing the verification, which seems reputataionally risky if rare.

### Triggering a worker after a direct PUT to R2

It seems very likely that CF will make it so you can trigger a worker from a put to R2 event.

That would let us do the verifcation async, which would let us switch to using direct signed URLs again. **But we'd have to condsider where to put the hash verification barrier**. writes couldd go to a temp bucket, and be copied across when we have verified and indexed (or the existence of indexes could be used to distinguish but this seems less explicit)

### Future: Saturn?

Longer term, can we write uploaded CARs directly to Saturn and have them hash the blocks?