| … | … | @@ -319,6 +319,17 @@ export async function serveMembrane (device, { corestore, swarm, did, handle, se |
| 319 | 319 | // Blobs live in the PEER's BlobStore; the keyless bridge relays this RPC (peer-front.getBlob) and |
| 320 | 320 | // streams the bytes back. null → the bridge answers 404. bytes are hex in the c.json RPC value. |
| 321 | 321 | if (blobs) { |
| 322 | // list-blobs (com.atproto.sync.listBlobs) — PUBLIC, same reasoning as get-blob: it returns content |
| 323 | // addresses this peer already serves by CID, so it grants no access get-blob does not. |
| 324 | // |
| 325 | // ⛔ THIS SURFACE IS THE ONE THE BRIDGE TALKS TO. hpp's serve-device.js has a SEPARATE responder |
| 326 | // list, and adding the method only there produced exactly the confusing symptom you would expect: |
| 327 | // getBlob worked, listBlobs answered UNKNOWN_METHOD, and the deployed tree demonstrably contained |
| 328 | // the handler. Two surfaces, one patched. Keep them in step. |
| 329 | rpc.respond('list-blobs', async ({ limit, cursor } = {}) => { |
| 330 | if (typeof blobs.list !== 'function') return { cids: [], cursor: null, skipped: 'not-supported' } |
| 331 | return blobs.list({ limit, cursor }) |
| 332 | }) |
| 322 | 333 | rpc.respond('get-blob', async ({ cid } = {}) => { |
| 323 | 334 | if (!cid) return null |
| 324 | 335 | const b = await blobs.get(String(cid)) |