If you don't like BlueSky managing your keys, the alternative to did:plc is did:web. Unfortunately, afaiu, it's not possible to migrate[0]. If this is something you really care about, and you trust yourself to manage your own private keys, you should probably bite the bullet and do it now. Make a pinned post on the old account to point to the new one.
That's the one part you can't migrate; everything else you can change while retaining your followers, posts, etc.
Setting your handle to a domain name via DNS[1] is intended to be easy for non-technical users (especially with registrars adding one-click forms for doing so) and also decoupled from actual PDS hosting. Many users just want their handle to reflect their identity on the web, and are ok trusting BlueSky to host their PDS for free.
Migrating to a new PDS is possible in both the cooperative case[2] or in the adversarial case[3]. The gist is that A: you should take regular backups by exporting your account data, and B: if you're using did:plc instead of did:web, you should register a backup key that has a higher priority than the key held by your PDS, so a malicious PDS can't simply migrate you back.
If you just want to post messages on your website that get syndicated to BlueSky (as blog post links or full threads or whatever) you could have your website server make API calls to your PDS (whether that's self-hosted or not).
If you're talking about building your own custom BlueSky app, "AppView" is not synonymous with "viewer app"; basically it's an "AppView" because it provides a "view" of the network necessary to power an end user "app". I.e. it holds a copy of every single post, repost, and like, so you don't have to. Your custom app would simply make requests to the logged-in user's PDS, which routes most of those requests to that user's preferred AppView.
I view Bluesky as being decentralized-optional. It's cool because you actually can join first and wrap your head around it later. You can continue using your account you created on the fully 1st-party stack, and you still have the option to switch to self-hosting the parts you care about, without losing your posts or followers.
- If you just want to use your domain name as a username, you set a DNS record.
- If what you care about is the client, you can build your own website or native app. You don't really even need to host a server other than for your own static assets, since the app can request Bluesky network data directly via the logged-in user's PDS (they even have CORS headers!)
- If what you care about is data sovereignty, you can self host your PDS (personal data server) on a low-end VPS. It's cheap because it pretty much just holds your data, passes events to Relays, and proxies data requests to your preferred AppView.
- If what you care about is not needing to trust Bluesky to reliably gather and collate events from each PDS, then you'd need to host a Relay ($30/month) and an AppView (even more expensive) so you'd be best off pooling resources with other people you trust. But that's kind of the nuclear option.
- With a narrower scope though: if you noticed that Bluesky was censoring a handful of legitimate accounts and you still wanted to follow them, I think you could probably have a personal Relay+AppView that only listens to the censored accounts' PDS's, and proxies other requests to the 1st party AppView. (I'm not 100% sure if that would be allowed.)
I do think it's a tempting use case, but there are precautions that up I would take if I was doing this sort of thing. Off the top of my head:
- Set up a separate inbox just for the agent, with a forwarding rule that passes on most things that land in my Gmail, but omits as many verification token/password reset emails as possible.
- Have the agent alert me when any sensitive emails do make it through, with suggestions on how to update the forwarding rule.
I guess what's unusual is that the scope includes inbox access.
IMO it's probably a bad idea to have an LLM/agent managing your email inbox. Even if it's readonly and the LLM behaves perfectly, supply chain attacks have an especially large blast radius (even more so if it's your work email).
It seems like they'd have a stronger negotiating position if they had an alternative contractor waiting in the wings before they accused Anthropic of being woke traitors, as opposed to a threat to migrate away over the next 6 months.
But again, the sophistication of their strategery might also have a negative correlation with Hegseth's BAC.
If it's a loyalty test then you'd think the DoD would be willing to let them "fail" and simply drop the contract, but instead they're threatening to label Anthropic a supply chain risk.
If we're going by Occam's razor: it's Friday so Pete probably started drinking ~10:30-11am.
Yeah I'm guessing the TLD was the main signal, based on other comments linking to a thread about "Pinggy", who was also using a .online. The fact that Namecheap is giving them out for free means they probably are more scammy on average.
I've also never added domains to Google Search Console and haven't had blacklisting issue other than with a free .ml (another "cursed" TLD) site that was by default assumed to be spam by Facebook Messenger.
It's unfortunate that this category exists, but I don't share the OP's .com purism; I've used a mix of TLDs and even the cheap ones like .fyi and .cc haven't come under extra scrutiny as far as I can tell.
I think they could get pretty far with a PWA, but there are legitimate arguments to go native. For use cases like podcasts, where users can download them ahead of time, it seems like Safari limits storage to 1GB [0]. Plus playing background audio might not be as good an experience.
Wikidata is a separate project, specifically for structured data in the form of semantic triples [0]. It's essentially the open-source version of Google's KnowledgeGraph; both sourced a lot of their initial data from Metaweb's Freebase [1], which Google acquired in 2010.
Does that logic apply only when the claimed cut is over 100%?
If I advertise that my store "cut prices by 50%" but the prices are actually only 33% lower (which is the same as undoing a 50% price hike), would it be pedantic to call me out on my bullshit?
The web platform on your device needs to be locked to a specific version because the OS stopped being updated. Once the OS stops being updated, you're supposed to buy a new device.
You shouldn't be allowed to use an old device with an updated browser, especially not a browser from a 3rd party, because that doesn't help Apple sell more iPads.
That's the one part you can't migrate; everything else you can change while retaining your followers, posts, etc.
Setting your handle to a domain name via DNS[1] is intended to be easy for non-technical users (especially with registrars adding one-click forms for doing so) and also decoupled from actual PDS hosting. Many users just want their handle to reflect their identity on the web, and are ok trusting BlueSky to host their PDS for free.
Migrating to a new PDS is possible in both the cooperative case[2] or in the adversarial case[3]. The gist is that A: you should take regular backups by exporting your account data, and B: if you're using did:plc instead of did:web, you should register a backup key that has a higher priority than the key held by your PDS, so a malicious PDS can't simply migrate you back.
[0] https://github.com/bluesky-social/atproto/discussions/2705
[1] Alternatively there's an option for HTTP handle resolution instead via `/.well-known/atproto-did`
[2] https://atproto.com/specs/account#pds-account-migration
[3] https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat...