unified wireprotocol #348
unified wireprotocol #348
Conversation
| * "tid": "123", | ||
| * "payload": { | ||
| * "cid": "bafybeib2v" | ||
| * "bytes": [0x65, 0x66, 0x67, ...], |
There was a problem hiding this comment.
why not just send the car raw as binary? the CAR get and PUT dont need to be parsed by the server
| * "tid": "123", | ||
| * "payload": { | ||
| * "cid": "bafybeib2v" | ||
| * "bytes": [0x65, 0x66, 0x67, ...], |
There was a problem hiding this comment.
the put request to the signed upload URL generator doesnt include the bytes, the bytes are sent raw on the s3 protocol on a subsequent request
| readonly cid: CID; | ||
| } | ||
| /* | ||
| * The response to a PutCar request. |
There was a problem hiding this comment.
the signed upload url can be returned as a redirect, but today we put it in a json envelope, either is ok, but the result here should just be a URL in the s3 protocol
| * "auth": { ... } | ||
| * "meta": { ... } | ||
| * } | ||
| */ |
There was a problem hiding this comment.
we need to be able to serve unencrpyted files directly at eg: <img src="https://example.fireproof.storage/database-uuid/fileCID"/> with correct content type
There was a problem hiding this comment.
being able to PUT raw files is not required
| readonly cid: CID; | ||
| } | ||
| /* | ||
| * A request to get a META file. |
There was a problem hiding this comment.
meta isn't quite a file, its an API response, as it must be composed by the server dynamically depending on current state
| * "tid": "123", | ||
| * "payload": { | ||
| * "cid": "bafybeib2v" | ||
| * "bytes": [0x65, 0x66, 0x67, ...], |
There was a problem hiding this comment.
this might be worth taking down another layer as JSON, instead of embedding bytes. Ideally you can see the CIDs of the relevant CARs in the JSON here, it would not be a larger serialization.
| * { | ||
| * "type": "put-meta-req", | ||
| * "tid": "123", | ||
| * "payload": { |
There was a problem hiding this comment.
this doesn't have a body i dont think
| readonly cid: CID; | ||
| } | ||
| /* | ||
| * The response to a PutMeta request. |
There was a problem hiding this comment.
this should respond with the HEAD post-PUT, inclusive of the PUTs effect -- same as a GET.
| * "type": "get-wal-req", | ||
| * "tid": "123", | ||
| * "payload": { | ||
| * operations: DbMeta[]; |
There was a problem hiding this comment.
right now this means we need a WAL per remote. we could keep high water marks, but that would require a function from (encrypted) CRDT log events to carLog CIDs. Not hard to do ... but wait til after we have the next layer of testing.
There was a problem hiding this comment.
this might be a good place for @Damienkatz help
pls review and share any ideas