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

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!

0 reposts0 likes

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