The default pds packaging takes care of SSL, but thats not a requirement, just something we try to make easy for users.

Also at:// URIs are of the form at://DID/..., and your human readable handle is bound to your DID through DNS TXT records _atproto.roshangeorge.dev, but applications all know to render that as just roshangeorge.dev. That DID points to a document that specifies where your server lives, so the HTTPS/WSS routes can live wherever you want them to.

Also likes/replies/etc on your posts go in their authors repos not yours, your intuition is correct there.

You can authenticate a handle via a file in ./well-known/ at the domain too, which is how bluesky does it for their default handles.

people get so up in arms when you suggest there might be a limit on how many people they can follow.

fwiw, the Knuth quote is "premature optimizations are the root of all evil"

I tend to agree with this, thats why theres canonical URIs for atproto posts that are agnostic to the hosting provider. The format is at://DID/collection/recordKey.

These are used throughout the system, for example if you look at the output of a feed generator, its just a list of these URIs

In some ways that's worse because it means you can be blocked at the DID layer.

It's possible, and we've talked about it, but it would take a good amount of work (as would any 'correct' solution), so we have punted on properly solving DMs for a bit. I know Matthew has been very interested in working with us to figure something out here

On the Matrix side, we’d definitely like to help make this happen. Decentralised e2ee is Hard, and after a lot of iteration we’ve got Matrix into a good place these days (plus there’s a new wave of React Native Matrix dev happening atm). Plus we’re not shy about doing stuff like switching IDs on Matrix to DIDs, or even supporting ATProto as a federation mechanism and client/server API if that’s what it takes. https://bsky.app/profile/patak.dev/post/3lbbxbekjw22q gives more context.

What would suck is if bluesky ended up with an entirely incompatible (but functionally identical) thing, so that all the existing Matrix clients, bridges, servers etc couldn’t be leveraged.

> My assumption for this being proprietary is so that it cannot be gamed. It could be a darker reason, I suppose.

As the guy developing said feed, this is indeed the reason. I have a hard enough time as it is with people gaming the specific parameters of the feed, having it fully open would be a huge tax on my time.

Most of the components of the feed are trialed in my personal feeds repo here: https://github.com/whyrusleeping/algoz

You could take the code from there and get to a workable "Discover" feed relatively quickly if you wanted to. Also several of the feeds I have in that repo are among the most popular feeds in the network, especially Quiet Posters (infrequent.go).

Algorithmic curation is, I believe, a key to making (para-)social media enjoyable and Bluesky is the only (semi?) open project I’m aware of investing in this type of stuff. It not being open is a bummer. Is there any good reading material on this topic?

I believe in a world in which people can choose and tune their algorithms, a diversity here should make them harder to game, as well as a highly-weighted „not interested“ button.

It’s surely not the plan to keep this proprietary forever, right?

its been consistent around 10/s most of today, hit even higher bursts at points. Its been steadily increasing every day for the past week.

It is indeed an open source app for an open source protocol.

yeah it works fine on bare metal, you'll just have to do a bit more set up work yourself (https terminating and such). The installer script should be instructive in how to run it but you'll have to figure out the BSD specific stuff

"Kinda" and "Soon", the soon part is that interactions with the site are signed by a key thats usually held for you by your PDS (Personal Data Server), this month we are opening things up more so you can run your own PDS, and thus use your own keys.

The Kinda part is that your identity by default is backed by a DID that delegates authority to specific keypairs. The keypair that your PDS uses to sign is included in there automatically, but on account creation you can currently set a backup keypair that allows you to manually sign identity operations.

I realize this may already be on the roadmap for after open federation, but I would love some sort of "bluesky for the truly paranoid (affectionate)" guide that explained soup to nuts how to participate in the network by running your own PDS and using did:web for identity. An answer to the question: I don't trust plc.directory for my identity and I don't trust the bsky.social PDS to host my data but I want to participate — how do I do that?

I have probably the least understanding of how this part of the protocol operates. Part of that has to do with the new (to me) concepts and the rest is open federation not being in place. I think something like this would be really useful and would prove your bonafides to others that Bluesky PBC is serious about being billionaire-proof.

Congrats on opening up registration!

The most straightforward way to fully use the network without trusting us at all would be to have your identity backed by a did:web, and run your own PDS. From there your posts will be indexed by our appView and you can see them in the app. If you still don't trust our AppView to show you the right thing, you can definitely run your own (its a little hefty and requires indexing the whole network). Beyond that, if you don't trust our relay to feed your AppView, you can run your own and have it scrape all the PDSs (the endpoints for this are open on each individual PDS). At that point the app experience for you should be roughly equivalent (depending on how you choose to apply moderation actions) without using any of our infrastructure. You would still be able to interact with everyone, all your followers can still see your posts, and no normal users would notice you werent on the same servers as them.

Love it. A "choose your own adventure" depending on how much you distrust Bluesky PBC :)

My only feedback would be: I'd love to read a real deep dive on just bringing in your own did:web and using a custom PDS. The DIY AppView and/or Relay is super interesting, but that more straightforward concept of "you own your identity and you own your data" is such a powerful hook that I'd love to be able to share something straight from the docs.bsky.app domain on how to do it.

This would be very cool. Thank you to the team for exploring in this direction.

What cryptographic primitives are supported?

currently we support ed25519 and secp256k1 for signing, adding more key types isnt terribly hard, but does require coordination (everyone has to support it otherwise posts signed with that key type won't get propagated)