i love the principled approach here. this, after @matthieu.bsky.team@bsky.brid.gy’s work on new lex client, and the ongoing permission sets work, feels like a great conclusion for this year in atmosphere. the APIs and SDKs for atproto are finally getting good

github.com/bluesky-soci...

so there isn’t really a protocol “reader” or a “writer” that isn’t the same thing as RSC itself. unless you introduce some intermediate format or runtime representation which would hurt performance

those APIs don't have first-class reference documentation on the site but there are some docs here: github.com/facebook/rea... but generally those fixtures is a better starting point and that's what framework implementors used in the past

but don't get me wrong, i'd like the protocol to be documented too as a rough reference, even if not meant to be up-to-date or consumable directly

i hear you overall that the default recommendation on react site has been half-baked for a long time. but it's also the one the react team was actually working on and which represented the vision. it's tricky to promote things that don't go along with the vision or even point against it too.

i think there's more to doing that when it spans the network because you want to know what happens in between (even if you don't build any tooling on top). realistically the answer is just there's a ton of "on fire" work at any given time while it was being built, and it's just now stabilizing

re: documenting internals, react never really documented its internals. the few times the team tried to document and expose internals, it often ended up in a pile of fragile tooling built on top of those that stalled ability to make updates and kept people on old versions forever.

i wouldn’t want the protocol development to freeze or have to be evolved backwards compatible. it’s valuable to still allow iteration. but more scrutiny for (de)serializer and more public understanding of how it works would be beneficial. not sure what a happy middle ground is

i think more attention to the protocol is great and will hopefully both demystify it and make it sturdier. it’s tricky because the protocol is an implementation detail of the react packages and some features are still being evolved. which is different from publicly specified protocols.