jakebsky

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.

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.

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

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.

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.

> "They also mention that anyone can run another of these, but there is zero chance anyone will be able to do that."

This is an odd claim since it's completely possible today and has always has been.

Each Bluesky Relay and PDS host has endpoints that anyone can use to receive network data (post/like records, etc) in a totally permissionless way.

A Relay:

    websocat wss://bsky.network/xrpc/com.atproto.sync.subscribeRepos

A PDS

    websocat wss://puffball.us-east.host.bsky.network/xrpc/com.atproto.sync.subscribeRepos

And there are additional sync methods as well for doing backfill, etc. Not sure how this could be more open.

Yes, it should be totally possible to build a blogging system on atproto. And the "app.bsky" API should serve as an example for almost all of the functionality required.

Another really neat aspect of atproto, is that apps can interact theoretically. So you might create a blog system but use "app.bsky" (Bluesky) for comments.

OAuth support is coming soon as well, which is a big step in simplifying auth.

Sure, but Apollo made it easy for users that didn't want ads to use Reddit without them. Destroying Apollo removed that ability for most people.

I'm about as anti-ads as it gets but I don't object to other people using apps with ads in them, if that's their choice.

These are just the initial limits while we work out any issues. It'd be bad for everyone if the network was immediately overrun with spammers launching PDS hosts with millions of fake users/posts, etc. Even though our infra might be able to weather this kind of abuse, there are many independent feed generators (custom algorithms) operated by individuals that would likely fall over.

The plan is to increase limits sufficiently to account for all legitimate usage.

(It's also worth pointing out that these limits only apply to our Relay service. The expectation is that there will be other Relays on the network in the future.)