Post

Wait, so the recommended limit for CBOR record size is 1MiB but the hard limit for record blocks in sync 1.1 commits is 1MB. So you can write the record but the relays will choke on it atproto.com/specs/sync#c... atproto.com/guides/data-...

atproto.comData Validation - AT ProtocolExpectations around recommended data limits and validation

garrison

@garrison.corporate.fm

@bad-example.com ever run into this?

fig (aka:[phil])

@bad-example.com

ohhhh yeah yes. or at least, it's on my list of spec things to raise on the ietf mailing list. 1MiB hard limit is for streaming #commit payloads. ietf draft text says > Repository updates exceeding these limits MUST be communicated through #sync message instead so bigger records aren't disallowed

ietf.orgAuthenticated Transfer: Repository and SynchronizationThis document specifies a repository data structure and synchronization mechanisms for public data as part of the Authenticated Transfer Protocol (ATP). It describes encoding formats for both individu...

fig (aka:[phil])

@bad-example.com

they just need an explicit resync by sync1.1 today. but i actually think they should just be disallowed and we should enforce 1MiB everywhere (cbor, not sure if anyone has calculated the worst-case expansion size for json). arbitrarily-big: sketchy. app-specific limits: complicate sync1.1 handling

fig (aka:[phil])

@bad-example.com

and arbitrarily-big probably works against the choice to use CAR serialization. i need to survey more libraries, but iroh-car can't handle blocks larger than 4MiB *at all*, it's hard-coded. (the CAR spec has no limits documented anywhere 🙃)

17/10/26, 10:58 pm0 reposts1 like

No replies yet.