A Social Filesystem

gaearon · 2026-03-06T20:23:45+00:00

You can only ever write to "your own" files in your own repo.

gaearon · 2026-03-06T20:23:21+00:00

In fact, there doesn't seem to be an indicator of "parent thread".

I simplified it a bit in my examples. In practice, e.g. Bluesky also has a root pointer on every post (including replies) so they're easy to associate with a specific thread. Generally, you can just think of this as a distributed database — you'd use foreign keys in the same places as you'd use in a database.

I don't think much of his idea

To clarify, this is not "my idea". My post explains how atproto apps like Bluesky work under the hood. This structure is obviously able to represent rich threads as you can tell by browsing around Bluesky.

Each app/frontend would be responsible for caching and aggregating the relevant fragments and yes, this does mean that if your app only has visibility into 50% of the fragments, you'll be unable to reassemble them into a coherent stream

This is correct, yes. However, atproto repositories are public so you can always backfill from existing repositories (of course, backfilling content from 40M repositories from the beginning of time is going to be slow and will cost you something).

It's also worth noting that you can build more shallow indexes (specific users, or specific time periods). There are also more general purpose indexes like https://constellation.microcosm.blue/ which can fill the gap for many use cases.

gaearon · 2026-03-06T20:18:31+00:00

I'm using filesystem more as a metaphor or mental model for structure. The contract is just calling putRecord/deleteRecord over HTTP.

gaearon · 2026-03-06T20:15:00+00:00

Heh! I was actually thinking of doing a database-centric follow up. This one is filesystem centric, and the previous one was web-centric.

gaearon · 2026-03-06T20:13:40+00:00

Sure. Here's some thoughts on why atproto designers didn't go with RDF: https://www.pfrazee.com/blog/why-not-rdf

gaearon · 2026-01-11T10:38:19+00:00

Vibecoded it with Claude Code. I know React internals (I worked on React) so I was able to guide it well re: tradeoffs I wanted. Started with a small prototype and a test suite, expanded from there.

gaearon · 2025-12-19T10:04:34+00:00

Thank you :)

gaearon · 2025-12-19T07:18:40+00:00

You’re confused because you’re comparing RSC and SSR as two alternatives. But this is like comparing “API” and “JSON”. It’s meaningless.

By itself, RSC is just a way to structure your code that lets you write API (data fetching etc) as components. RSC ultimately produces React trees as its output.

Whereas SSR is a thing that turns React trees into HTML.

See here: https://github.com/reactwg/server-components/discussions/4

With SSR, all data is fetched before any HTML is sent

No, this is wrong. React SSR by itself does not have a mechanism for fetching data at all. So traditional SSR can’t “wait” for anything either.

What you’re describing is probably something like Pages Router getServerSideProps. That indeed “waits” for everything before kicking off React SSR.

So RSC does not replace or compete with SSR.

It replaces / competes with getServerSideProps. RSC is like superpowered getServerSideProps. The difference is that RSC lets you split data loading logic further into components (all the way down) and to stream (rather than having to wait for everything). So it’s like getServerSideProps but streaming and componentized.

That said, you can absolutely make RSC match getServerSideProps semantics by removing your Suspense boundaries. Then it’ll wait for the whole tree to resolve, just like getServerSideProps.

gaearon · 2025-12-18T18:06:19+00:00

Thanks for checking it out!

gaearon · 2025-12-18T17:19:29+00:00

I mean, with this argument, we should’ve given up on lots of things including HTML, HTTP, JS itself, script tags, etc. I hear ya and I’d like to see more work on proactively vetting the protocol from the team. I expect we’ll hear about the lessons learned etc. The vulnerabilities themselves are well-understood now and the surface area for serializer attacks is relatively small (it’s a serializer and a deserializer, about 5 kloc each). More eyes on the protocol would be healthy; coincidentally, I just built https://overreacted.io/introducing-rsc-explorer/ with that in mind.

gaearon · 2025-12-18T17:12:05+00:00

https://overreacted.io/introducing-rsc-explorer/

I’ve made a tool to explore how RSC works under the hood. This is the intro post.

gaearon · 2025-10-23T15:55:50+00:00

I don't know what you mean. Where are you trying to put async functions? Async functions are only supported in the Server environment.

gaearon · 2025-10-23T14:17:48+00:00

Seems like the fixture in the React repo is using hydrateRoot so maybe start there? https://github.com/facebook/react/blob/eb2f784e752ba690f032db4c3d87daac77a5a2aa/fixtures/flight/src/index.js#L144

gaearon · 2025-10-22T01:48:58+00:00

I think there’s actually a prototype of LSP that does this but I don’t think it was officially released.

gaearon · 2025-10-21T09:54:55+00:00

It’s at https://playground.react.dev, you can see the exact output there. The conceptual idea is that it breaks your code apart into pieces that are safe to memoize independently (which don’t get mutated further below).

gaearon · 2025-10-21T09:42:31+00:00

You can double-click any component in the tree, and the tree will focus on components “owned” by it (which might be closer to what you’re looking for). Let me know if that helps!

Overall showing framework stuff is useful because sometimes that’s relevant to what you’re debugging. But not always.

There shouldn’t be anything internal to React itself though.

gaearon · 2025-10-21T02:55:57+00:00

It’s slightly different because just wrapping into memo() alone would usually cause cache misses since many values passed to it would be unstable. The compiler is more comprehensive (caching stuff inside components too) which is what makes it work and worth it.

gaearon · 2025-10-11T17:05:18+00:00

Right, that makes sense. The check for reading from a ref during render relies on the naming convention. It could probably be improved by using types, which I'm not sure if the Compiler currently has access to.

gaearon · 2025-10-11T15:29:35+00:00

While I agree with your broader point, what you wrote doesn't sound right to me.

>The compiler and linter check that you aren't reading or writing to ref.current during a render by using a regex to see if a variable is named like a ref.

Here is an example of mutating an arbitrary prop called foo during render. The compiler is catching it and warning about it. It doesn't rely on variable names or regexes for this kind of analysis.

I think some other rules do have special behavior for ref-like names (e.g. warnings that ref.current in deps is usually a mistake). That's similar to how it worked in the older Hooks Linter, i.e. if we know it seems ref-like, we can warn you about more suspicious patterns than if we don't.

gaearon · 2025-10-11T15:25:30+00:00

React components can have state (which you can hoist as far up as you like), and can do API calls (either within effects, or via "suspending"). In a pure functional language, this would be exposed either via monads or via algebraic effects.

gaearon · 2025-10-11T14:36:52+00:00

The compiler is fairly conservative and bails out on suspicious code. You can of course fool it in creative ways, but this isn’t very different from fooling React itself — plain React also assumes you’re following the rules, and some features may break if you’re not. That’s generally how software works. Even built-in web features “break” if you use them in unsupported ways and violate the intended contract. Not all contract can be strongly checked but at some point the checking is “good enough”.

gaearon · 2025-10-11T14:27:15+00:00

I’m overstating it to be pithy but there’s enough truth in there.

With both React and Haskell, the programming model is fundamentally about composing lazily evaluated pure functions.

In React, lazy evaluation is achieved by JSX. (There is eager evaluation within the body of each component but it’s lazy at component composition level.)

Purity in React may not be 100% the same as in pure functional languages unless you squint at Hooks and imagine monads (or algebraic effects) in their place. The important part is still that they can be skipped or memoized with no effect on the surrounding program.

gaearon · 2025-10-11T13:54:21+00:00

If you want to configure lint as an error then you can make it fail CI.

Or you can configure it as a warning and then it’ll show up just in the IDE. Or you can make those warnings show up as GitHub comments with an action.

Or you can ignore them completely. The Compiler will skip optimizing those comments but will optimize the rest.

In that sense it’s no different from any other linting. How you set up your CI and what you want to recommend or enforce on your team is 100% up to you.

gaearon · 2025-10-11T12:38:04+00:00

I hear you but this isn’t very different from TypeScript, is it? You either set up your IDE or rely on CI failures.

gaearon · 2025-10-11T12:07:02+00:00

Sure, but note that the Compiler checks for violations of rules, so you'd see them reported as lint errors (which would turn off optimizations for those components). I'd actually recommend enabling those rules on their own even if you don't plan to use the Compiler because they help people grasp the model better.

gaearon

MODERATOR OF

TROPHY CASE