Does Google Reader help you make sense of it? It’s more like each app is like its own Google Reader. And indeed you were able to access the same posts via other apps at that time of outage.
I’ll just say that as someone who was on the React team throughout these years, the drive to expand React to the server and the design iteration around it always came from within the team. Some folks went to Vercel to finish what they started with more solid backing than at Meta (Meta wasn’t investing heavily into JS on the server), but the “Vercel takeover” stories that you and others are telling are lies.
Gosh, Dan, in seeing your response here - I'm truly sorry I wrote this. While I still find opt-out telemetry distasteful and dangerous, I over-generalized to React in a hurtful way. You've been an incredible influence on me and I have the utmost respect for everything you've done. I've shown quite the opposite of respect in my writing, here.
For whatever it's worth on the RSC front: I, and many others used to "if there's a wire protocol and it's meant to be open, the bytes that make up those messages should be documented" were presented with a system, at the release time of RSC, that was incredibly opaque from that perspective. There's still minimal documentation about each bundler's wire protocol. And we're all aware of companies that have done this as an intentional form of obfuscation since the dawn of networked computing - it's our open standards that have made the Internet as beautiful as it is.
But I was wrong to pin that on your team at Vercel, and I see that in the strength of your response. Intention is important, and you wanted to bring something brilliant to the world as rapidly as possible. And it is, truly, brilliant.
I should rethink how I approached all of this, and I hope that my harshness doesn't discourage you from continuing, through your writing, to be the beacon that you've been to me and countless others.
Hey, appreciate the reply! I’m sorry for lashing out as well.
Re: protocol, I see where you’re coming from although I can also see the team perspective and I kind of like it the way it is. The team’s perspective is that this isn’t a “protocol” in the sense that HTTP or such is. It isn’t designed to have many implementations emitting it. It is an implementation detail of React itself for which React provides both the “writer” and the “reader”. Those are completely open source — none of the RSC frameworks need to know the actual wire format. They just use the packages provided by React to read and write. Keeping the protocol an implementation detail of React (rather than an “open format”) lets React evolve it pretty substantially between versions with zero concerns about backwards compat. Which is still quite useful at this stage.
When you’re concerned about wire format not being an open protocol, it’s because you’re imagining it would be useful for others to read and write. But this doesn’t really buy you anything. If you’re making an RSC framework, you should just use the React packages for reading and writing. And if you’re not, there’s no reason to use this format. Eg if you make an RSC-like framework in another (non-JS) language, it’s better for you to use your own wire format that’s more targeted to your use case.
Does this help clarify it?
(Note I do think it would be beneficial to document the current version for educational reasons, which is part of why I made https://rscexplorer.dev, but that’s separate from wanting it to be fixed in stone as protocols must be. I think the desire for it to be fixed is rooted in a misconception that frameworks like Next.js somehow “rely” on the protocol and thus have “secret knowledge”, but that’s false — they just use the React packages for it and stay agnostic of the actual protocol.)
Coincidentally I just watched OBAA yesterday and found it very lacking. I’m so surprised by the positive reception. Great visual, acting and music, but I found almost no emotion in it because none of the conflicts it sets up actually resolve on screen. Characters don’t confront consequences of their choices and don’t grow.
> And I have yet to actually see a real use of ATproto that isn't just immediately blown out of the water by ActivityPub.
ActivityPub doesn’t remotely even try to solve problems solved by atproto. What are you talking about?
In short, atproto makes apps interoperable by default by decoupling data hosting from applications. This means that apps become projections of everyone’s data, and can embed and interpret typed data from each other. ActivityPub doesn’t offer anything close, which is why you don’t have projects like http://leaflet.pub, https://standard.site, https://tangled.org, https://semble.so in the AP ecosystem.
If you genuinely want to learn about atproto, I have two longreads for you:
This isn’t Mastodon so a “Bluesky server” isn’t a thing.
Mastodon is shaped like email so you have “servers” sending messages to each other.
Atproto is shaped more like RSS with aggregation. Everyone posts data to their hosting (which anyone could move at any time), and apps like Bluesky aggregate data from everyone’s hosting.
So a concept like “Bluesky server” is nonsensical. What you have is “atproto hosting” (which can be provided by Bluesky, by other communities, by other companies, or can be self-hosted — it’s all open source and you can even implement your own) and “Bluesky app” (of which there’s only one — but there are forks like Blacksky which fork the entire stack including the server). There also “other atproto apps” like https://leaflet.pub, https://tangled.org, etc, which have nothing to do with Bluesky.
Sure, which is why it's perfectly possible to work around those restrictions using any of the alternative apps that show the same data (but don't implement the legal restrictions).
Also, unlike ActivityPub, it's actually useful for building features that normal people expect from social apps — for example, algorithmic feeds and search, and a single interlinked world (rather than fragmented "servers").
and I actually don't hate that bit (I really like lexicons, although I might have approached it in a different way) - what I hate is the aggregation layer. I know that it is possible to have an AppView-less atproto app (e.g. RedDwarf), but I feel like much of the ecosystem still defaults to the assumption that it will go through the Bluesky AppView.
Unrelated apps (https://leaflet.pub/, https://tangled.org/, http://semble.so/) don't go through Bluesky Appview (since they need aggregations of different kind of data). I think aggregation is the only model that can compete with centralized services on UX, but of course different apps would need different backends.
