[Atp] Possible changes for IETF version

[Daniel Holmgren <[e-mail]>]

Hey folks,


I’ll be doing a session at the WG meeting at IETF 126 on some various
smaller changes and cleanups to the repository commit structure and the
wire protocol. There is a variety of changes in here, however most are
fairly mechnical. The purpose of the session is to give an overview and
start the conversation, not to reach consensus.


In preparation for that session, I thought I’d share my current list of
changes that I have in mind ahead of the meeting.


Repository Commit:

   - Currently has a “did” field on the commit object. As the spec does not
   currently (nor is expected to) mention DIDs, we probably also shouldn’t
   mention them in the commit object. I propose renaming this field to
   “account”. Other possibilities include “acc” or “identifier”, among others.
   - There is currently a “prev” field on the commit object. This is
   technically usable to reference a previous version of the repository.
   However it was mainly kept around for backwards compatibility purposes, and
   is nearly always set to `null`. I propose formally deprecating and removing
   this feature.
   - A repository commit does not have any field on it that clearly marks
   it as an AT commit. I propose adding a field to the commit `$type:
   atproto_commit` for domain separation purposes.
   - AT repositories are currently version 3. This version number is in
   each commit. Along with these changes, we would bump the version number to
   4.


Synchronization protocol:

   - There are some historical old fields on `#commit` messages such as
   `tooBig` and `blobs`. I propose formally deprecating those.
   - Synchronization protocol messages have a similar problem to repo
   commits in that they use the field “did” to refer to the account (and there
   is a mismatch between most message types and `#commit` messages which use
   the field “repo”). I propose renaming and standardizing on “account” (or
   whatever we specify for the commit field”
   - The current wire protocol for synchronization uses CBOR frames which
   are a header & payload, both CBOR-encoded and then concatenated together.
   While technically valid CBOR, we’ve found that it is somewhat unfamiliar
   and many libraries have a difficult time parsing it. I propose moving to a
   single CBOR object framing. Bluesky currently has a similar proposal for
   general XRPC subscription framing (in CBOR & in JSON). You can read that
   proposal here:
   https://github.com/bluesky-social/proposals/blob/main/0015-json-subscriptions
   - Currently the cursor of the subscription is provided on each message
   received. This is fine for larger hosts with a steady throughput of
   messages. However, it can cause some issues with low-throughput hosts. I
   propose introducing a new “cursor” message that is sent on connect that
   gives a consumer the current cursor value. More details on this can be
   found in a longer write up that Bryan Newbold posted:
   https://bnewbold.leaflet.pub/3mngmjniwlk2l
   - I’d like to bring up the possibility of alternate cursor formats,
   including time-based cursors. I’m not sure I would push for the
   necessarily, but I do think it’s worth a discussion. More details on this
   can be found in Bryan’s post as well.


Misc:

   - The current protocol supports secp256k1 & secp256r1 keys & signatures.
   I’d like to discuss adding a post-quantum cryptography system.
   - The current repository structure supports keys structured as
   “collection/record_key”. I’d like to discuss the possibility of a key
   structure for past versions of records. For instance,
   “collection/record_key/prev_hash".
   - There’s been a great discussion
   <https://mailarchive.ietf.org/arch/msg/atp/5ItSf1xkhrl92zChWq52Nut86uQ/>
   on including floating point numbers in the data model. I’m hoping that is
   its own session, however if not, then I can at least bring the topic up.


Feel free to chime in with thoughts in this thread or wait until we surface
these in Vienna. Looking forward to seeing folks there!


Thanks,

Daniel