I've also done a full network replica (all the data indexed in a postgres) on a raspberry pi (with an 8tb nvme attached via a hat). Its really not expensive to do . And if I wanted to drop data older than say 3 months, it would be even cheaper still.
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.
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
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
> 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.
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).
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
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)
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.
"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.
While individual posts are not self-authenticating (largely because it makes deletion much more complicated) all of a users posts are in a merkle-tree that it itself self-authenticating. A Post and the merkle-proof to the root its a complete verifiable entity.
https://docs.bsky.app/blog/plc-directory-org