Post

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

0 reposts2 likes

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 🙃)

bryan newbold
@bnewbold.net

that language in the text isn't clear. big records should be disallowed. the '#sync' trick is for large batches of record ops

johanna
@jola.dev

Yeah, it's not very discoverable. If the relay had backoff it could've taken forever for me to realize. My alerting saying the server is pinned at 100% at least let me know about the issue!

johanna
@jola.dev

Also it seems indigo-relay will just ignore your commit and continue if it's specifically between 2MB and 2MiB ps I just can't ever remember which one of those is bigger and I have to keep checking