jakebsky

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.

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.

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.

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

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

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

Reddit destroyed Apollo so they could inject ads into the Reddit experience.

Bluesky doesn't have the ability to do this. There's no API key to revoke that could stop someone else from running parallel apps/infrastructure/etc. The network is completely open.

Currently, atproto works probably best for public social apps, like microblogging, forums, etc. So yes, it's definitely possible to build a reddit-like social app on atproto.

Part of the change today is that the PDS and Relay[1] now support non-app.bsky record types. This is quite new, so there could be issues, but we're prepared to fix any issues that crop up.

1. https://bsky.social/about/blog/5-5-2023-federation-architect...

Thanks for Caddy, Matt! Some of us on the team have been using Caddy for years, for many of our projects. Because it's so simple, sufficiently high performance, and has lots of nice features.

The on-demand TLS certificates with an "ask" endpoint is especially useful for the PDS use-case. Because there's generally a wildcard DNS name that is used to give each new user a domain handle (@alice.example.com) but we don't want to be vulnerable to a TLS certificate DoS/rate limit situation.

There are a number of independent projects using atproto in various ways.

There's an (incomplete) list here: https://docs.bsky.app/showcase

And the protocol is documented here: https://atproto.com

Yeah, there's nothing preventing someone from running the PDS server on other distributions. The installer just does a few convenient things for you (like install Docker, opens port 80/443 using ufw, etc) and we haven't added and tested support for other distributions.

There is a Docker compose file in the repo, and advanced users shouldn't have any problems running the code on another distribution or even without Docker if they prefer.

Advanced users can just view the installer script as documentation.

Yeah, you're right, it was. That was temporary measure during the public launch to prevent spam/abuse. We've made some improvements here recently.

Yup, it's MIT/Apache 2.0. We'll fix that. Thanks for the heads up.

This is just for a brief period during polishing/debugging since this is the first time third-party PDS hosts have been added to the network.

The goal is just to help PDS operators join the network and make sure that if there's a problem we have a channel of communication open.

Thanks Steve! You've been very fair the entire time and your feedback/thoughts have been helpful.

Thanks!

Yes, it's totally up to a PDS operator to decide how they create user accounts. It's also not required on the Bluesky PDS service any longer, in most cases.

By default the self-hosted PDS requires an invite code, to prevent random people from creating an account. Later other options will exist, including OAuth support which is coming soon.

The network is designed to be "locked open" in a way that prevents this. The architecture is designed to work like the web.

Hey HN, the engineering team at Bluesky is especially excited to get to this point! We're happy to help answer questions and help anyone trying to run their own PDS host. Things should work pretty well for self-hosters right now, but we're standing by to help if there are any problems.

Technical details and the installer are in the GitHub repo https://github.com/bluesky-social/pds

And we're on Discord available to help: https://discord.com/invite/UWS6FFdhMe

Limited functionality for a specified subset of users counts as "very little" to my mind given that they launched 6 months ago and have a team of hundreds working on it.

But like I said, I sincerely do hope Threads follows through on their plan to federate. But it's just not correct to claim that they already have.

We do have an anti-abuse tool to help flag abuse. It is obviously important that PDS operators not allow themselves to become overrun with abusive users.

Anyone technical can run their own single-user or low-user-count PDS and probably not have to worry about any problems.

Yes, it's always a bit of an after thought (unfortunately) but we have improved it already a couple of times.

And like most things with atproto, there will likely be protocol support for pluggable search engines, so users can choose their search provider(s).

It's already entirely possible for others to operate atproto search engines since all the data is public and available.