As many of you know, the IETF 126 is happening in Vienna next week and there is a working session on atproto on Thursday, July 23rd.
In order to show the IETF that there is interest in the topic from the community, I’m sharing how you can register for remote sessions to the IETF 126, inspired by @chadkoh.com‘s post from IETF 124 in Montreal.
Just like previously stated for the Montreal presence, I also think it is important to show that there is a vibrant community interested in atproto that is not just Bluesky
While we also have a community meetup after, generously hosted at the Metalab ( atpr-otter Vienna (@atproto.wien) ), not everyone can make it in person and I would also encourage you to look into registering for the day and calling into the atproto session.
To Participate:
- Set up a free Datatracker account: https://datatracker.ietf.org
- Get a ticket to the event. You can pay for one day here (always nice if you can expense it!) or you can apply for a Fee Waiver here (it is instant, you get a coupon code for your ticket)
- On the day you can log into the meeting by going to the Agenda and clicking on the little purple camera button.
This launches the Meetecho WebRTC app that runs in the browser. I recommend you do this before the meeting since there is a pre-flight test to get your camera and mic access and all that.
Here is a little video guide on how it works:
Meetecho Participant Tutorial
Once you are in the meeting you will be able to hear and see all the presentations, participate in chat, and get in the queue for questions! The back channel chat is very active for these kinds of sessions so it would be amazing if someone from the remote community could answer questions from the IETF in there.
—
Thank you @bmann.ca for the idea and @chadkoh.com for the previous post which inspired this one.
I look forward to seeing you there, either online or at the meetup, or both!
13 Likes
I’ll be attending remotely and will try and answer any questions in the chat 
2 Likes
I’m also going to attend the meeting remotely
Great explanation, I’ll share it through ATBrasil @atproto.com.br too
3 Likes
I will be attending remotely and will be on hand as well to answer questions!
2 Likes
I will be attending remotely as well.
2 Likes
ditto, also attending remotely. Feel free to ask if you have any questions, I’ve been involved in IETF and standards stuff a while now, so happy to help point people in the right direction.
What I would recommend doing is reviewing the agenda by areas + groups, and then creating a calendar of any sessions you may want to attend. I usually end up with getting a week pass because it can be interesting to silently drop in and observe other standard groups working, e.g., httpbis, dnsop, oauth, etc. Of course you can totally just join for ATP and then leave, but there is value in observing how things are done or learn about new things
Also, for what it’s worth, next summer is in Berlin! So:
- 126, Vienna, this week
- 127, San Francisco
- 128, TBD: somewhere in Asia
- 129, Berlin
Source: IETF | Upcoming meetings
2 Likes
I’ll also be attending virtually!
2 Likes
FYI: Session Page for those looking for start time and agenda: agenda-126-atp-03
1 Like
The official IETF upload of the meeting has been published:
3 Likes
The transcribed minutes for the meeting have been published:
Highlights:
Status and Agenda Bash
The Repo and Sync drafts will be worked together, and the authors suggested to merge the two into one.
The account identifier is suggested to be worked on first and then the URI draft.
Justin suggested that the milestones can be left as they are now. The work will be driven by the discussions in the working group.
Status of Repository and Synchronization
[Ted Hardie] - recommends not changing HTTP API endpoints until
there’s a non backward compatible change
[Phillip Hallam-Baker] - recommends moving to well-known endpoints
Possible Changes for IETF Version
[Eric Rescorla] - recommends removing secp256k1, not bothering with
ed25519, move towards MLDSA
[Ben Go] - questions whether to have these signature algorithms
specified within the doc
[David Schinazi] - recommends keeping a signature algorithm registry
within doc, keeping it to a short list, mandating implementations
upgrade to changes
The AT URI Syntax Challenge
[Ted Hardie] - recommends at:did… , strongly recommends against
other options
[David Schinazi] & [Justin Richer] - recommend against pushing for
URI changes
[Phillip Hallam-Baker] - recommends at:did…, calls out the URI slash
formats was for relative linking
Floats question
[Bryan Newbold] - concerned with relying on JSON data assumptions that
aren’t specified in JSON
[Bryan Newbold] - recommends relying on the CBOR representation rather
than parsing the JSON to check hash / signatures
[Daniel Holmgren] - concerned with requiring custom JSON parsing, but
would prefer if custom requirements stays in the CBOR encoder
Please remember to bring any contributions or comments regarding the IETF standardization of atproto to the atp mailing list.
3 Likes
