Welcome!
", "time": "2025-11-05T14:30:33.000Z"}, {"author": "Gregory Scallan", "text": ":wave:
", "time": "2025-11-05T14:30:44.000Z"}, {"author": "Ryan Barrett", "text": ":joy:
", "time": "2025-11-05T14:30:52.000Z"}, {"author": "Wendy Seltzer", "text": "Here for the Krebs cycle!
", "time": "2025-11-05T14:31:16.000Z"}, {"author": "Boris Mann", "text": ":joy:
", "time": "2025-11-05T14:31:38.000Z"}, {"author": "Chad Kohalyk", "text": ":wave:
", "time": "2025-11-05T14:31:44.000Z"}, {"author": "Richard Barnes", "text": "Should have signed up Krebs on Security to report on it!
", "time": "2025-11-05T14:31:51.000Z"}, {"author": "Aaron Parecki", "text": "Justin coming in hot with the lawyer speak
", "time": "2025-11-05T14:32:26.000Z"}, {"author": "Bumblefudge", "text": ":call_me:
", "time": "2025-11-05T14:32:45.000Z"}, {"author": "Orie Steele", "text": "https://mailman3.ietf.org/mailman3/lists/atp.ietf.org/
", "time": "2025-11-05T14:35:04.000Z"}, {"author": "Richard Barnes", "text": "https://datatracker.ietf.org/group/atp/about/
", "time": "2025-11-05T14:35:41.000Z"}, {"author": "Richard Barnes", "text": "^^^ to sign up for the mailing list
", "time": "2025-11-05T14:35:46.000Z"}, {"author": "Justin Richer", "text": "I have not yet begun to lawyer!
", "time": "2025-11-05T14:36:53.000Z"}, {"author": "Justin Richer", "text": "remote folks - is speaker audio at a good level?
", "time": "2025-11-05T14:39:30.000Z"}, {"author": "Bumblefudge", "text": "yeah it's good
", "time": "2025-11-05T14:39:41.000Z"}, {"author": "Ryan Barrett", "text": ":+1:
", "time": "2025-11-05T14:39:45.000Z"}, {"author": "Mallory Knodel", "text": "Yes thanks
", "time": "2025-11-05T14:39:45.000Z"}, {"author": "Justin Richer", "text": "ok, thanks!
", "time": "2025-11-05T14:39:46.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Is identity here the network identity, like IP address?
", "time": "2025-11-05T14:41:32.000Z"}, {"author": "Aaron Parecki", "text": "no, he will probably explain it more shortly
", "time": "2025-11-05T14:41:57.000Z"}, {"author": "Daniel Holmgren", "text": "identity is a global resolvable user identifier abstracted from network identity
", "time": "2025-11-05T14:42:09.000Z"}, {"author": "Martin Thomson", "text": "\"strong norm\" seems like it won't hold
", "time": "2025-11-05T14:42:11.000Z"}, {"author": "Bumblefudge", "text": "more like two identifiers, one human-readable (mutable) and one machine-readable (longlived)
", "time": "2025-11-05T14:42:12.000Z"}, {"author": "Orie Steele", "text": "See also https://atproto.com/guides/identity
", "time": "2025-11-05T14:42:22.000Z"}, {"author": "Ted Hardie", "text": "\"organization boundary\" is doing some heavy lifting here. Some more unpacking of that would likely be useful (based on the architecture document, this does not quite mean what you might expect).
", "time": "2025-11-05T14:42:26.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Daniel Holmgren said:
\n\n\nidentity is a global resolvable user identifier abstracted from network identity
\n
Who does this global resolution?
", "time": "2025-11-05T14:43:01.000Z"}, {"author": "Ted Hardie", "text": "URIs, thirsty work.
", "time": "2025-11-05T14:43:26.000Z"}, {"author": "Ryan Barrett", "text": "anyone can resolve a handle (user-visible identity). https://atproto.com/specs/handle#handle-resolution
", "time": "2025-11-05T14:44:11.000Z"}, {"author": "Daniel Holmgren", "text": "identifiers are currently DIDs (w3c standard) which have a flexible resolution method
", "time": "2025-11-05T14:44:13.000Z"}, {"author": "Richard Barnes", "text": "@Usama - Lots of these details coming up :)
", "time": "2025-11-05T14:44:28.000Z"}, {"author": "Ryan Barrett", "text": "oh sorry, DIDs, yes. https://atproto.com/specs/did
", "time": "2025-11-05T14:44:32.000Z"}, {"author": "Martin Thomson", "text": "Hopefully we'll get to the point where we will learn what is proposed to be in scope.
", "time": "2025-11-05T14:44:56.000Z"}, {"author": "Aaron Parecki", "text": "but only 2 DID methods: \"AT Protocol supports the DID PLC and DID Web variants.\"
", "time": "2025-11-05T14:45:05.000Z"}, {"author": "Martin Thomson", "text": "Because DIDs are W3C
", "time": "2025-11-05T14:45:06.000Z"}, {"author": "Richard Barnes", "text": "i don't think there's any proposal to change DID at all, at most to use DIDs
", "time": "2025-11-05T14:45:29.000Z"}, {"author": "Martin Thomson", "text": "I don't think that the intent with DID was to limit the methods that way.
", "time": "2025-11-05T14:45:29.000Z"}, {"author": "Richard Barnes", "text": "@Martin - there are 200+ DID methods, no app is going to support all of them
", "time": "2025-11-05T14:45:51.000Z"}, {"author": "Richard Barnes", "text": "But one scoping question here is whether a WG here would have to think about DIDs at all
", "time": "2025-11-05T14:46:22.000Z"}, {"author": "Boris Mann", "text": "Yep, was just going to say the same. Different DID methods have very different trade offs.
", "time": "2025-11-05T14:46:25.000Z"}, {"author": "Ted Hardie", "text": "@Richard but there's no particular reason that users of AT other than Bluesky would be limited to those two, right?
", "time": "2025-11-05T14:46:25.000Z"}, {"author": "Bumblefudge", "text": "yeah i think it's pretty typical to start from 1 or 2 methods and maybe expand to 3 or 5 over time, in most projects that compare notes at DIF :D
", "time": "2025-11-05T14:46:26.000Z"}, {"author": "Heather Flanagan", "text": "\u201cA big ball of yarn\u201d - giggles ensue from the knitters\u2019 corner in the room.
", "time": "2025-11-05T14:47:00.000Z"}, {"author": "Boris Mann", "text": "@Ted the community has been pretty convergent in wanting a smaller set of fit for purpose DIDs
", "time": "2025-11-05T14:47:26.000Z"}, {"author": "Bumblefudge", "text": "@Ted, the issue is that all the load-bearing parts of the system need to be able to resolve many many DIDs per pageload, so each additional DID method exponentially makes everything more expensive (at least in the usecases I've seen)
", "time": "2025-11-05T14:47:32.000Z"}, {"author": "Martin Thomson", "text": "On this slide, the \"encoding\" line is soooo uninteresting
", "time": "2025-11-05T14:48:11.000Z"}, {"author": "Nick Doty", "text": "? RSS feeds include the full data of the post in most cases
", "time": "2025-11-05T14:48:19.000Z"}, {"author": "Boris Mann", "text": "There are, of course, lots of orgs that want their favourite DID method included, and it will likely expand over time, but more likely on a cadence of years
", "time": "2025-11-05T14:48:36.000Z"}, {"author": "Richard Barnes", "text": "\"encoding = Email\" :shrug::rolling_on_the_floor_laughing:
", "time": "2025-11-05T14:48:45.000Z"}, {"author": "Martin Thomson", "text": "RSS/Atom can include the full message, but it isn't really the full message.
", "time": "2025-11-05T14:48:47.000Z"}, {"author": "Aaron Parecki", "text": "RSS _can_ include the full post but the vast majority switched to summaries long ago because they wanted to force people back to the site to read the whole post
", "time": "2025-11-05T14:48:48.000Z"}, {"author": "Ted Hardie", "text": "@Boris, but AT as a building block is not dependent on this, if I understand correctly. You could use it with something other thatn did:plc if that mad sense in your environment. Is that also your understanding? (Not arguing that any app would support 200).
", "time": "2025-11-05T14:49:07.000Z"}, {"author": "Martin Thomson", "text": "What appears in Atom/RSS is still just a copy. The canonical content is still where the URL points.
", "time": "2025-11-05T14:49:17.000Z"}, {"author": "Nick Doty", "text": "but at a protocol level -- how much the author decides to keep in the post, RSS syndicates content, not just metadata
", "time": "2025-11-05T14:49:22.000Z"}, {"author": "Richard Barnes", "text": "@Ted - in principle I think you could use it without DID at all, as long as you have some way to associate public keys with identities
", "time": "2025-11-05T14:49:44.000Z"}, {"author": "Richard Barnes", "text": "like i said, interesting scoping question
", "time": "2025-11-05T14:49:57.000Z"}, {"author": "Aaron Parecki", "text": "@Nick RSS is still a view of the original content, not the actual data that was authored
", "time": "2025-11-05T14:50:08.000Z"}, {"author": "Ryan Barrett", "text": "the problem is interop. the protocol currently specifies (requires) only did:plc or did:web. if you introduced other methods, you couldn't expect other consumers in the ecosystem to handle them
", "time": "2025-11-05T14:50:18.000Z"}, {"author": "Boris Mann", "text": "@Ted certainly. The \"main AT network\" has strong network effects to run on the main methods.
", "time": "2025-11-05T14:50:23.000Z"}, {"author": "Eli Mallon", "text": "@Richard The \"DID Doc\" plays a bit role in identity resolution. You could do lots of method but \"no DID\" probably means \"no DID doc\" which would be a problem
", "time": "2025-11-05T14:50:46.000Z"}, {"author": "Nick Doty", "text": "@aaron depends on the author and type. I'm not sure everyone publishing RSS thinks of the web version of the content as first or canonical
", "time": "2025-11-05T14:50:58.000Z"}, {"author": "Aaron Parecki", "text": "the \"depends\" is the difference between this and RSS that you are looking for then
", "time": "2025-11-05T14:51:25.000Z"}, {"author": "Bumblefudge", "text": "yeah I think podcasts and blogs/webpublishers use the protocol p differently!
", "time": "2025-11-05T14:52:10.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Regarding expert review, has any formal analysis been done for this protocol in-house in Bluesky or publicly available?
", "time": "2025-11-05T14:53:20.000Z"}, {"author": "Justin Richer", "text": "here's the most important part about what the proposed scope is , for those who were asking
", "time": "2025-11-05T14:53:46.000Z"}, {"author": "Daniel Holmgren", "text": "(next slide will be more helpful lol)
", "time": "2025-11-05T14:54:17.000Z"}, {"author": "Rich Salz", "text": "\"What we know about the IETF\". Brilliant.
", "time": "2025-11-05T14:54:46.000Z"}, {"author": "Ted Hardie", "text": "I'd really like to map this back to slide 7, but it would probably be unreadable.
", "time": "2025-11-05T14:55:41.000Z"}, {"author": "Martin Thomson", "text": "The \"DataGraph\" layer will to some degree dictate the synchronization layer operation. URIs seem like they would need to be in-scope for IETF, even if that isn't what they are looking at here.
", "time": "2025-11-05T14:55:49.000Z"}, {"author": "Bumblefudge", "text": "^ +1
", "time": "2025-11-05T14:56:08.000Z"}, {"author": "Ryan Barrett", "text": "not sure. for just repo and firehose, I don't think at:// URIs specifically are load bearing
", "time": "2025-11-05T14:56:34.000Z"}, {"author": "Martin Thomson", "text": "Even if they aren't in scope, anything at that layer will need to stipulate what properties those things need to have.
", "time": "2025-11-05T14:56:55.000Z"}, {"author": "Nick Doty", "text": "I appreciate the not-gaslighting about its being centralized
", "time": "2025-11-05T14:57:06.000Z"}, {"author": "Evan Prodromou", "text": "The characterisation of ActivityPub is incorrect
", "time": "2025-11-05T14:57:14.000Z"}, {"author": "Ted Hardie", "text": "The at uri scheme was provisionally registered already; moving it to permanent would take some work, but it is probably not a huge lift. I
", "time": "2025-11-05T14:57:28.000Z"}, {"author": "Evan Prodromou", "text": "We have a variable amount of data, depending on if you're pushing or pulling
", "time": "2025-11-05T14:57:29.000Z"}, {"author": "Andrew Newton", "text": "I know this isn't a wg-forming bof, but what is the desired outcome? Is it just \"this seems sane to bring to the IETF?\"
", "time": "2025-11-05T14:57:32.000Z"}, {"author": "Eric Rescorla", "text": "I think so.
", "time": "2025-11-05T14:57:38.000Z"}, {"author": "Evan Prodromou", "text": "And we have a distributed database; it's just across the Web
", "time": "2025-11-05T14:57:39.000Z"}, {"author": "Martin Thomson", "text": "Yeah, I don't think that the URI is a major consideration, but you will need a functional abstraction of the units that the protocols handle.
", "time": "2025-11-05T14:58:21.000Z"}, {"author": "Bumblefudge", "text": ":woman_raising_hand:
", "time": "2025-11-05T14:58:47.000Z"}, {"author": "Ryan Barrett", "text": "good q
", "time": "2025-11-05T14:59:13.000Z"}, {"author": "Ted Hardie", "text": "Please remember, folks, to say your name at the mic.
", "time": "2025-11-05T14:59:55.000Z"}, {"author": "Richard Barnes", "text": "presumably the hope would be that the AT community would overlap with the AT WG
", "time": "2025-11-05T15:00:12.000Z"}, {"author": "Ryan Barrett", "text": ":+1:
", "time": "2025-11-05T15:00:30.000Z"}, {"author": "Boris Mann", "text": "The community would like to participate in the IETF rather than roll our own spec process
", "time": "2025-11-05T15:01:03.000Z"}, {"author": "Martin Thomson", "text": "the pig just needs more grease
", "time": "2025-11-05T15:01:07.000Z"}, {"author": "Aaron Parecki", "text": "need a bigger anaconda
", "time": "2025-11-05T15:01:14.000Z"}, {"author": "Justin Richer", "text": "martin why
", "time": "2025-11-05T15:01:14.000Z"}, {"author": "Rich Salz", "text": "\"don't want to bring too much\". these people did their homework.
", "time": "2025-11-05T15:01:23.000Z"}, {"author": "Lars Eggert", "text": "I mean, the first thing the IETF is going to do is of course make everything network byte order like it's 1999.
", "time": "2025-11-05T15:01:34.000Z"}, {"author": "Ryan Barrett", "text": "did:little-endian:
", "time": "2025-11-05T15:01:54.000Z"}, {"author": "Ted Hardie", "text": "@Martin is it a K\u0101lua pig?
", "time": "2025-11-05T15:01:56.000Z"}, {"author": "Eric Rescorla", "text": "It seems to me that the
\nLars Eggert said:
\n\n\nI mean, the first thing the IETF is going to do is of course make everything network byte order like it's 1999.
\n
We should actually swap the endianness, whatever it is
", "time": "2025-11-05T15:02:06.000Z"}, {"author": "Martin Thomson", "text": "@Ted Hardie I was thinking in the wrestling sense.
", "time": "2025-11-05T15:02:30.000Z"}, {"author": "Richard Barnes", "text": "@Ted thanks, now i'm salivating
", "time": "2025-11-05T15:03:25.000Z"}, {"author": "Boris Mann", "text": "woo hoo! Tony and I made it into the screenshot
", "time": "2025-11-05T15:03:41.000Z"}, {"author": "Nick Doty", "text": "that doesn't seem true at all. a centralized closed service could also provide options for custom feeds.
", "time": "2025-11-05T15:04:12.000Z"}, {"author": "Boris Mann", "text": "Permissionlessly by any actors, including adversarial ones @Nick
", "time": "2025-11-05T15:04:41.000Z"}, {"author": "Martin Thomson", "text": "A circle is a little bit ...closed, isn't it?
", "time": "2025-11-05T15:04:45.000Z"}, {"author": "Eric Rescorla", "text": "Nick Doty said:
\n\n\nthat doesn't seem true at all. a centralized closed service could also provide options for custom feeds.
\n
Agreed. I'm not sure what the argument is there
", "time": "2025-11-05T15:04:45.000Z"}, {"author": "Martin Thomson", "text": "An open protocol will have a lot more arrows leaving it.
", "time": "2025-11-05T15:05:09.000Z"}, {"author": "Eric Rescorla", "text": "Martin Thomson said:
\n\n\nA circle is a little bit ...closed, isn't it?
\n
Well there were some gaps where it had \"protocol\" written
", "time": "2025-11-05T15:05:17.000Z"}, {"author": "Muhammad Usama Sardar", "text": "To be clear: Customers do need to trust Bluesky for their services, right?
", "time": "2025-11-05T15:05:21.000Z"}, {"author": "Justin Richer", "text": "@Martin this is the loop from the company's perspective
", "time": "2025-11-05T15:05:23.000Z"}, {"author": "Eric Rescorla", "text": "Muhammad Usama Sardar said:
\n\n\nTo be clear: Customers do need to trust Bluesky for their services, right?
\n
Blue sky customers do. The idea would be that you could start IetfSky that wouldn't need to
", "time": "2025-11-05T15:05:39.000Z"}, {"author": "Justin Richer", "text": "not necessarily what it'd look like here
", "time": "2025-11-05T15:05:41.000Z"}, {"author": "Boris Mann", "text": "@Mohammad accounts can be hosted by multiple providers, multiple front ends can connect into the data
", "time": "2025-11-05T15:05:47.000Z"}, {"author": "Nick Doty", "text": "@Boris I agree that an open protocol would be better. I just don't understand why Bluesky claims that it's relying on those features when it fact it seems set up to work entirely closed.
", "time": "2025-11-05T15:05:50.000Z"}, {"author": "Orie Steele", "text": "what justin said
", "time": "2025-11-05T15:05:56.000Z"}, {"author": "Boris Mann", "text": "One of the more interesting feeds is called \"For You\" and is run out of a home gaming PC and a WireGuard VPN
", "time": "2025-11-05T15:07:21.000Z"}, {"author": "Boris Mann", "text": "XBlock as labeled is also run from a home PC in the UK
", "time": "2025-11-05T15:07:36.000Z"}, {"author": "Eric Rescorla", "text": "To follow on to Nick, it seems to me quite possible that someone (E.g., Nick) could stand up MySky.app that didn't allow people to subscribe to these feeds
", "time": "2025-11-05T15:07:47.000Z"}, {"author": "Martin Thomson", "text": "Is moderation a data plane thing or does it affect the transfer?
", "time": "2025-11-05T15:08:06.000Z"}, {"author": "Eric Rescorla", "text": "Martin Thomson said:
\n\n\nIs moderation a data plane thing or does it affect the transfer?
\n
Data plane. It's tagging
", "time": "2025-11-05T15:08:25.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Where are Bluesky services hosted? on-premise or cloud?
", "time": "2025-11-05T15:08:35.000Z"}, {"author": "Martin Thomson", "text": "But is it exclusively tagging or is there a filter in place somewhere?
", "time": "2025-11-05T15:08:43.000Z"}, {"author": "Boris Mann", "text": "@Mohammad bare metal colos
", "time": "2025-11-05T15:08:51.000Z"}, {"author": "Eric Rescorla", "text": "Muhammad Usama Sardar said:
\n\n\nWhere are Bluesky services hosted? on-premise or cloud?
\n
It's complicated.
", "time": "2025-11-05T15:09:00.000Z"}, {"author": "Nick Doty", "text": "I think Bluesky has suggested that they would moderate just with labeling, but of course they could also block transfers or block access to the data, or block access to an identity, if they wanted to
", "time": "2025-11-05T15:09:06.000Z"}, {"author": "Martin Thomson", "text": "If a government were to ask that \"Rude\" posts not be sent to children, what then?
", "time": "2025-11-05T15:09:17.000Z"}, {"author": "Boris Mann", "text": "@Martin there is network abuse spam/ip/CSAM blocking
", "time": "2025-11-05T15:09:23.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Boris Mann said:
\n\n\n@Mohammad bare metal colos
\n
What does that mean exactly?
", "time": "2025-11-05T15:09:24.000Z"}, {"author": "Muhammad Usama Sardar", "text": "as in bare metals on the cloud?
", "time": "2025-11-05T15:09:48.000Z"}, {"author": "Rich Salz", "text": "They are renting full servers in various datacenters. Not running as VMs.
", "time": "2025-11-05T15:09:49.000Z"}, {"author": "Martin Thomson", "text": "@Boris Mann exactly my point. So the question is whether that is in scope.
", "time": "2025-11-05T15:09:52.000Z"}, {"author": "Ted Hardie", "text": "@Martin https://www.ietf.org/archive/id/draft-newbold-at-architecture-00.html#name-labeling. mostly tagging, but they acknowledge that there is some \"infrastructure\" take down, which implies removing posts/individuals in reaction to LE demands.
", "time": "2025-11-05T15:09:54.000Z"}, {"author": "Bryan Newbold", "text": "@martin it is complicated: we try to primarily use \"labeling\" which is data annotation, but there is also unavoidable infra-layer moderation (especially of media files)
\nlonger deep dive: https://whtwnd.com/bnewbold.net/3m2j6ccx2bs2t
Muhammad Usama Sardar said:
\n\n\nBoris Mann said:
\n\n\n@Mohammad bare metal colos
\nWhat does that mean exactly?
\n
Is your question where bsky hosts their services? Or where the network as a whole is. Because as discussed here, you can have your data on your own pds
", "time": "2025-11-05T15:10:14.000Z"}, {"author": "Bumblefudge", "text": "I like Martin's hypothetical. Let's say Turkey wants to block all !rude from all children
", "time": "2025-11-05T15:10:20.000Z"}, {"author": "Ryan Barrett", "text": "https://bsky.social/about/blog/09-10-2025-age-assurance-approach
", "time": "2025-11-05T15:10:39.000Z"}, {"author": "Martin Thomson", "text": "I'm not asking about the solution necessarily. I'm asking about whether the IETF will be engaging with that. And it sounds like we might be.
", "time": "2025-11-05T15:11:04.000Z"}, {"author": "Dan York", "text": "(Suddenly feeling like I need to pay a bit more attention to the AT ecosystem... I wasn't aware of all the other groups building on this)
", "time": "2025-11-05T15:11:18.000Z"}, {"author": "Eli Mallon", "text": "(We'd love for MORE of the Streamplace features to go over AT and are interested in helping extend the protocol to support those use cases FWIW
", "time": "2025-11-05T15:11:47.000Z"}, {"author": "Boris Mann", "text": "Yeah, there are 2000+ self hosted personal data servers https://blue.mackuba.eu/directory/pdses
", "time": "2025-11-05T15:11:50.000Z"}, {"author": "Ted Hardie", "text": "I think the tagging was marked as \"maybe later\". The infrastructure level stuff would have to be out of scope at the IETF (note that the labeling has other functions than suppression).
", "time": "2025-11-05T15:11:54.000Z"}, {"author": "Ryan Barrett", "text": ":+1:
", "time": "2025-11-05T15:12:09.000Z"}, {"author": "Evan Prodromou", "text": "Then why did we just have that presentation?
", "time": "2025-11-05T15:12:25.000Z"}, {"author": "Bumblefudge", "text": "+1
", "time": "2025-11-05T15:12:27.000Z"}, {"author": "Bumblefudge", "text": "(to social dimension being in scope of a technosocial protocol)
", "time": "2025-11-05T15:12:40.000Z"}, {"author": "Aaron Parecki", "text": "to learn about practical uses of ATProto
", "time": "2025-11-05T15:12:45.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Eric Rescorla said:
\n\n\nMuhammad Usama Sardar said:
\n\n\nBoris Mann said:
\n\n\n@Mohammad bare metal colos
\nWhat does that mean exactly?
\nIs your question where bsky hosts their services? Or where the network as a whole is. Because as discussed here, you can have your data on your own pds
\n
Both. I am trying to get an overall idea of how this whole thing is working.
", "time": "2025-11-05T15:13:10.000Z"}, {"author": "Boris Mann", "text": "Including that many non microblogging use cases don't have feeds at all
", "time": "2025-11-05T15:13:16.000Z"}, {"author": "Nick Doty", "text": "agree that we will need to discuss the social dimensions / handling abuse etc., even if I agree that the Bluesky company's moderation features might not be the focus for this meeting
", "time": "2025-11-05T15:13:17.000Z"}, {"author": "Martin Thomson", "text": "we do need to understand implications and consequences of what we're building, but Justin was absolutely right to stop that line of inquiry.
", "time": "2025-11-05T15:13:20.000Z"}, {"author": "Aaron Parecki", "text": "+1 martin
", "time": "2025-11-05T15:13:32.000Z"}, {"author": "Justin Richer", "text": "@bumblefudge - yes but we dont' have enough time to dive into that part of the discussion right now, today
", "time": "2025-11-05T15:13:35.000Z"}, {"author": "Wendy Seltzer", "text": "If the question had been what protocol hooks are available for global and local moderation, that might be closer to IETF scope
", "time": "2025-11-05T15:13:41.000Z"}, {"author": "Richard Barnes", "text": "i would note that moderation is not a feature of all of the AT applications we're going to see here
", "time": "2025-11-05T15:13:42.000Z"}, {"author": "Eric Rescorla", "text": "To the extent to which there is a question for IETF, I think it's something like \"is it a good thing to have a global microblogging type design where users get to choose their own content display experience without having it imposed by some central system\"
", "time": "2025-11-05T15:13:54.000Z"}, {"author": "Richard Barnes", "text": "or at least that T&S looks very different in the different apps
", "time": "2025-11-05T15:14:01.000Z"}, {"author": "Martin Thomson", "text": "In other words, I thank the chairs for applying moderation to questions about moderation.
", "time": "2025-11-05T15:14:02.000Z"}, {"author": "Bumblefudge", "text": ":rolling_on_the_floor_laughing: BUT MY FREEE SPEEEECH
", "time": "2025-11-05T15:14:16.000Z"}, {"author": "Nick Doty", "text": "if AT is designed to transfer all of the data in the payload, then what does it matter where it's \"hosted\" in a PDS?
", "time": "2025-11-05T15:14:52.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Rich Salz said:
\n\n\nThey are renting full servers in various datacenters. Not running as VMs.
\n
so they have cloud-based services.
", "time": "2025-11-05T15:15:13.000Z"}, {"author": "Justin Richer", "text": "@martin thank you, and I see what you did there
", "time": "2025-11-05T15:15:15.000Z"}, {"author": "Eric Rescorla", "text": "Nick Doty said:
\n\n\nif AT is designed to transfer all of the data in the payload, then what does it matter where it's \"hosted\" in a PDS?
\n
Ask that question again?
", "time": "2025-11-05T15:15:52.000Z"}, {"author": "Martin Thomson", "text": "I think that Nick is asking: if the content is pushed out, what role does the PDS - as the source of the push - play after that point?
", "time": "2025-11-05T15:16:35.000Z"}, {"author": "Nick Doty", "text": "@ekr, I'm unclear what significance there is to different PDS hosts if the hosted content doesn't need to be accessed by any of the other actors in the system
", "time": "2025-11-05T15:16:44.000Z"}, {"author": "Boris Mann", "text": "The source of truth lies with each account. The account delegates to a hosting provider, running a PDS. The PDS emits post events, and that gets aggregated as a scaling factor.
", "time": "2025-11-05T15:17:07.000Z"}, {"author": "Boris Mann", "text": "Any app can index and aggregate by reaching back to the PDS.
", "time": "2025-11-05T15:17:21.000Z"}, {"author": "Martin Thomson", "text": "I thought that the source of truth was cryptographic, ultimately.
", "time": "2025-11-05T15:17:27.000Z"}, {"author": "Ryan Barrett", "text": "it's a good question though. PDSes serve other access patterns too, eg fetching individual records and entire repos
", "time": "2025-11-05T15:17:29.000Z"}, {"author": "Boris Mann", "text": "And different apps can have different policies about data types or moderation
", "time": "2025-11-05T15:17:37.000Z"}, {"author": "Bryan Newbold", "text": "@Nick: the PDS in AT is relatively commodity: it they are not particularly differentiated or a nucleus for community.
\nthey might provide more or less reliable service, have different privacy policies, etc
Without ever removing ownership and existence of the user data.
", "time": "2025-11-05T15:17:54.000Z"}, {"author": "Bumblefudge", "text": "@Martin yes, most PDSs sign each message to authenticate it with a public key in the then-current DID doc to enable verifiability across service-provider changes
", "time": "2025-11-05T15:18:08.000Z"}, {"author": "Eric Rescorla", "text": "@Nick Doty I think the answer here is that you don't need to (for instance) conform to some other system's policies, so, if bsky.app says \"no cat pictures\" you can move your PDS and send out cat pictures
", "time": "2025-11-05T15:18:13.000Z"}, {"author": "Boris Mann", "text": "@Martin yes the account repository is all signed data
", "time": "2025-11-05T15:18:16.000Z"}, {"author": "Ryan Barrett", "text": "if consumers like relays get out of sync for a given repo, they can re-fetch it in part or whole to help re-sync
", "time": "2025-11-05T15:18:17.000Z"}, {"author": "Bumblefudge", "text": "but each user has at any given time ONE PDS per DID/\"account\"
", "time": "2025-11-05T15:18:30.000Z"}, {"author": "Martin Thomson", "text": "I think of the PDS and ATP as different types of distribution for the content. Complementary.
", "time": "2025-11-05T15:18:32.000Z"}, {"author": "Patrick Singletary", "text": "it's identity based control rather that network based control
", "time": "2025-11-05T15:18:33.000Z"}, {"author": "Ted Hardie", "text": "A big question here, give that the \"firehose stream\" is one of the early targets for standardization is whether a different approach to data distribution could be proposed with any later WG. A charter limited to that approach would rule out a lot of other approaches that might be more useful at different scales.
", "time": "2025-11-05T15:18:48.000Z"}, {"author": "Martin Thomson", "text": "In that view, ONE PDS doesn't really make sense.
", "time": "2025-11-05T15:18:59.000Z"}, {"author": "Eric Rescorla", "text": "But Daniel and I were actually just talking pre-meeting about inverting the flow of control and having the PDS push
", "time": "2025-11-05T15:19:01.000Z"}, {"author": "Bumblefudge", "text": "+1 Ted
", "time": "2025-11-05T15:19:15.000Z"}, {"author": "Eric Rescorla", "text": "Or rather, I was talking about it, and he didn't like it :)
", "time": "2025-11-05T15:19:16.000Z"}, {"author": "Nick Doty", "text": "@bryan indeed it doesn't seem like the user gets any decentralization or any different moderation policies by moving their PDS to a different host
", "time": "2025-11-05T15:19:29.000Z"}, {"author": "Boris Mann", "text": "The PDS pings which relays it registers with
", "time": "2025-11-05T15:19:38.000Z"}, {"author": "Ryan Barrett", "text": "lol. if one goal of the protocol is that PDSes don't need to scale with consumption, then push degrades that a bit
", "time": "2025-11-05T15:19:49.000Z"}, {"author": "Eric Rescorla", "text": "Nick Doty said:
\n\n\n@bryan indeed it doesn't seem like the user gets any decentralization or any different moderation policies by moving their PDS to a different host
\n
No, I think it does.
", "time": "2025-11-05T15:19:50.000Z"}, {"author": "Boris Mann", "text": "We don't really want to have the PDS be that chatty
", "time": "2025-11-05T15:19:52.000Z"}, {"author": "Eric Rescorla", "text": "Ryan Barrett said:
\n\n\nlol. if one goal of the protocol is that PDSes don't need to scale with consumption, then push degrades that a bit
\n
No, you'd just push to the relays that you otherwise had pulling from you
", "time": "2025-11-05T15:20:09.000Z"}, {"author": "Eric Rescorla", "text": "Eric Rescorla said:
\n\n\nRyan Barrett said:
\n\n\nlol. if one goal of the protocol is that PDSes don't need to scale with consumption, then push degrades that a bit
\nNo, you'd just push to the relays that you otherwise had pulling from you
\n
It's essentially the same performance wise
", "time": "2025-11-05T15:20:25.000Z"}, {"author": "Boris Mann", "text": "The entire network of 40M accounts has relays running on RPis on home internet
", "time": "2025-11-05T15:20:26.000Z"}, {"author": "Ryan Barrett", "text": "ah, sure. the push/pull distinction gets less meaningful then, but sure
", "time": "2025-11-05T15:20:32.000Z"}, {"author": "Eric Rescorla", "text": "Ryan Barrett said:
\n\n\nah, sure. the push/pull distinction gets less meaningful then, but sure
\n
The reason we were discussing it was for DoS resistance, because a client is harder to DoS than a server.
", "time": "2025-11-05T15:20:50.000Z"}, {"author": "Ryan Barrett", "text": "PDSes already send requestCrawl messages to relays to start them reading their firehoses, so they're already slightly push :grinning_face_with_smiling_eyes:
", "time": "2025-11-05T15:21:05.000Z"}, {"author": "Martin Thomson", "text": "@ekr ... PTTH
", "time": "2025-11-05T15:21:10.000Z"}, {"author": "Richard Barnes", "text": "i mean, if your PDS vanishes, your data is kinda gone
", "time": "2025-11-05T15:21:11.000Z"}, {"author": "Ted Hardie", "text": "@ekr there are some differences for systems which are only intermittently available. That's not the Bsky use case, but it might be worth considering.
", "time": "2025-11-05T15:21:14.000Z"}, {"author": "Bumblefudge", "text": "push once, pull every 5 min forever
", "time": "2025-11-05T15:21:18.000Z"}, {"author": "Boris Mann", "text": "@richard no your data is not gone
", "time": "2025-11-05T15:21:31.000Z"}, {"author": "Boris Mann", "text": "Because it's all signed, so you can fetch it from a relay, an archive, or a backup
", "time": "2025-11-05T15:21:53.000Z"}, {"author": "Bumblefudge", "text": "@richard there are backups and ways to rotate away from a dead/hostile provider thanks to DID doc semantics
", "time": "2025-11-05T15:21:55.000Z"}, {"author": "Eric Rescorla", "text": "Bumblefudge said:
\n\n\npush once, pull every 5 min forever
\n
Right, this is another reason why one might think push was nice
", "time": "2025-11-05T15:22:36.000Z"}, {"author": "Bumblefudge", "text": "if your DID doc includes a \"recovery\" key, you can sign a message moving to a new one and the DID directories (well currently there is only one authoritative one) will catch that message and honor it, basically
", "time": "2025-11-05T15:22:39.000Z"}, {"author": "Kathleen Moriarty", "text": "The chart in the overview presentation provided a nice breakdown in response to Usama
", "time": "2025-11-05T15:22:47.000Z"}, {"author": "Nick Doty", "text": "@bumblefudge -- sure, if someone backed up the data, then it isn't permanently gone when the host disappears. but that's not some special property of PDS, that's just like a website?
", "time": "2025-11-05T15:22:49.000Z"}, {"author": "Boris Mann", "text": "It's signed data @nick so it's provably the same data
", "time": "2025-11-05T15:23:28.000Z"}, {"author": "Ryan Barrett", "text": "early on, Bluesky talked about having clients (including client devices) keep full copies of your data and repo, so you could use those to recover if your PDS died
", "time": "2025-11-05T15:23:29.000Z"}, {"author": "Ryan Barrett", "text": "that got deprioritized but it's still interesting
", "time": "2025-11-05T15:23:36.000Z"}, {"author": "Ryan Barrett", "text": "and possible
", "time": "2025-11-05T15:23:37.000Z"}, {"author": "Boris Mann", "text": "Including that you can trustlessly fetch that data from anywhere that has a copy
", "time": "2025-11-05T15:23:42.000Z"}, {"author": "Boris Mann", "text": "vs. HTTP \"tyranny of origin\"
", "time": "2025-11-05T15:23:49.000Z"}, {"author": "Akshay Oppilippan", "text": "im akshay also from tangled! ill be available on the chat
", "time": "2025-11-05T15:23:56.000Z"}, {"author": "Bumblefudge", "text": "@Nick sure, my point is just that the did, not the server/PDS domain is the authority of the at:// URIs that all the data is organized around
", "time": "2025-11-05T15:24:16.000Z"}, {"author": "Lisa Dusseault", "text": "Data portability enters the chat
", "time": "2025-11-05T15:24:21.000Z"}, {"author": "Eli Mallon", "text": "if the concern is PDS scalability you could also have relays pull from other partial relays. there hasn't been a lot of need for that topology but it's totally possible (ask the bluesky team about the time their relay started ingesting itself!)
", "time": "2025-11-05T15:24:25.000Z"}, {"author": "Justin Richer", "text": "what's interesting to me here is that git is decentralized, by design, but github is not
", "time": "2025-11-05T15:25:03.000Z"}, {"author": "Richard Barnes", "text": "Caches all the way down
", "time": "2025-11-05T15:25:04.000Z"}, {"author": "Bumblefudge", "text": "the dream of DIDs as user portability mechanism finally made it to prod after all these years (insofar as these APIs last and are reimplemented antagonistically)
", "time": "2025-11-05T15:25:07.000Z"}, {"author": "Justin Richer", "text": "@bumblefudge depends on your did method :P
", "time": "2025-11-05T15:25:24.000Z"}, {"author": "Eric Rescorla", "text": "Eli Mallon said:
\n\n\nif the concern is PDS scalability you could also have relays pull from other partial relays. there hasn't been a lot of need for that topology but it's totally possible (ask the bluesky team about the time their relay started ingesting itself!)
\n
Well, I think this gets to the question about scalability for whom. Because it's the PDS who is interested in reducing excessive relay subscriptions, but it's the other relay whose job is to use the first tier relay.
", "time": "2025-11-05T15:25:28.000Z"}, {"author": "Bumblefudge", "text": "@justin same as it ever was?
", "time": "2025-11-05T15:25:44.000Z"}, {"author": "Bumblefudge", "text": "each DID method is another chance at that \"insofar\"
", "time": "2025-11-05T15:25:56.000Z"}, {"author": "Richard Barnes", "text": "@ekr - PDS CDN
", "time": "2025-11-05T15:25:58.000Z"}, {"author": "Ryan Barrett", "text": "PDSes are expected to serve their firehose to relays. it's more the direct traffic from appviews, end user clients, etc that they try to avoid
", "time": "2025-11-05T15:26:29.000Z"}, {"author": "Eric Rescorla", "text": "Richard Barnes said:
\n\n\n@ekr - PDS CDN
\n
Finally a use for DHTs!
", "time": "2025-11-05T15:26:36.000Z"}, {"author": "Bumblefudge", "text": "^ Ahem
", "time": "2025-11-05T15:27:06.000Z"}, {"author": "Eric Rescorla", "text": "Ryan Barrett said:
\n\n\nPDSes are expected to serve their firehose to relays. it's more the direct traffic from appviews, end user clients, etc that they try to avoid
\n
Let's stipulate the first point, though I have concerns about that. What is it that they do to actually avoid that direct traffic
", "time": "2025-11-05T15:27:23.000Z"}, {"author": "Richard Barnes", "text": "expanding my point -- websites want to manage excessive connections, and they do that with CDNs
", "time": "2025-11-05T15:27:28.000Z"}, {"author": "Bumblefudge", "text": "ATProto uses DAG-CBOR, which is an IPFS serialization for data on DHTs
", "time": "2025-11-05T15:27:34.000Z"}, {"author": "Ted Hardie", "text": "@EKR You're an author of RFC 6940, just as a reminder
", "time": "2025-11-05T15:27:53.000Z"}, {"author": "Eric Rescorla", "text": "Richard Barnes said:
\n\n\nexpanding my point -- websites want to manage excessive connections, and they do that with CDNs
\n
But that's bad! The point is to avoid that. I shouldn't have to call Cloudflare because Taylor Swift retweets me
", "time": "2025-11-05T15:27:54.000Z"}, {"author": "Eric Rescorla", "text": "Ted Hardie said:
\n\n\n@EKR You're an author of RFC 6940, just as a reminder
\n
Don't remind me
", "time": "2025-11-05T15:28:13.000Z"}, {"author": "Eli Mallon", "text": "Getting retweeted doesn't increase traffic on your PDS though
", "time": "2025-11-05T15:28:22.000Z"}, {"author": "Richard Barnes", "text": "@ekr - Ryan's point is that the relay protects you from TSwift
", "time": "2025-11-05T15:28:27.000Z"}, {"author": "Ted Hardie", "text": "@ERK too late!
", "time": "2025-11-05T15:28:34.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Kathleen Moriarty said:
\n\n\nThe chart in the overview presentation provided a nice breakdown in response to Usama
\n
Maybe I missed that chart. Did you mean the busy slide 7 of first presentation? If not, could someone point me to which slide exactly?
", "time": "2025-11-05T15:28:38.000Z"}, {"author": "Eric Rescorla", "text": "Richard Barnes said:
\n\n\n@ekr - Ryan's point is that the relay protects you from TSwift
\n
I understand that's his point. I'm not persuaded it's true
", "time": "2025-11-05T15:29:01.000Z"}, {"author": "Martin Thomson", "text": "Richard Barnes said:
\n\n\n@ekr - Ryan's point is that the relay protects you from TSwift
\n
Does it protect you from swifties?
", "time": "2025-11-05T15:29:06.000Z"}, {"author": "Bailey", "text": "Big fan of tangled. I use it for the majority of my open source work now
", "time": "2025-11-05T15:29:13.000Z"}, {"author": "Nick Doty", "text": "(I got lost in the metaphors. what's a \"knot\"?)
", "time": "2025-11-05T15:29:18.000Z"}, {"author": "Bumblefudge", "text": "tangled's timing is great, github really getting the doctorow treatment this year
", "time": "2025-11-05T15:29:30.000Z"}, {"author": "Bailey", "text": "A knot holds your git repo
", "time": "2025-11-05T15:29:31.000Z"}, {"author": "Ted Hardie", "text": "Subscribing to multiple relays seems not to work in the current architecture, because there is no way to de-duplicate, but adding that should be possible. That would enable a slightly different set of scaling characteristics.
", "time": "2025-11-05T15:29:32.000Z"}, {"author": "Akshay Oppilippan", "text": "love to hear it @bailey!
", "time": "2025-11-05T15:29:36.000Z"}, {"author": "Bumblefudge", "text": "@Nick it's like a micro git hub
", "time": "2025-11-05T15:29:50.000Z"}, {"author": "Giulia Scarnecchia", "text": "Big fan of tangled too!
", "time": "2025-11-05T15:30:01.000Z"}, {"author": "Bumblefudge", "text": "attached to a did:plc
", "time": "2025-11-05T15:30:02.000Z"}, {"author": "Eli Mallon", "text": "@Ted You can de-dupe easily; drop duplicate records
", "time": "2025-11-05T15:30:05.000Z"}, {"author": "Akshay Oppilippan", "text": "\n\nNick Doty
\n
\n15:29
\n(I got lost in the metaphors. what's a \"knot\"?)
knots are selfhostable git servers, its where code is hosted.
", "time": "2025-11-05T15:30:07.000Z"}, {"author": "Ryan Barrett", "text": "right. You de-dupe across multiple relays at the repo level. repo structure (and their commits) are deterministic
", "time": "2025-11-05T15:30:19.000Z"}, {"author": "Kathleen Moriarty", "text": "@Usama they have building blocks that exist int he IETF already and they have all been talking about the repository and firehose being the parts they'd like to work on here. Those are typical for IETF work in that they are the data format (and the URI) as well as the protocol to transfer large amouns of data, AKA the firehose.
", "time": "2025-11-05T15:30:20.000Z"}, {"author": "Giulia Scarnecchia", "text": "Could we move the speaker camera to the speaker?
", "time": "2025-11-05T15:30:34.000Z"}, {"author": "Ryan Barrett", "text": "commits have CIDs that you can de-dupe on
", "time": "2025-11-05T15:30:40.000Z"}, {"author": "Eric Rescorla", "text": "Giulia Scarnecchia said:
\n\n\nCould we move the speaker camera to the speaker?
\n
Meetecho
", "time": "2025-11-05T15:30:43.000Z"}, {"author": "Giulia Scarnecchia", "text": "Thanks!
", "time": "2025-11-05T15:30:50.000Z"}, {"author": "Bailey", "text": "There he is
", "time": "2025-11-05T15:30:52.000Z"}, {"author": "Boris Mann", "text": "@Ted yes you can de-dupe because content is content addressable identifiers
", "time": "2025-11-05T15:31:07.000Z"}, {"author": "Martin Thomson", "text": "great to hear \"risky\", but not sure about that as a branding move
", "time": "2025-11-05T15:31:32.000Z"}, {"author": "Boris Mann", "text": "@Martin it is very intentional
", "time": "2025-11-05T15:32:11.000Z"}, {"author": "Ted Hardie", "text": "@ELI I believe that method only after receiving both, which is suboptimal. If that does work some other way, a poitner would be welcome.
", "time": "2025-11-05T15:32:18.000Z"}, {"author": "Martin Thomson", "text": "Boris Mann said:
\n\n\n@Martin it is very intentional
\n
Hence, \"not sure\"
", "time": "2025-11-05T15:32:27.000Z"}, {"author": "Kathleen Moriarty", "text": "@usama, relying on Identity, authentication, authorization and methods to provide security properties over defined data (e.g. JOSE, COSE) are some of the parts that exist already in the IETF
", "time": "2025-11-05T15:32:29.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Kathleen Moriarty said:
\n\n\n@Usama they have building blocks that exist int he IETF already and they have all been talking about the repository and firehose being the parts they'd like to work on here. Those are typical for IETF work in that they are the data format (and the URI) as well as the protocol to transfer large amouns of data, AKA the firehose.
\n
Thanks for clarification. Sure, I see you mean slide 13 in the first presentation. But it goes back to my first question, i.e., what is the exact connection of this to the one on busy slide 7?
", "time": "2025-11-05T15:32:59.000Z"}, {"author": "Bumblefudge", "text": "if there's one thing i would never question rudy on, it's branding
", "time": "2025-11-05T15:33:00.000Z"}, {"author": "Boris Mann", "text": "Risky - it's risky to support marginal populations by sending messages that administrations don't want to see spread
", "time": "2025-11-05T15:33:03.000Z"}, {"author": "Eli Mallon", "text": "the de-duping is important. One way Streamplace scales is that we don't index every atproto user by default; we ignore identities from the relay that haven't interacted with Streamplace in some way. When a user does so for the first time, we start subscribing to their actions and backfill from the PDS incrementally. CIDs and de-duplication are how we avoid double-ingesting in that context
", "time": "2025-11-05T15:33:59.000Z"}, {"author": "Nick Doty", "text": "the different relay seems like more of a question for user decision-making about moderation policies, rather than the PDS.
", "time": "2025-11-05T15:34:15.000Z"}, {"author": "Kathleen Moriarty", "text": "De-duplication could run into patents in the storage space depending on how it is done.
", "time": "2025-11-05T15:34:44.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Kathleen Moriarty said:
\n\n\n@usama, relying on Identity, authentication, authorization and methods to provide security properties over defined data (e.g. JOSE, COSE) are some of the parts that exist already in the IETF
\n
Should we blend attestation in it? :smile:
", "time": "2025-11-05T15:34:50.000Z"}, {"author": "Bumblefudge", "text": "well if they know rust forking blacksky is easier than forking bluesky haha
", "time": "2025-11-05T15:34:53.000Z"}, {"author": "Kathleen Moriarty", "text": "@Usama, let's wait on adding attestation... they need to work through core building blocks first
", "time": "2025-11-05T15:35:41.000Z"}, {"author": "Phil Schleihauf", "text": "sorry to resurrect the PDS CDNs point but: you can serve redirects from your PDS to another service that can handle more traffic, or you could delegate your PDS endpoint entirely to a CDN-like service that your PDS lives behind. (you might even imagine that service offering a push interface to the PDS side)
\nit can look a lot like hosting a website
", "time": "2025-11-05T15:36:13.000Z"}, {"author": "Boris Mann", "text": "There are attestation approaches today, but for app specific use cases
", "time": "2025-11-05T15:36:24.000Z"}, {"author": "Bumblefudge", "text": "https://ngerakines.leaflet.pub/3m3idxul5hc2r
\n^ One attestation approach from the community
re attestation: atproto PDSses will provide a merkle inclusion/exclusion proof for a particular record on-demand. so if you need a longer-lived proof of a particular \"atproto fact\", you can serialize that theoretically
", "time": "2025-11-05T15:37:07.000Z"}, {"author": "Eli Mallon", "text": "now, there's a norm that you can delete data in atproto. so archiving such a proof might be _rude_. but you can do it
", "time": "2025-11-05T15:37:25.000Z"}, {"author": "Bumblefudge", "text": "^ network covenant wen
", "time": "2025-11-05T15:37:50.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Eli Mallon said:
\n\n\nre attestation: atproto PDSses will provide a merkle inclusion/exclusion proof for a particular record on-demand. so if you need a longer-lived proof of a particular \"atproto fact\", you can serialize that theoretically
\n
What protocol will convey this proof?
", "time": "2025-11-05T15:38:32.000Z"}, {"author": "Ryan Barrett", "text": "firehose + DIDs
", "time": "2025-11-05T15:39:13.000Z"}, {"author": "Justin Richer", "text": "did:firehose
", "time": "2025-11-05T15:39:20.000Z"}, {"author": "Eli Mallon", "text": "@Muhammad It's the same mechanism that relays use to proof repository diffs (you can just generate one for arbitrary records if you want to)
", "time": "2025-11-05T15:39:27.000Z"}, {"author": "Boris Mann", "text": "There is an endpoint on the PDS where this is fetched from, with account + repo
", "time": "2025-11-05T15:39:31.000Z"}, {"author": "Ryan Barrett", "text": "and also getRecord, etc that the PDS serves
", "time": "2025-11-05T15:39:35.000Z"}, {"author": "Ryan Barrett", "text": "proofs (signatures) are bundled with data, hence \"self authenticating\"
", "time": "2025-11-05T15:39:45.000Z"}, {"author": "Bumblefudge", "text": "well until there are multiple firehoses that index different sets of dids, did:firehose is actually a better name than did:plc
", "time": "2025-11-05T15:39:47.000Z"}, {"author": "Bumblefudge", "text": "@justin
", "time": "2025-11-05T15:39:56.000Z"}, {"author": "Martin Thomson", "text": "Do we have anyone familiar enough with MOQ to ask why this doesn't use MOQ?
", "time": "2025-11-05T15:39:57.000Z"}, {"author": "Ted Hardie", "text": "It predates MoQ moving from being media only.
", "time": "2025-11-05T15:40:15.000Z"}, {"author": "Martin Thomson", "text": "@Ted Hardie I don't see how that is relevant.
", "time": "2025-11-05T15:40:33.000Z"}, {"author": "Ted Hardie", "text": "But I would use MoQ's pub/sub interactions with relays as a model, personally.
", "time": "2025-11-05T15:40:41.000Z"}, {"author": "Nick Doty", "text": "discovering and talking to relays/aggregation services seems significant ... but also doesn't seem that connected to the particular PDS structure. could we standardize how to communicate with relays without the merkle tree stuff?
", "time": "2025-11-05T15:40:50.000Z"}, {"author": "Ryan Barrett", "text": "Nick: maybe yes! that's https://atproto.com/specs/event-stream
", "time": "2025-11-05T15:41:11.000Z"}, {"author": "Ted Hardie", "text": "@Martin I guess my reply is a standardized version might, but it's understandable why the current version does not.
", "time": "2025-11-05T15:41:14.000Z"}, {"author": "Martin Thomson", "text": "Yes, I'm asking a loaded question, so that is fair.
", "time": "2025-11-05T15:41:44.000Z"}, {"author": "Bumblefudge", "text": "not sure i understand what \"without the merkle tree stuff\" means here tbh
", "time": "2025-11-05T15:41:46.000Z"}, {"author": "Ryan Barrett", "text": "but relays are only really intended to aggregate firehoses, they don't do anything else
", "time": "2025-11-05T15:41:49.000Z"}, {"author": "Eli Mallon", "text": "Yeah \"without the merkle tree stuff\" sounds like \"without atproto\" to me
", "time": "2025-11-05T15:42:02.000Z"}, {"author": "Neema Brown", "text": "yeah, like the proof mechanism is tied in with everything else
", "time": "2025-11-05T15:42:23.000Z"}, {"author": "Ryan Barrett", "text": "labelers and subscribeLabels are an example of using event streams outside of firehoses and relays
", "time": "2025-11-05T15:42:24.000Z"}, {"author": "Nick Doty", "text": "@eli I'm literally still trying to understand what atproto is
", "time": "2025-11-05T15:42:27.000Z"}, {"author": "Chad Kohalyk", "text": "@Meetecho Robot Shall we move the speaker camera back to the moderators?
", "time": "2025-11-05T15:42:30.000Z"}, {"author": "Chad Kohalyk", "text": "Cheers!
", "time": "2025-11-05T15:42:59.000Z"}, {"author": "Bumblefudge", "text": "i'm all for a broader scope (i keep lobbying that the at:// URI scheme and identity system be at least descriptively in scope as invariants), but currently the entire economy of scale assumes that merkle-tree stuff and opinionated goofy serialization
", "time": "2025-11-05T15:43:27.000Z"}, {"author": "Boris Mann", "text": "@nick authenticated data with identities and content addressing and signing keys
", "time": "2025-11-05T15:43:30.000Z"}, {"author": "Eli Mallon", "text": "@Nick totally fair! IMO the repository structure and the signed distribution of repository diffs as merkle proofs are the most core part of the protocol (and roughly are the two things they're trying to standardize here)
", "time": "2025-11-05T15:43:45.000Z"}, {"author": "Bumblefudge", "text": "+1 eric, open question which invariants can be assumed by the scope
", "time": "2025-11-05T15:44:31.000Z"}, {"author": "Nick Doty", "text": "transferring signed data into relays to speed up communication seems potentially useful entirely separate from the PDS repo structure
", "time": "2025-11-05T15:44:32.000Z"}, {"author": "Bumblefudge", "text": "particularly the turkish border
", "time": "2025-11-05T15:45:12.000Z"}, {"author": "Bumblefudge", "text": "@Nick i agree that decoupling the sync and PDS data model+APIs+identity system + URI scheme
", "time": "2025-11-05T15:46:05.000Z"}, {"author": "Evan Prodromou", "text": "What happens if a WG is not formed?
", "time": "2025-11-05T15:46:21.000Z"}, {"author": "Bumblefudge", "text": "is useful, whether both come to IETF or neither
", "time": "2025-11-05T15:46:21.000Z"}, {"author": "Bumblefudge", "text": "or just 1
", "time": "2025-11-05T15:46:35.000Z"}, {"author": "Eric Rescorla", "text": "Evan Prodromou said:
\n\n\nWhat happens if a WG is not formed?
\n
You mean ever? Because it wont be formed today no matter what
", "time": "2025-11-05T15:46:51.000Z"}, {"author": "Nick Doty", "text": "+1 hardie (examples of a useful structure but maybe not interoperating)
", "time": "2025-11-05T15:47:10.000Z"}, {"author": "Boris Mann", "text": "@Evan we'll coordinate as a community - there's lots of things outside of this that are in flight
", "time": "2025-11-05T15:47:12.000Z"}, {"author": "Evan Prodromou", "text": "It seems like an open question
", "time": "2025-11-05T15:47:14.000Z"}, {"author": "Ryan Barrett", "text": "nick you may be interested in https://atproto.com/articles/atproto-ethos and https://bsky.social/about/bluesky-and-the-at-protocol-usable-decentralized-social-media-martin-kleppmann.pdf
", "time": "2025-11-05T15:47:15.000Z"}, {"author": "Evan Prodromou", "text": "@Boris that's one option; another is going with another standards org or forming a new one
", "time": "2025-11-05T15:47:52.000Z"}, {"author": "Bumblefudge", "text": "kleppmann's presentation to DINRG 5 or 6 IETFs ago was also relevant
", "time": "2025-11-05T15:47:54.000Z"}, {"author": "Bumblefudge", "text": "to explaining the design approach
", "time": "2025-11-05T15:48:03.000Z"}, {"author": "Eli Mallon", "text": "Identity can be decoupled from atproto repos in some ways sure. I'm not sure repos can be decoupled from sync, insofar as the sync protocol is a stream of merkle tree diffs
", "time": "2025-11-05T15:48:14.000Z"}, {"author": "Boris Mann", "text": "@Evan yep, lots of different options
", "time": "2025-11-05T15:48:19.000Z"}, {"author": "Justin Richer", "text": "boiling the whole lego enchilada
", "time": "2025-11-05T15:48:31.000Z"}, {"author": "Boris Mann", "text": "I personally would not want to form a new one from scratch
", "time": "2025-11-05T15:48:32.000Z"}, {"author": "Evan Prodromou", "text": "Yeah, it's a mess
", "time": "2025-11-05T15:48:39.000Z"}, {"author": "Bumblefudge", "text": "not a fan
", "time": "2025-11-05T15:48:43.000Z"}, {"author": "Eric Rescorla", "text": "Evan Prodromou said:
\n\n\n@Boris that's one option; another is going with another standards org or forming a new one
\n
ETSI
", "time": "2025-11-05T15:48:45.000Z"}, {"author": "Bumblefudge", "text": ":skull:
", "time": "2025-11-05T15:48:59.000Z"}, {"author": "Ryan Barrett", "text": "Eli maybe not sync specifically, but https://atproto.com/specs/event-stream is kind of pubsub more generally, so we do have one existing abstraction
", "time": "2025-11-05T15:49:22.000Z"}, {"author": "Gregory Scallan", "text": "2 examples where surf uses AT and interopates with other AT uses:
\n1) graze feeds can be included as source feeds for surf custom feeds
\n2) leaflet posts in your interest can be interacted with in surf.
", "time": "2025-11-05T15:49:24.000Z"}, {"author": "Evan Prodromou", "text": "So, is the next step to have another BOF that is WG-forming?
", "time": "2025-11-05T15:49:44.000Z"}, {"author": "Boris Mann", "text": "The community has rally'd in person in the room, coming to Montreal, and also online
", "time": "2025-11-05T15:49:45.000Z"}, {"author": "Bumblefudge", "text": "+1 more informational i-ds along the path to wg/no-go decision
", "time": "2025-11-05T15:49:47.000Z"}, {"author": "Boris Mann", "text": "Definitely willing to engage
", "time": "2025-11-05T15:49:51.000Z"}, {"author": "Eric Rescorla", "text": "Evan Prodromou said:
\n\n\nSo, is the next step to have another BOF that is WG-forming?
\n
I wouldn't be shocked if it got formed without a BOF
", "time": "2025-11-05T15:50:04.000Z"}, {"author": "Boris Mann", "text": "We have a diverse community that skews younger and skews unfamiliar with the IETF
", "time": "2025-11-05T15:50:06.000Z"}, {"author": "Ted Hardie", "text": "Agree that having the architecture in draft form is useful, and IS would be a fine result if the ISE is willing.
", "time": "2025-11-05T15:50:06.000Z"}, {"author": "Daniel Holmgren", "text": "The architecture draft is \"informational\" and is just meant to communicate the context that the repo & sync protocol is used in today
", "time": "2025-11-05T15:50:14.000Z"}, {"author": "Eric Rescorla", "text": "Daniel Holmgren said:
\n\n\nThe architecture draft is \"informational\" and is just meant to communicate the context that the repo & sync protocol is used in today
\n
I found it helpful. I think it would actually be good to have one for some time
", "time": "2025-11-05T15:50:34.000Z"}, {"author": "Justin Richer", "text": "@Evan - that's part of the question for next steps that we'd like to see here. if the community can hash out a charter on list it could be formed before 125
", "time": "2025-11-05T15:50:39.000Z"}, {"author": "Evan Prodromou", "text": "Thanks. It feels like the discussion is a little ambivalent right now.
", "time": "2025-11-05T15:51:11.000Z"}, {"author": "Justin Richer", "text": "the quesiton right now is \"is this right for IETF\" and \"if so what do we do next\" is ... next
", "time": "2025-11-05T15:51:44.000Z"}, {"author": "Nick Doty", "text": "@ryan that ethos doc worries me because it sounds like they aren't designing something that's useful to people who disagree, only people who like the same kind of peer-to-peer tech
", "time": "2025-11-05T15:51:57.000Z"}, {"author": "Bumblefudge", "text": ":smiling_face_with_hearts:
", "time": "2025-11-05T15:52:07.000Z"}, {"author": "Nick Doty", "text": "good chairing!
", "time": "2025-11-05T15:52:19.000Z"}, {"author": "Bumblefudge", "text": "+1 to the chair wearing the bluesky shirt
", "time": "2025-11-05T15:52:26.000Z"}, {"author": "Chad Kohalyk", "text": ":clap::clap::clap:
", "time": "2025-11-05T15:52:27.000Z"}, {"author": "Lixia Zhang", "text": "I feel a lack of understanding on how one could decouple a protocol's security design from its identifier choices
", "time": "2025-11-05T15:52:39.000Z"}, {"author": "Kathleen Moriarty", "text": "Things to share at the mic to Richard's point is directional and support/lack of support - guidance for a good outcome.
", "time": "2025-11-05T15:52:40.000Z"}, {"author": "Eric Rescorla", "text": "Gemini has produced a charter for you:
\nWorking Group Name: Authenticated Transfer Protocol
\nWorking Group Acronym: ATP
\nArea: Applications and Real-Time (ART)
\nChairs: TBD
\nMailing List: atp@ietf.org
\nTo Subscribe: https://www.google.com/search?q=https://www.ietf.org/mailman/listinfo/atp
\nMeeting Materials: https://www.google.com/search?q=https://datatracker.ietf.org/wg/atp/meetings/
\nThe Authenticated Transfer (ATP) Working Group is chartered to standardize the AT Protocol, a protocol for decentralized social networking and general-purpose federated data transfer. The protocol is designed to be open, interoperable, and composable, enabling a \"federation of services\" model.
\nThe core components of the AT Protocol include:
\nA federated network architecture: This involves Personal Data Servers (PDS), Relays (for large-scale data aggregation), and Application View services (for indexing and presenting data).
\nA data model: This includes user data repositories (\"repos\") structured as signed Merkle trees, and a schema system called \"Lexicons\" for defining data types.
\nAn identity system: This uses Decentralized Identifiers (DIDs), specifically did:plc, for persistent, cryptographic user identity.
An interoperability framework: This uses a remote procedure call (RPC) system called XRPC for communication between servers and clients.
\nThis working group will focus on producing RFCs that specify these core components to ensure interoperability between independent implementations.
\nThe modern social web is dominated by a small number of large, centralized platforms. This architecture creates challenges related to data portability, user-controlled identity, and innovation. A decentralized, federated approach can address these issues by separating the concerns of identity, data hosting, and application-layer services.
\nWhile the AT Protocol exists as a public specification and several implementations, it has not yet undergone a formal, multi-stakeholder standardization process. Standardization through the IETF will:
\nClarify ambiguous parts of the specification.
\nEnsure the protocol meets IETF-grade requirements for security, privacy, and scalability.
\nPromote wider adoption and interoperability among diverse implementations.
\nProvide a stable, long-term foundation for a new generation of federated services.
\nThe working group will take the existing AT Protocol specifications as its starting point and work to refine them into a set of proposed standards.
\nThe ATP Working Group will focus on standardizing the core protocol.
\nIn Scope:
Core Architecture: An informational RFC describing the overall architecture, the roles of PDS, Relay, and App View services, and the flow of data between them.
\nIdentity: A standards-track RFC specifying the use of DIDs (e.g., did:plc) as the persistent identity layer, including key rotation and account recovery mechanisms.
Data Model: A standards-track RFC for the user data repository structure, including the signed Merkle tree (prologue tree) format, and the \"Lexicon\" schema system for defining data types.
\nTransport (XRPC): A standards-track RFC defining the XRPC protocol, including its JSON-based serialization, HTTP bindings, and error handling.
\nFederation: A standards-track RFC detailing the server-to-server federation protocols, including data synchronization, event streams, and authentication between services.
\nOut of Scope:
\nStandardization of specific \"Lexicons\" (e.g., schemas for social posts, likes, or follows). The WG will standardize the framework for defining schemas, but not the schemas themselves.
\nClient-to-server or client-to-client protocols, beyond what is defined in XRPC.
\nSpecific application-level policies (e.g., content moderation policies).
\nThe did:plc method itself, which is out of scope for the IETF. The WG will focus on how DIDs are used by ATP.
The WG will produce the following documents:
\nMilestone 1: An informational RFC describing the overall AT Protocol architecture.
\nMilestone 2: A Proposed Standard RFC for the AT Protocol Data Model (Repositories and Lexicons).
\nMilestone 3: A Proposed Standard RFC specifying the use of DIDs within the AT Protocol.
\nMilestone 4: A Proposed Standard RFC for the XRPC transport protocol.
\nMilestone 5: A Proposed Standard RFC for server-to-server federation.
\nDependencies:
\nLiaisons:
\nW3C Decentralized Identifier WG: The WG will liaise with the W3C DID WG regarding the use and evolution of the DID standards.
\nW3C Social Web WG (if active): The WG will maintain communication to ensure compatibility or alignment with other social web standards, such as ActivityPub, where appropriate.
\nThe protocol's design has significant security and privacy implications. The WG will be responsible for:
\nRigorously documenting the security and privacy properties of the architecture in all specification documents.
\nAnalyzing and mitigating risks related to identity spoofing, data tampering, denial of service in a federated environment, and user data privacy.
\nEnsuring mechanisms for user-controlled data visibility and account security (e.g., key rotation) are robust and well-specified.
\nThe IETF's standard Note Well (RFC 3978, RFC 8179) applies. The WG will follow the IETF's IPR policies. The working group will seek to clarify the IPR status of the initial specifications submitted as input, with the goal of ensuring all standardized components can be implemented under the IETF's royalty-free terms.
", "time": "2025-11-05T15:53:11.000Z"}, {"author": "Lixia Zhang", "text": "and it is this identifier space question that people seem to dance around
", "time": "2025-11-05T15:53:11.000Z"}, {"author": "Justin Richer", "text": "ekr stop
", "time": "2025-11-05T15:53:40.000Z"}, {"author": "Justin Richer", "text": ":P
", "time": "2025-11-05T15:53:55.000Z"}, {"author": "Eric Rescorla", "text": "Justin Richer said:
\n\n\nekr stop
\n
Can't stop, won't stop.
", "time": "2025-11-05T15:54:09.000Z"}, {"author": "No\u00e9 Busson", "text": "Would did:plc be part of this eventual IETF working group? From what I've understood that's not planned now
", "time": "2025-11-05T15:54:24.000Z"}, {"author": "Bumblefudge", "text": "+1 Lixia, another i-d on all the stuff people were confused about here. happy to contribute personally since i am still confused about some of those choices after all these years :sweat_smile:
", "time": "2025-11-05T15:54:39.000Z"}, {"author": "Eric Rescorla", "text": "No\u00e9 Busson said:
\n\n\nWould did:plc be part of this eventual IETF working group? From what I've understood that's not planned now
\n
That's open for discussion.
", "time": "2025-11-05T15:54:40.000Z"}, {"author": "Martin Thomson", "text": "I can't see plc being in scope
", "time": "2025-11-05T15:54:40.000Z"}, {"author": "Martin Thomson", "text": "replacing it might be
", "time": "2025-11-05T15:54:51.000Z"}, {"author": "Bumblefudge", "text": "well it's called placeholder
", "time": "2025-11-05T15:55:01.000Z"}, {"author": "Eric Rescorla", "text": "Martin Thomson said:
\n\n\nreplacing it might be
\n
Ah yes, that aligns with my view
", "time": "2025-11-05T15:55:05.000Z"}, {"author": "No\u00e9 Busson", "text": "Okay, I understood that would something that eventually comes after.
", "time": "2025-11-05T15:55:10.000Z"}, {"author": "Bumblefudge", "text": "i would have called it ugly baby
", "time": "2025-11-05T15:55:12.000Z"}, {"author": "Bumblefudge", "text": "did:uglybaby
", "time": "2025-11-05T15:55:25.000Z"}, {"author": "Ryan Barrett", "text": "\"symmetry challenged\"
", "time": "2025-11-05T15:55:27.000Z"}, {"author": "Aaron Parecki", "text": "Bumblefudge said:
\n\n\nwell it's called placeholder
\n
it's not called placeholder anymore :eyes:
", "time": "2025-11-05T15:55:28.000Z"}, {"author": "Nick Doty", "text": "I thought \"plc\" stood for permanent centralized ledger?
", "time": "2025-11-05T15:55:36.000Z"}, {"author": "Neema Brown", "text": "it does now
", "time": "2025-11-05T15:55:44.000Z"}, {"author": "Jeremie Miller", "text": "Bumblefudge said:
\n\n\ndid:uglybaby
\n
redundant
", "time": "2025-11-05T15:55:58.000Z"}, {"author": "Aaron Parecki", "text": "\"PLC stands for 'Public Ledger of Credentials'\" https://web.plc.directory/
", "time": "2025-11-05T15:56:06.000Z"}, {"author": "Bumblefudge", "text": "PLC stands for \"if there's only one registry it's not a DID method\"
", "time": "2025-11-05T15:56:22.000Z"}, {"author": "Martin Thomson", "text": "Aaron Parecki said:
\n\n\n\"PLC stands for 'Public Ledger of Credentials'\" https://web.plc.directory/
\n
Keep telling yourself that Aaron
", "time": "2025-11-05T15:56:30.000Z"}, {"author": "Murray Kucherawy", "text": "People Love to Complain
", "time": "2025-11-05T15:56:56.000Z"}, {"author": "Bumblefudge", "text": "^ i feel seen
", "time": "2025-11-05T15:57:07.000Z"}, {"author": "No\u00e9 Busson", "text": "I'm still concerned about the ambiguity of did:plc: why is the directory not included within the DID itself?
", "time": "2025-11-05T15:57:18.000Z"}, {"author": "Lixia Zhang", "text": "back that many years, we would not have polled off this interconnected world without first nailing down the IP address space. Now we are talking communications at higher layers, how wer could communicate securily without a clear understanding of how the identifier space(s) may look like
", "time": "2025-11-05T15:57:21.000Z"}, {"author": "Bumblefudge", "text": "+1 to Ryan, bryan is a team player and good community manager
", "time": "2025-11-05T15:57:24.000Z"}, {"author": "No\u00e9 Busson", "text": "See: https://github.com/did-method-plc/did-method-plc/issues/76
", "time": "2025-11-05T15:57:30.000Z"}, {"author": "Boris Mann", "text": ":raised_hands:
", "time": "2025-11-05T15:58:21.000Z"}, {"author": "Eric Rescorla", "text": "No\u00e9 Busson said:
\n\n\nSee: https://github.com/did-method-plc/did-method-plc/issues/76
\n
Right, I think the question here is whether some kind of log-structured DID is useful here and if so, how should it be built
", "time": "2025-11-05T15:58:21.000Z"}, {"author": "Ryan Barrett", "text": "https://lexicon.community/ , a baby standards body for community-owned lexicons (ATProto schemas)
", "time": "2025-11-05T15:58:56.000Z"}, {"author": "Dan York", "text": "For the notes, what was the name of the speaker who just rose and talked about live video streaming?
", "time": "2025-11-05T15:59:01.000Z"}, {"author": "Boris Mann", "text": "Eli Mallon
", "time": "2025-11-05T15:59:08.000Z"}, {"author": "Eli Mallon", "text": "@Dan York That's me!
", "time": "2025-11-05T15:59:11.000Z"}, {"author": "Dan York", "text": "Thanks!
", "time": "2025-11-05T15:59:16.000Z"}, {"author": "Boris Mann", "text": "Streamplace https://stream.place
", "time": "2025-11-05T15:59:21.000Z"}, {"author": "Jim Fenton", "text": "We need to have \"AT protocol office hours\" somewhere to find these people for all the follow-up discussions
", "time": "2025-11-05T15:59:27.000Z"}, {"author": "Murray Kucherawy", "text": "Did he say it's going to be a lot of fun working here?
", "time": "2025-11-05T15:59:33.000Z"}, {"author": "Rich Salz", "text": "for some definition of \"fun\"
", "time": "2025-11-05T15:59:51.000Z"}, {"author": "Ryan Barrett", "text": "Jim: Boris and https://atprotocol.dev/ can probably help
", "time": "2025-11-05T15:59:52.000Z"}, {"author": "Bumblefudge", "text": "yeah there are community calls and stuff
", "time": "2025-11-05T16:00:17.000Z"}, {"author": "Kathleen Moriarty", "text": "@Murray - we all come back for a reason :-)
", "time": "2025-11-05T16:00:18.000Z"}, {"author": "Boris Mann", "text": "Also forum https://discourse.atprotocol.community
", "time": "2025-11-05T16:00:22.000Z"}, {"author": "Ryan Barrett", "text": "also https://discord.gg/3srmDsHSZJ
", "time": "2025-11-05T16:00:23.000Z"}, {"author": "Bumblefudge", "text": "@martin remind me to send you links about that \"plug-in network intelligence\" idea, there is some work on that
", "time": "2025-11-05T16:02:40.000Z"}, {"author": "Bumblefudge", "text": "", "time": "2025-11-05T16:02:59.000Z"}, {"author": "Bumblefudge", "text": "+1 mirja, with right scope it's a great place to make the protocol governance more transparent and fair
", "time": "2025-11-05T16:04:33.000Z"}, {"author": "Muhammad Usama Sardar", "text": "@chairs: are we already into scoping discussion now?
", "time": "2025-11-05T16:04:39.000Z"}, {"author": "Eric Rescorla", "text": "My put for the scope is this: \"Specify enough to build an Internet scale multi-provider globally consistent content network that interoperates with existing deployed systems such as BlueSky but without the application semantics\"
", "time": "2025-11-05T16:04:43.000Z"}, {"author": "Martin Thomson", "text": "That sounds like a good scope. Unfortunately, that means pulling in a lot more of the lower layers of Bryan's picture.
", "time": "2025-11-05T16:05:22.000Z"}, {"author": "Ryan Barrett", "text": "that would be...a lot. like, eight of the boxes would be green, instead of two
", "time": "2025-11-05T16:05:30.000Z"}, {"author": "Bumblefudge", "text": "instead of red yellow green for in/maybe/out, maybe there should be a color for
", "time": "2025-11-05T16:05:51.000Z"}, {"author": "Ted Hardie", "text": "To remind folks of my comments, I want the eventual charter to be clear about what kind of interoperability we are targeting. \"Common building block\" vs. \"systems that talk to each other\" gives a different set of requirements.
", "time": "2025-11-05T16:05:58.000Z"}, {"author": "Bumblefudge", "text": "\"descriptive/declaration of invairants\"?
", "time": "2025-11-05T16:06:00.000Z"}, {"author": "Martin Thomson", "text": "Ryan Barrett said:
\n\n\nthat would be...a lot. like, eight of the boxes would be green, instead of two
\n
I don't think that many of those are particularly hard. Especially the grey ones.
", "time": "2025-11-05T16:06:00.000Z"}, {"author": "Evan Prodromou", "text": "Is there another wg that could take on the work?
", "time": "2025-11-05T16:06:22.000Z"}, {"author": "Richard Barnes", "text": "i think the grey ones were supposed to be things that are already specified
", "time": "2025-11-05T16:06:24.000Z"}, {"author": "Richard Barnes", "text": "@Evan - don't think so
", "time": "2025-11-05T16:06:33.000Z"}, {"author": "Orie Steele", "text": "@evan I don't think so.
", "time": "2025-11-05T16:06:35.000Z"}, {"author": "Martin Thomson", "text": "Richard Barnes said:
\n\n\ni think the grey ones were supposed to be things that are already specified
\n
exactly my point
", "time": "2025-11-05T16:06:40.000Z"}, {"author": "Eli Mallon", "text": "\"globally consistent\" is loaded; pretty much all the actors in the system can decline to sync certain repos/users for a variety of reasons. Definitely not like global version of the \"state\" that's true
", "time": "2025-11-05T16:06:51.000Z"}, {"author": "Ted Hardie", "text": "@Chairs can you put up the slide with the colored boxes (I believe it was slide 13 of Bryan's slides).
", "time": "2025-11-05T16:06:53.000Z"}, {"author": "Orie Steele", "text": "+1 Ted
", "time": "2025-11-05T16:07:01.000Z"}, {"author": "Eric Rescorla", "text": "Orie Steele said:
\n\n\n@evan I don't think so.
\n
webbotaith
", "time": "2025-11-05T16:07:02.000Z"}, {"author": "Bryan Newbold", "text": "Phil is at the mike but is not in the queue (I believe)
", "time": "2025-11-05T16:07:21.000Z"}, {"author": "Orie Steele", "text": "XD ... I can't speak for WIT ADs
", "time": "2025-11-05T16:07:34.000Z"}, {"author": "Bumblefudge", "text": "eric: i wasn't familiar with your game
", "time": "2025-11-05T16:07:41.000Z"}, {"author": "Ted Hardie", "text": "@Chairs thanks!
", "time": "2025-11-05T16:07:51.000Z"}, {"author": "Richard Barnes", "text": ":call_me:
", "time": "2025-11-05T16:07:57.000Z"}, {"author": "Eric Rescorla", "text": "Bumblefudge said:
\n\n\neric: i wasn't familiar with your game
\n
its a long game
", "time": "2025-11-05T16:08:11.000Z"}, {"author": "Lixia Zhang", "text": "the first requirement for \"globally consistent\" is a clearly defined identiifier space -- is that DID, or sometning else
", "time": "2025-11-05T16:08:16.000Z"}, {"author": "Bumblefudge", "text": "@Evan the OAuth profile is already indirectly happening in the OAuth WG via Aaron's RFCs that bluesky rely on
", "time": "2025-11-05T16:08:17.000Z"}, {"author": "Bumblefudge", "text": "i think a descriptive i-d painting the whole picture (or even just existing oauth profile docs) might be enough to link to
", "time": "2025-11-05T16:08:39.000Z"}, {"author": "Evan Prodromou", "text": "Thanks, I was talking about AT
", "time": "2025-11-05T16:08:44.000Z"}, {"author": "Bumblefudge", "text": "ah ok
", "time": "2025-11-05T16:08:49.000Z"}, {"author": "Ted Hardie", "text": "@lixia. DID is a set of identifiers. DID:plc is the current commonly used one, but it less distributed than the DID part of its name might imply.
", "time": "2025-11-05T16:09:13.000Z"}, {"author": "Ted Hardie", "text": "@Lixia, I think there is work to change that, but I am not sure whether that work is or is not in scope yet.
", "time": "2025-11-05T16:10:00.000Z"}, {"author": "Martin Thomson", "text": "Bryan's summary seems clear. I think that means that you need all the lower yellow boxes other than labeling.
", "time": "2025-11-05T16:10:03.000Z"}, {"author": "Aaron Parecki", "text": "this question keeps coming up about OAuth tho, since bluesky has a specific profile of OAuth that references a bunch of docs in a unique way. right now this OAuth profile only exists as ATProto docs. Should that profile be captured as an OAuth WG item or ATP item?
", "time": "2025-11-05T16:10:06.000Z"}, {"author": "Lixia Zhang", "text": "there is a question of which one in the set is the one that controls security
", "time": "2025-11-05T16:10:08.000Z"}, {"author": "Bumblefudge", "text": "my point is that just because they described their identity system in terms of a novel DID method doesn't mean the w3c DID method's scope includes engineering their identity requirements?
", "time": "2025-11-05T16:10:09.000Z"}, {"author": "Ryan Barrett", "text": "Martin: not OAuth or handles, and I'd argue not at:// URI
", "time": "2025-11-05T16:10:26.000Z"}, {"author": "Ryan Barrett", "text": "(but don't feel strongly)
", "time": "2025-11-05T16:10:37.000Z"}, {"author": "Lixia Zhang", "text": "To Ted: one cannot say did:plc is the identifiers but it depends on did:url to work
", "time": "2025-11-05T16:10:55.000Z"}, {"author": "Eli Mallon", "text": "Specifying the repo with collections and rkeys but not the full at:// URI is curious to me
", "time": "2025-11-05T16:11:11.000Z"}, {"author": "Nick Doty", "text": "ekr didn't say syncing repositories, and bryan did
", "time": "2025-11-05T16:11:12.000Z"}, {"author": "Martin Thomson", "text": "Ryan Barrett said:
\n\n\nMartin: not OAuth or handles, and I'd argue not at:// URI
\n
It depends on what you include. I think that you can have lightweight hooks that would be filled by oauth, but not a full integration.
", "time": "2025-11-05T16:11:13.000Z"}, {"author": "Bumblefudge", "text": "at:// URI is crucial imho. i don't necessarily think it needs to be changed or extended but the system doesn't make sense without it, it encodes the requirements for the DID method(s)
", "time": "2025-11-05T16:11:17.000Z"}, {"author": "Dan York", "text": "@eric Rescorla - Could you post that text in here that you said? So I could add it to the notes.
", "time": "2025-11-05T16:11:33.000Z"}, {"author": "Martin Thomson", "text": "The URI is a trivial thing to add. Even if it is a thicket of bike sheds.
", "time": "2025-11-05T16:11:34.000Z"}, {"author": "Eric Rescorla", "text": "Specify enough to build an Internet scale multi-provider globally consistent authenticated content network that interoperates with existing deployed systems such as BlueSky but without the application semantics
", "time": "2025-11-05T16:11:56.000Z"}, {"author": "Ryan Barrett", "text": "yeah the ugly bit about at:// URIs is that to make them valid URIs, you have to percent-encode the DID part, which is awkward
", "time": "2025-11-05T16:11:59.000Z"}, {"author": "Ted Hardie", "text": "The URI should reflect the protocol mechanisms, not drive them.
", "time": "2025-11-05T16:12:12.000Z"}, {"author": "Lixia Zhang", "text": "having did:plc depend on did:url introduces circular dependency (what secures the did:url)
", "time": "2025-11-05T16:12:21.000Z"}, {"author": "Eric Rescorla", "text": "Nick Doty said:
\n\n\nekr didn't say syncing repositories, and bryan did
\n
I think we're saying consistent stuff. It's just that he's thinking about it in the current design and I'm talking about what it does
", "time": "2025-11-05T16:12:22.000Z"}, {"author": "Martin Thomson", "text": "Ryan Barrett said:
\n\n\nyeah the ugly bit about at:// URIs is that to make them valid URIs, you have to percent-encode the DID part, which is awkward
\n
exactly the sort of ugliness that the IETF loves to waste time on
", "time": "2025-11-05T16:12:23.000Z"}, {"author": "Eli Mallon", "text": "Ryan Barrett said:
\n\n\nyeah the ugly bit about at:// URIs is that to make them valid URIs, you have to percent-encode the DID part, which is awkward
\n
Is this the reason it's yellow up there right now?
", "time": "2025-11-05T16:12:39.000Z"}, {"author": "Ryan Barrett", "text": "Eli: nah I doubt that
", "time": "2025-11-05T16:12:48.000Z"}, {"author": "Ryan Barrett", "text": "https://github.com/bluesky-social/atproto-website/pull/440
", "time": "2025-11-05T16:12:50.000Z"}, {"author": "Boris Mann", "text": "I'm going to Berlin in 2 weeks
", "time": "2025-11-05T16:12:58.000Z"}, {"author": "Nick Doty", "text": "@ekr I think they're compatible, but I think it's an important difference. I would like for a protocol to work even if not everyone wants to commit to the particular implementation style.
", "time": "2025-11-05T16:13:05.000Z"}, {"author": "Boris Mann", "text": "There are various jurisdictions that would like a legible instiutions to help steward the standard
", "time": "2025-11-05T16:13:23.000Z"}, {"author": "David Schinazi", "text": "QUIC was about the airline miles we made along the way
", "time": "2025-11-05T16:13:27.000Z"}, {"author": "Boris Mann", "text": "Democracy is load bearing
", "time": "2025-11-05T16:13:37.000Z"}, {"author": "Boris Mann", "text": "So yes, there is urgency
", "time": "2025-11-05T16:13:41.000Z"}, {"author": "Bumblefudge", "text": "to Boris' point, protocol governance is urgent, not output/v2/vNext etc
", "time": "2025-11-05T16:14:17.000Z"}, {"author": "Boris Mann", "text": "yep!
", "time": "2025-11-05T16:14:32.000Z"}, {"author": "Bumblefudge", "text": "HTTP hijinx police
", "time": "2025-11-05T16:15:53.000Z"}, {"author": "Lixia Zhang", "text": "naming/identifer is the hardest problem, that security directly depends on. making DID a set of differnt things does not get around that problem
", "time": "2025-11-05T16:16:31.000Z"}, {"author": "Eric Rescorla", "text": "I don't think we need a WG forming BOF, if people can get their acts together and write a charter
", "time": "2025-11-05T16:16:49.000Z"}, {"author": "Justin Richer", "text": "@EKR I honestly agree -- it's a big \"if\" there but it's certainly plausible
", "time": "2025-11-05T16:17:14.000Z"}, {"author": "Eric Rescorla", "text": "Justin Richer said:
\n\n\n@EKR I honestly agree -- it's a big \"if\" there but it's certainly plausible
\n
I already wrote you one!
", "time": "2025-11-05T16:17:32.000Z"}, {"author": "Eric Rescorla", "text": "Eric Rescorla said:
\n\n\nJustin Richer said:
\n\n\n@EKR I honestly agree -- it's a big \"if\" there but it's certainly plausible
\nI already wrote you one!
\n
Though it was vibe chartered, because I didn't read it!
", "time": "2025-11-05T16:17:53.000Z"}, {"author": "Ryan Barrett", "text": ":joy:
", "time": "2025-11-05T16:18:05.000Z"}, {"author": "Orie Steele", "text": "I hate that vibe chartering is probably a thing now.
", "time": "2025-11-05T16:18:24.000Z"}, {"author": "Kathleen Moriarty", "text": "@EKR - if not a BoF at the next meeting, could there be an interim BoF? I think it would be very useful to see how the feedback provided is digested and then helps to form the proposed set of work and charter
", "time": "2025-11-05T16:19:35.000Z"}, {"author": "Wendy Seltzer", "text": "The community will help provide urgency, if they want stability and anti-lock-in
", "time": "2025-11-05T16:22:03.000Z"}, {"author": "Justin Richer", "text": "@Wendy it CAN provide it, no guarantee that enthusiasm now translates to urgency when the process gets long
", "time": "2025-11-05T16:22:30.000Z"}, {"author": "Wendy Seltzer", "text": "@Justin, true
", "time": "2025-11-05T16:23:04.000Z"}, {"author": "Martin Thomson", "text": "to be clear about David's version control point, the version control in QUIC was and is not very good
", "time": "2025-11-05T16:23:34.000Z"}, {"author": "Bumblefudge", "text": ":joy:
", "time": "2025-11-05T16:23:49.000Z"}, {"author": "Bailey", "text": ":joy:
", "time": "2025-11-05T16:24:17.000Z"}, {"author": "Martin Thomson", "text": "version negotiation and whatnot is really, really hard
", "time": "2025-11-05T16:24:17.000Z"}, {"author": "Ted Hardie", "text": "@Martin the \"whatnot\" in particular.
", "time": "2025-11-05T16:24:36.000Z"}, {"author": "Martin Thomson", "text": "we had to retrofit a whole lot of stuff into QUIC's version negotiation
", "time": "2025-11-05T16:24:52.000Z"}, {"author": "David Schinazi", "text": "@MT especially when the IETF changes the bits that you see before version negotiation
", "time": "2025-11-05T16:25:18.000Z"}, {"author": "Martin Thomson", "text": "like security
", "time": "2025-11-05T16:25:22.000Z"}, {"author": "Bumblefudge", "text": "+1
", "time": "2025-11-05T16:25:23.000Z"}, {"author": "Richard Barnes", "text": "Links to subscribe to the mailing list at:
\nhttps://datatracker.ietf.org/group/atp/about/
", "time": "2025-11-05T16:26:07.000Z"}, {"author": "Bumblefudge", "text": "instant block from the mailinglist
", "time": "2025-11-05T16:27:09.000Z"}, {"author": "Ted Hardie", "text": "@Bumblefudge. too late, he's already posted.
", "time": "2025-11-05T16:27:25.000Z"}, {"author": "Richard Barnes", "text": "@Bumblefudge - ping me at rlb@ipv.sx if you have trouble subscribing
", "time": "2025-11-05T16:28:00.000Z"}, {"author": "Ryan Barrett", "text": ":clap:
", "time": "2025-11-05T16:28:07.000Z"}, {"author": "No\u00e9 Busson", "text": "Thank you!
", "time": "2025-11-05T16:28:10.000Z"}, {"author": "Anirudh Oppiliappan", "text": ":clap:
", "time": "2025-11-05T16:28:11.000Z"}, {"author": "Akshay Oppilippan", "text": ":wave:
", "time": "2025-11-05T16:28:13.000Z"}, {"author": "Bailey", "text": ":clap:
", "time": "2025-11-05T16:28:15.000Z"}, {"author": "Anirudh Oppiliappan", "text": "Thanks everyone!
", "time": "2025-11-05T16:28:15.000Z"}, {"author": "Seongmin Lee", "text": ":clap:
", "time": "2025-11-05T16:28:15.000Z"}, {"author": "Patrick Singletary", "text": ":clap:
", "time": "2025-11-05T16:28:20.000Z"}, {"author": "Akshay Oppilippan", "text": "thanks everybody!
", "time": "2025-11-05T16:28:21.000Z"}, {"author": "Sri", "text": ":wave:
", "time": "2025-11-05T16:28:23.000Z"}, {"author": "Neema Brown", "text": ":clap:
", "time": "2025-11-05T16:28:25.000Z"}, {"author": "Bailey", "text": "thank you everyone! Some great stuff
", "time": "2025-11-05T16:28:25.000Z"}, {"author": "Teon Brooks", "text": ":clap:
", "time": "2025-11-05T16:28:28.000Z"}, {"author": "Anuj Ahooja", "text": "\ud83d\udc4f\ud83c\udffc
", "time": "2025-11-05T16:28:29.000Z"}, {"author": "Penny Parker", "text": ":clap:
", "time": "2025-11-05T16:28:30.000Z"}, {"author": "Jeremie Miller", "text": ":clap:
", "time": "2025-11-05T16:28:30.000Z"}, {"author": "Giulia Scarnecchia", "text": ":clap:
", "time": "2025-11-05T16:28:38.000Z"}, {"author": "Tynan Purdy", "text": "Thanks everyone!
", "time": "2025-11-05T16:28:39.000Z"}, {"author": "Boris Mann", "text": "Look for your \"I survived the pre-BOF\" badge in your ATProto repo
", "time": "2025-11-05T16:28:41.000Z"}, {"author": "Bumblefudge", "text": "@richard i was saying ekr should be banned for vibechartering on list
", "time": "2025-11-05T16:28:46.000Z"}]