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

Except that, crucially, RSS/Atom plays well with static nodes (e.g. personal websites generated with Jekyll/Hugo/whatever—or even written by hand[1]), and Atproto does not. (Nor does Mastodon; previously: <https://news.ycombinator.com/item?id=30862612>.)

It'd be great if the complexities needed to support the "Atmosphere" were widely recognized/acknowledged to be overkill and soon enough ended up going the way of things like CORBA and WSDL while in its place a resurgence of interest in the Atomsphere emerged.

1. <https://m15o.ichi.city/site/writing-atom-feed-manually.html>

Atom was designed for news, before social media existed, where 15+ minute polling times were (borderline) acceptable. Atproto was designed for social media, in an age of Twitter users getting their news in seconds, to the point of being able to comment on live events play-by-play. There's no coming back from that world.

With that said, I wish both Mastodon and Atproto supported opt-in pull-based, static sources.

And this is widely recognized by now to have been a very bad thing, even/especially those most susceptible to its draw. It's strange that you're framing it as a strength and not a lament.

> There's no coming back from that world.

You can't say that when everyone just begs the question and shoves application-server-needed-here protocol designs to the fore.

It has upsides and downsides. The ability to live-post an event, or get up-to-the-minute news, can be a good thing.

Atproto's PDS is the root idea that everything extends off of, is the "social filesystem" that you control. There's a protocol objective to be able to spread your data around widely and for folks to be able to cryptographically check that that data came from you (even if you have to change hosts or even if someone sneakernets your data around). That's going to have some complexity! But it allows aggregation, is essential to how we are able to syndicate data so widely in atproto. It's so important it's in the name: Authenticated Transfer protocol.

And that in turn enables systems like Tangled here to be built, that layer stop the personal data servers, and relays. These work because there is identity.

If you need your static site to be on atproto (yay!), you can just have one of the various PDS hosts (such as Bluesky or eurosky or black sky or npmx) host the PDS for your. Since it is authenticated and user sovereign, you can permissionlessly move to a different host whenever you please, should that go awry. It's unclear to me why static site needs are an interesting or useful target that social networking ought conform to.

If you want to make a simpler network where we don't have those guarantees, please go right ahead. It feels to me like a snap reaction though that doesn't bother weighing what we have gotten or why things are this way, that is reflexively demanding.

These seems to defeat the purpose of the relative amount of sovereignty that hosting a static site gives you compared to depending on a PDS.

> It's unclear to me why static site needs are an interesting or useful target that social networking ought conform to.

How is this possible?

Your lack of a reply at the end, refusing to support basically your entire ask with even a modicum of supporting cause, feels a bit vindicating, that indeed you are a hostile agent & not here to engage or discuss, but to throw bombs.

Have we met?

Unless they gut or disable their API, and then ban scrapers, although I understand why after seeing bots crush sites.

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.

And if the answer is "yes" then at least when someone "makes their own app" can they easily use "Bluesky hosts list" + add special extra hosts (or remove specific hosts) so that the app relies on the platform, with the exception the disagreement point?

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

In ATP, your data is stored in the "Atmosphere", hosted on decentralized "Personal Data Servers" (PDS). The app then simply parses and filters that data. They can apply moderation actions by choosing not to display or read certain posts, but your data still exists and another app could choose to display it. Similarly, if the app goes down, your data is still perfectly intact in the Atmosphere.

It might then seem like the PDS is equivalent to an AP instance, but as mentioned, they are decentralized. Identity is verified through signatures, so if your PDS goes down, you can migrate to a new one as long as you have your signing keys. Therefore, the account belongs to you and not any specific server.

Domain here referred to the area of influence or control, like what the provider of a relay effectively has. The fact that other groups can run any element of the infra themselves doesn't change the fact that the drift towards centralization is much greater with ATP than with AP.

ATP has its own uses (quick aggregation) but it doesn't even attempt to solve fundamental issues of current ecosystem of social networking,. AP, on the other hand, offers the foundation for further development in the right direction.

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.

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.

Proper federation is exactly such bunch of small services messaging each other. On the hand, what ATProto leads to is at most a handful of large-scale providers each running the own portion of the network.

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.

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.

Stuff like this:

> Each one of these, on its own, is just a bug. Together, they’re a culture.

And the headings starting with "The"

AI seems to have adopted a style reminiscent of startup marketers circa 2020 - really simple, lots of one liner quips and far too much incredulity about minor things. Now we've come full circle!

I'm the first to say I'm not the best writer...

Or is this also true: "I don't change what a LLM writes so long as it doesn't seem like something I would write"

It's just like vibe coding it's the new normal. We don't notice our own unique voices when writing. But as a collective we do notice LLM voices.

Submissions are different than comments in HN rules - don't worry about it.

>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!

I enjoyed your article and shared it on my family-geek-whatsapp group

This article on the other hand has 1: https://routerjockey.com/introducing-graphiant-the-future-of...

I don't mind either way, but reading through the Tim Cook one without opening the comments on HN, I was 99.9% sure I'm reading AI.

LLM's got their inspiration from popular sources written by humans. Now humans are exposed to LLM on repeat basis every day. It looks only normal that writing done with or without LLMs tend to converge to the same style.

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.

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