ATProto Montreal Recap

The ATProto community gathered in Montreal in the first week of November 2025. IETF124 and the AT Protocol pre-BOF is the reason for gathering together, and we also took the opportunity for a couple of community days.

IETF 124 Montreal

Register today for the IETF 124 Montreal meeting on 1-7 November 2025 with 1000+ participants and 100+ sessions, including an IETF Hackathon.

We had a rough agenda in the forum that we mostly stuck to, as well as some nice meals and lots of talking to other ATProto builders.

Hackathon Sunday

We started things off on the Sunday at the IETF124 hackathon and hung out talking to IETF folks.

We left the hackathon venue and had introduced a handful of folks to poutine.

Community Days

Since not everyone attending had full IETF passes, we had help from Marc-Antoine in booking a meeting room at his co-working cooperative, ECTO. Thanks Marc-Antoine @maparent.ca !

Monday

We started with a round of introductions to hear what everyone is working on and what their challenges are.

Nick did a high speed overview of OAuth, and worked with some of the attendees on implementing AIP for their products.

Monday Social at Café Nocturne

On Monday night, Gov arranged for us to gather at Café Nocturne for a mini social, and the traditional beer & pizza. Thanks Gov @gov.glados.computer !

Video (and pizza) for everyone!

Tuesday

We were back at ECTO for a day of discussions and dug deep into a bunch of topics.

Here's a quick whiteboard photo covering a few other hints on what we discussed, that we'll cover in bullet points below.

We wrapped up Tuesday night with a great meal at a very cool sushi place recommended by Marc-Antoine called Tri Express .

Thanks Boris for paying for food, and Nick for paying for drinks!

Wednesday IETF124 Pre-BOF

Daniel wrote this up in late September in preparing for this IETF "pre-BOF". This is the first step in asking to be considered as an IETF standard:

Taking AT to the IETF | Bluesky

Last week we posted two drafts to the IETF Data Tracker. This is the first major step towards standardizing parts of AT in an effort to establish long-term governance for the protocol.

Those of us without tickets had a mini watch party at the AirBnB (apparently you're not supposed to full screen share video of your living room for a meeting?) and enjoyed all the people presenting and questions that were asked, along with a very active chat backchannel (130 people online at peak).

All of the information about joining the mailing list and Zulip rooms for the "ATP" work at the IETF can be found here:

Authenticated Transfer (atp)

Document dependencies

The reception was generally positive, with everyone encouraged to join the mailing list as the main venue for hashing out next steps. Forming a charter for the working group, and figuring what is/isn't in scope to initially bring to the IETF (Bryan's slides with green / yellow / etc boxes) seem to be the main work to do.

We wrapped things up Wednesday evening with a nice dinner.

Community Topics

Here are some brief notes on topics we covered.

Shared / Collaborative structures

Wesley from Cosmik shared thoughts on shared Collections in Semble as a use case for shared data in group-like structures. An initial owner creates a collection and then can accept in collaborators in different ways. All of them would have "two way" records showing that an account was connected to a collection, and would have to be accepted by the other side.

Bryan from Bluesky gave an alternate structure about having "community DIDs" rather than individual accounts in order to enable ownership and collaboration, and lean into all the tools around portable accounts. It does mean managing auth in different ways, something that AIP or other tools might help with to delegate control between multiple accounts.

This was a long discussion that was really good, and balanced "let's do it the quick way that is implementable in products today" vs "you're going to want to plan for shared ownership models and roles that don't trap community data with a single, personal account".

Personal Private Data

Rather than a full deep dive, we talked through tackling personal-private data as low hanging fruit.

Eli's suggestion was to essentially mirror the layout of the public repo, and insert e.g. "personal-private" in the at:// uri. Has to be implemented in a custom PDS, which leads to only some accounts having the feature.

PDS feature detection and apps having to support multiple paths isn't really a good path. Jared from Leaflet was a hard no on supporting different kinds of PDS (they have private data on their own servers, Semble plans the same for how).

One approach was that if you logged into an app that supported private data, it could have a "private data PDS" service end point, just like there is a DID doc entry for personal data server today.

Private data is going to be a big lift. The people in the room were more aligned around "classic app" private data where an appview and PDS host gate access to data with OAuth, rather than a full encryption model. Running your own PDS would be the option for those that don't trust a host.

Germ on MLS

Mark and Anna from the Germ team were in town to participate in the MLS working group.

There were a couple of distributed MLS discussions at the IETF. Here's the Distributed MLS draft that Mark contributed to:

Distributed MLS

The Messaging Layer Security (MLS) protocol enables a group of participants to negotiate a common cryptographic state for messaging, providing Forward Secrecy (FS) and Post-Compromise Security (PCS). There are some use cases where message ordering challenges may make it difficult for a group of participants to agree on a common state or use cases where reaching eventual consistency is impractical for the application. This document describes Distributed-MLS (DMLS), a composition protocol for using MLS sessions to protect messages among participants without negotiating a common group state.

We had a great discussion of how they are thinking about ATProto integration and what the challenges are of designing for a federated standard, rather than Signal's single provider.

In particular, to make an MLS implementation work on the web would take significant resources. Germ is on iOS today and can make libraries that would work on Android and desktop devices, and lean into local secure enclaves and signed apps. Making this work on the web, Facebook has previously implemented Labyrinth for this use case, and Mark's estimate was a small team of 5-6 applied cryptographers would be needed to work on the problem. So, let's consider that an annual burn rate of around $1MUSD.

There's a whole other challenge around authenticated delivery of software on the web / secure software supply chain. Content addressing and web3 dapps have done some work on this in the past.

We brainstormed a couple of things here, and it's clear that this is the sort of thing that many different applications need, including outside of ATProto, and it is a candidate for looking for a large amount of pooled funding if we hope to see cross-platform MLS that works on the web.

Other topics:

Using Microcosm for more things: Fig was in the room and got asked a bunch of questions, Constellation might be a good solution for Germ in checking the bsky social graph for blocks.

Streamplace is building the Best PDS: needs to support high throughput and lots of storage, C2PA support for every chunk of video stored in the PDS.

Notifications: lots of interest in cross app notifications, and also how ownership, opt in, and "where do the notifications show" are challenges

Scoped permissions for shared Lexicons: Jared presented a challenge about the Leaflet comments lexicon, and giving permissions for comments that means any blog could potentially edit comments of the current user on any other blog

Payments, receipts, and attestations: Leaflet subscriptions and payments, plus data structures for attesting to payment vs receipts.

Cross app collaboration: creating a Smoke Signal event in a block in Leaflet, and having it aggregated on Smoke Signal (with advanced event editing features there).

Protocol level redirects: we have AT URIs and content addressing, but sometimes things need to be migrated. What is the concept of a "redirect" record in ATProto?

We covered lots more and had really great discussions with all the builders.

Thanks

Thanks to everyone that came and participated. As well as supporting the ATP IETF standardization efforts, the opportunity to work on hard problems and different product approaches with other builders in ATProto community is so valuable.

The AT Community Fund sponsored the coworking rental that Marc-Antoine organized and for Boris' travel.

Cosmik Network paid for shared accommodation that kept costs low. and Graze supported Nick's travel and paid access to the .

Thanks to everyone that came - Wesley & Ronen from Cosmik Network / Semble , Bryan & Daniel from Bluesky, Mark & Anna from Germ Network , Jared from Leaflet , Fig of Microcosm , Eli from Streamplace , and Nick with his OAuth, AIP, Smoke Signal and many other expertises.

Check the Event Planning topic in the community forum for other upcoming events.