pds

One of the core features of AT is the ability to move your repo hosting provider (PDS) at any time. This is the "data portability" problem that ActivityPub never solved. Bluesky Social, PBC runs a PDS service (bsky.social) for free, there are a number of free public alternatives, and thousands of users self-host. Self-hosting your own PDS can be done with Raspberry Pi or $5/mo VM and requires very little work. It runs in a Docker container with SQLite. https://github.com/bluesky-social/pds

If, like me, you were wondering what PDS stands for: https://github.com/bluesky-social/pds

Interesting. Ok just saw this https://github.com/bluesky-social/pds > Self-hosting a Bluesky PDS means running your own Personal Data Server that is capable of federating with the wider ATProto network. So pds (personal data server) is like the container where you chose to store the data and it follows a certain standard. If the container is hosted is bluesky, i still consider it a "bluesky api" but I understand the nuance better now.

https://github.com/bluesky-social/pds There are also a couple of discord channels and even a server for PDS self-hosters https://discord.atprotocol.dev

Okay, so this sounds like you'd want to run an appview + pds. (and possibly a relay, depending on some details.) Except for one thing: > or dependent on Bluesky. If you want to take this to an extreme, and are uncomfortable with how did:plc has not yet moved into its own org, then you'd want to also run your own plc server, etc. The problem with doing this is: > If people wanna follow on bluesky they can You lose this. Because you're now not running on the main atproto system, but instead a fully parallel one of your own. Anyway, you could start on this by running a PDS via the reference implementation here: https://github.com/bluesky-social/pds and then building your own appview (application). You could also take a look at Blacksky's implementation https://github.com/blacksky-algorithms/rsky and if you end up using it, consider throwing

You can think of ATProto like this. Each user has a "website" with JSON of their own content (e.g. all my posts, all my likes, all my follows, actually live in a sqlite database hosted somewhere). It's not really a website but more like a git repo — one per user. And then, there's a protocol for how to aggregate information from all such "websites" in the network into a stream of changes. Apps subscribe to that stream of changes and update their local databases (which act as app-specific caches) in response to those events. When I make a Bluesky post, I'm really writing JSON into my sqlite file. This change gets broadcasted to all interested apps which update their own databases (which may or may not care about specific content type like "Bluesky post"). Obviously forks of Bluesky backend do index Bluesky posts (and then return them in th

>in what way can smaller players federate with ATProto or how the structure allows federation. Each of the pieces I've described (PDS, Relay, AppView) implement the protocol specified at https://atproto.com/. Anything that acts as an ATProto PDS can be used as an ATProto PDS, anything that acts as an ATProto Relay can be used as an ATProto Relay, and so on. I'm not sure I understand the question so pardon the tautology. The structure allows federation by design — a Relay will index any PDS that asks to be indexed; an AppView can choose the Relay it wants to get the data from (or skip a Relay completely and index PDS's directly); anyone can make their own AppView for an existing or a new app. That's how there are multiple AppViews (both for Bluesky app and for other ATProto apps) ingesting data via multiple Relays from many PDS's. There ar

> Running an ActivityPub server is piss easy, anyone can do it on a $5 VPS or in their basement, and that's one of its big strengths. same statement can be applied to running a bluesky PDS. Here are the server recs: https://github.com/bluesky-social/pds?tab=readme-ov-file#sel...

A) That article is from was 3 months ago, the network has grown almost 50% since then. B) You can set up your own PDS, right now. If you're comfortable with Docker it should take you under an hour: https://github.com/bluesky-social/pds

Follow the instructions under "Self-hosting PDS" here: https://github.com/bluesky-social/pds

> "Bluesky asks about which server to use on registration" > > No he doesn't ask, you're wrong. It's not very prominent, but the Android mobile app does have the option to change what server you register on. https://ibb.co/s9pzTt3k You can tap on the bold "Bluesky Social" text to change it. > And there is no single one alternative server where we can register and interact with people on bsky.app You absolutely can host a PDS that interacts flawlessly with the rest of the network. I host my own. There's an entire section in the README about self-hosting: https://github.com/bluesky-social/pds?tab=readme-ov-file#sel...

It should be noted that, at least for now, account migration can only go one way. That is, from the main Bluesky PDS to an external one. According to the documentation on account migration[0], they plan to enable incoming migrations at some point in the future, but there's no timeline. I'm sure a big reason for this the possibility for abuse, since "migrating" an account is a different action than simply "creating" a new one [0]: https://github.com/bluesky-social/pds/blob/main/ACCOUNT_MIGR...

https://github.com/bluesky-social/pds You can run your own server if you like There are also 3rd party algorithms, moderation, and interfaces you can mix and match

Bluesky has an initial PDS anyone can run, available on their github. Last I checked they said not to host more than 10 accounts during the beta testing. You can absolutely migrate your account and still use the Bluesky app. The custom server is an option at login https://github.com/bluesky-social/pds