Comments URL: https://news.ycombinator.com/item?id=48225985

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48193202

Points: 5

# Comments: 0

The screaming “DAMAGE” blocks, “body count”, “(EXHIBIT)”, “7.8X MORE SCANDALS PER YEAR”, all of this looks extremely stupid, screams LLM, and undermines the points the authors want to make.

Every app can display public data from every other app because the source of truth is outside both apps (in hosting).

App owner can’t do bad things to your account other than banning you in their particular app. Other apps (even for same data) independently choose whether to show your data. So app owners are only in control over how your data is presented in their apps, not over your actual data.

Whereas in AP, each app’s moderators literally control your entire identity.

Hosting providers don’t need to discover other hosting providers. Data only flows between hosting and apps; not between hosting and hosting or apps and apps.

An app can choose to ignore/ban some users (or even entire hosting servers if they’re specifically created for network abuse). This is similar to how any web app may choose to ignore POST requests from spammers.

And yes, someone can decide to aggregate data themselves and provide an alternative app over same data with different moderation policies. In fact that’s already the case (Blacksky runs their own application server that mostly piggybacks on Bluesky moderation decisions but overrides some of them. There are also clients that ignore moderation altogether and show you the raw data from hosting.)

These days running a relay is fairly cheap (~$30/mo?), there’s maybe a dozen of them, and some apps don’t use one at all (instead relying on services like https://constellation.microcosm.blue/ for querying backlinks).

1) there’s an app-agnostic hosting layer (and anyone can run a host, a bit like personal site with RSS)

2) then there’s apps, which aggregate over data from all hosts (a bit like Google Reader or Feedly)

So there’s no such thing as “defederating”. You don’t have many copies of Tangled beefing with each other. It’s more like you can run your own hosting for your own data (if you want), and anyone can build an app that aggregates from everyone’s data (Tangled is one such app).

If this got you curious, I have two longreads: https://overreacted.io/open-social/ (conceptual) and https://overreacted.io/a-social-filesystem/ (diving into the data model).

1) a layer of app-agnostic hosting providers + a separate independent layer of apps aggregating over data from those (like personal sites with RSS + aggregators like Google Reader)

2) a circle of flat instances where each node couples app+hosting (like many little Twitters)

One doesn’t couple hosting with apps, another one does.

Mastodon/AP model is (2), atproto model is (1). You should be able to see the outcomes from different network shapes.

In atproto, you can build a new app that works with existing data, but in AP you can’t. In atproto you can move hosting with zero effect on your identity or how you show up in apps, in AP you can’t.

In atproto, there’s two axes.

One is hosting. Bluesky offers hosting but some people host on their own (it’s just a Docker container with sqlite), some on Cloudflare, some on community-hosted nodes like https://npmx.dev and https://selfhosted.social. From app perspective it looks exactly the same way (unlike in Mastodon where “hosting” = “choosing a community”) and you can switch hosting anytime.

Another axis is apps. Apps aggregate from data from all hosts. Bluesky is an app, Tangled is an app, Leaflet is an app, Wisp is an app, Semble is an app, and so on. Those can all aggregate over the same data (which enables cross-app interop) but they don’t have to (eg Bluesky doesn’t overlap with Tangled much except that Tangled can reuse Bluesky avatar on login). Generally you don’t have people running copies of the same app (as in Mastodon) which is why there aren’t many “blueskyes”. But when someone has an incentive, they can. (Eg Blacksky is a complete fork including server and DB, allowing their own moderation decisions over same data.) Similarly you can build your own app on top of distributed Tangled data.

Hope that helps clarify why “atproto provider” as a concept doesn’t make sense. You have hosting, which is as distributed as you want, and you have apps, which anyone can make.

It’s a bit long but should give you a really crisp picture.

ActivityPub is email-shaped. Servers are inboxes sending messages to each other.

atproto is web-shaped. User repositories host data (like personal sites or git/RSS), while apps aggregate from repositories (like Google Reader).

Different topologies lead to different properties. Eg atproto lets user change hosting with no disruption in app experience. atproto also lets anyone build new apps aggregating over existing data.

ActivityPub doesn’t allow either of those things. It’s literally a bunch of small centralized coupled hosting+app services messaging each other.

>Not just sell. Not just ship. Use.

>The honest read ... The hopeful read ...

>The grumbling isn’t about features. It’s about the texture of using the products.

>Yes, Apple Silicon is incredible. Yes, the Watch saved lives. Yes, the iPhone got better cameras

There's also bizarre not-quite-landing uncanny metaphors that LLMs love to do:

>Today's Apple ships friction and treats it like background radiation.

>The texture changed.

>And the rot follows that exact line.

If you're surrounded by this kind of writing, it may be good to get other inspirations. It's bad!

Is it really so hard to write your articles by yourself? The blandest tone imaginable, all the usual LLM tells in the sentence structure. You are polluting HN and the broader internet by posting this publicly.

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.)