Why would you think it's not open source?

The reference implementation: https://github.com/bluesky-social/atproto

Complete React Native Android/iOS/Web app: https://github.com/bluesky-social/social-app

Go libraries: https://github.com/bluesky-social/indigo

PDS distribution: https://github.com/bluesky-social/pds

All dual MIT / Apache 2.0 licensed.

Because a single corporation owns and develops the protocol. It's single-vendor open source at best.

I honestly don't understand this PR strategy. So much of your success relies on trust.

Even at scale, running a Relay should be well within the means of a motivated individual or org that is willing to spend hundreds of dollars per month. Right now it'd cost just tens of dollars per month to run a whole network Relay. Some people are already doing this I believe.

Running an "AppView" (an atproto application aggregator/indexer/API server) is generally an order of magnitude more expensive and complicated. But still not beyond the reach of a user coop, non-profit, or small startup.

So these services should all be well within the capabilities of at least multiple companies operating in the atproto ecosystem as it scales.

And in many cases it should make good sense for these companies to do this since it will improve their performance by colocating their services and enable them to do things like schedule their own maintenance windows, etc.

Thanks! "It costs thousands of dollars a month, which is feasible enough that people will find a way" sounds pretty reasonable.

For anyone interested, more info about Ozone is available here: https://news.ycombinator.com/item?id=39684027

Haha! Pretty sure most people on the team have seen this post, even prior to the logo choice.

Speaking personally, it just strikes me as very pedantic point with not much substance behind it. I do get why this post is "ackchyually" bait though.

There are no ex-Twitter devs at Bluesky and only one ex-Twitter employee who started this month.

Custom feeds on Bluesky are federated so that anyone can create a new one using any algorithm they wish. There are already many thousands to choose from.

Yes, we have an "AutoMod" system and other protections in place. But it is a cat-and-mouse game, so we expect it to be one of the challenges. But because the network is completely open, it's also something anyone who is interested can help with.

The bsky.app web app is a JavaScript app that runs in a browser. It talks to an AppView (API server) which talks to a Relay which talks to all PDS hosts on the network.

There are other clients for Bluesky that do the same thing as the bsky.app web app: https://docs.bsky.app/showcase?tags=client

For now, yes, our network services are IPv4 only.

In fact, it's mostly inaccurate.

> "the protocol has an official webpage with a waitlist and a private beta?"

Both the waitlist and the private beta are gone.

> "The “protocol” is just a description of whatever the Bluesky app and servers do, it can and does change anytime the Bluesky developers decide they want to change it"

1. atproto is well documented and the plan and desire is to make it a proper internet standard.

2. There are hundreds of independent projects relying on the protocol to create alternative clients and custom feeds (algorithms).

3. The protocol includes namespaced schemas so that different apps can evolve without breaking each other e.g. the "app.bsky" namespace is for the Bluesky microblogging app.

> "The “DID Placeholder” method..."

There is already support for did:web and plans to support other DID methods, including potentially (non-POW) blockchain methods.

> "All posts go through the Bluesky central server..."

All posts go through any Relay that anyone cares to operate. It's also possible to fetch posts directly form the origin PDS host, it's just slower and results in more load on the PDS.

> "And you, as a reader, doesn’t have any control of what you’re reading from either..."

Apps are in full control over where they get posts from. An app can enable users to select a Relay/AppView or fetch posts directly from the origin PDS.

> "But I fail to see why even more than one network provider will exist,..."

People may want to operate their own Relay/AppView services so they have more control for their specific application, for higher performance (latency/throughput) reasons, or for geographic/jurisdictional reasons, to name a few.

And the compute/network requirements are not beyond the capabilities of small startups, non-profits, coops, or public services and likely never will be.

CGNAT is for IPv4, so users can share IPs. It's pretty hard to use the internet without IPv4 access today, so it's not that much of a limitation.

But we do certainly plan to make IPv6 work on all our network services.

That’s… not what I said. If you want other people to host services (like to federate), it’s going to be pretty impossible for the vast majority of people to actually do it if you only allow IPv4 connections.

You cannot federate behind CGNAT, and most folks can only open ports over IPv6, because they don’t live in America where everyone can get their own public IPv4 address. This is a pretty big miss IMO.

Okay, I get what you're saying. Yes, hosting a PDS server behind NAT is a problem.

1. The expected scenario is that people would run PDS hosts on small VMs (Digital Ocean, Vultr, AWS, etc) where an IPv4 address is the default.

2. People running PDS hosts behind NAT would use a tunnel service of some kind (Cloudflare Tunnel, Tailscale Funnel, Ngrok, etc).

But IPv6 is something we do want to support, and it won't be a huge effort. It will just take a bit of time to get to it.

IPv4 is not the default on any of the platforms you mentioned, it’s a paid add-on you must pay extra for.

It just seems strange that a federated social network platform who wants as wide of an audience as possible, gatekeeps who can participate based on a trivial self imposed limitation.

Hope I don’t sound like a hater because I’m excited for this, but yea it’s a bigger deal than a lot of people think. Even just dealing with bots is 100x easier when you have v6 because you can fine tune rules based on ASNs much easier when you can expect v6 addresses from certain networks and what not. We saw this in India the most where most bot activity would be v4 only, while humans would connect over v6, so we could dynamically tune sensitivity on challenges based on solve rates and what not.

Another option is using zrok - https://zrok.io/. Its open source so you could build it directly into Bluesky and either host the backend yourself or use the zrok free SaaS. zrok also has SDKs so you could embed the capability directly into your binaries without having a separate agent.