I have moved my to own PDS @sgo.to!

Aha! @sgo.to got fixed by the magic of asynchronously indexed databases!!!

Thanks @bnewbold.net !

Most things are working, I think, but one thing I noticed is that the @-reply autocomplete for @sgo.to seems to be still be pointing to @samuelgoto.bsky.social.

Is that just a caching issue that will go away by magic?

I finished my move to @sgo.to, which is now pointed to my own DID with my own implementation of a PDS running in a single and fragile heroku server.

I'll keep this account as a backup!

This is an experiment, try #2!

Will it work this time?

Lets find out!

For sure it does!!!

@sgo.to how is it going?

ah @threddyrex.org figured out that I should have sent an event to the firehose!

bsky.app/profile/did:...

that did the trick!

Aha! I think that did the trick!

But yet, my bsky.app/profile/sgo.to still points my handle to @pds.sgo.to as well as the app.bsky.actor.getProfile?actor=did%3Aplc%3Athaoj4hhvraos7y6v3yog7re is also returning "handle": "pds.sgo.to".

Bluesky Social media as it should be. Find your community among millions of users, unleash your creativity, and have some fun again.

"handle updates happen in DID docs" ... i'm struggling to figure out why bsky.app is still not associating my did with my handle @sgo.to.

So, bsky-debug.app/handle?handl... seems to check out: the DNS is pointing to my did and my did is pointing to my PDS.

ah, requestAccountDelete is also one of these "proxy" things ... at least it comes with a atproto-proxy directive ...

Another one that doesn't seem right to me is this one: com.atproto.server.requestAccountDelete ... the bsky.app is calling this when i try to delete my bsky.app account ... but shouldn't this just delete the records for the app specific records (rather than my whole account in the PDS)?

Is com.atproto.identity.updateHandle also an exception to the rule in that it also needs to change the records that affect the app.bsky.actor.getProfile call to contain the new handle?

Ok, I think I figured out what I'm going to do:

1) Keep this account rather than migrate it
2) Move this account to @samuelgoto.bsky.social
3) Point @sgo.to to my own personal PDS
4) Cross my fingers my own personal PDS won't entirely die on me or get hacked

See you all on the other side!

That looks super interesting! Are you involved?

It was vibe coded in 2 days

I cleaned up my PDS quite a lot and now that I'm proxying most of the requests I feel like the implementation is extremely small ...

I'm wondering if I should migrate my @sgo.to handle to my PDS ...

Would it be easy to export my DID private key from the Bluesky PDS?

I'll wait a couple of days. No big deal, for testing. In the meantime, I've been using darksky, which I'm going to assume is a reasonable proxy for what I'd get in bsky.app once I'm able to do the age assurance pass.

@willem.dobs.nl here is a weird one: app.bsky.actor.getPreferences is an app.bsky.* RPC empty atproto-proxy header ... how should I route this?

I'm testing my PDS against blacksky.community which seems to be using the same services as bsky.app ... so I'm guessing that once I'm able to log in to bsky.app it will work out, but I'm not sure.

I'm running into a "You recently changed your birthdate
There is a limit to how often you can change your birthdate. You may need to wait a day or two before updating it again." while using bsky.app now, anything I can do about this @bnewbold.net other than wait two days?

Oh, wow, I think I was wrong about this!

I stripped out *all* of the app.bsky.* RPCs and proxied them to the atproto-proxy and my PDS is now much leaner and still up and running!

It is only handling the com.atproto.* RPCs!

@bnewbold.net @willem.dobs.nl @threddyrex.org

Yeah ... Im specifically interested in understanding how the browser can help me federate my PDS identity to other websites.

What criteria should a PDS use to determine what to pass through and what to not pass through?

Just clarification question:

When you say "own bluesky compatible appview" and "bluesky appview" do you mean "a PDS that is compatible with bluesky's appview"?

I don't think I'm trying to write my own "appview" (I'm assuming that the "web view"?), but just my own PDS.

I'm not sure I understand ... are you suggesting that I can avoid implementing the listNotifications RPC in my PDS and instead proxy it using the atproto-proxy header? I'm not sure I follow how that would work ... does that require me to have *two* PDSes? one that's mine and another that I proxy to?

It doesn't seem like getLikes and listNotifications was implemented, so I'm guessing that that PDS wouldn't quite work (wrt likes and notifications) against bsky.app, right?

All of the "authenticated" ones do need to be implemented though, right? Like, managing notifications? chats? And then all of the "writes" (e.g. writing a post, liking, reposting, etc)?

I can see how all of the reads it can delegate to a proxy, but there is a non-trivial amount of RPCs right?

I got surprisingly far writing a PDS from scratch, but I feel like it would be a never ending project of covering what the bsky.app UI wants the PDS to support ...

I'm a little conflicted because it would seem that running your own PDS is a big part of the sovereignty that atproto provides .... but maybe I'm mistaken?

Maybe it is more like SMTP/POP where we kind of assume that it is impossible to run your own server and use someone else's instead?