I agree that the overall premise is somewhat eugenics-y, but I overlook that on the basis that it's a comedy movie from 2005 and it's easier to swallow than something like "aliens abducted all the world's smart people"[0] or something. There are still some good themes on over-reliance on automation without understanding it.
The Idiocracy line that I think about the most these days is "Brawndo stock dropped to zero and the computer did that auto-layoff thing to everybody."
The CSS selector they used (`a[href*="://"]::after`) is meant to only target only external links, but assumes any internal links will be using relative paths like `href="/about"`. The problem is that this site uses absolute URLs (`href="https://hhh.hn/about"`) for its nav links, so every link ends up with an icon.
You could fix this by adding an exception to the CSS rule so it skips links starting with your site's name:
Not sure how long the subreddit has existed but I always assumed it was inspired by the episode of The Office where Michael asks Oscar to explain what a surplus is like he's 5. The broader usage on social media and the ELI5 shorthand are definitely the result of the subreddit though.
This article is definitely abusing the terminology, because I wouldn't expect even tech-knowledgeable people to know what Nostr is or does.
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.
The Idiocracy line that I think about the most these days is "Brawndo stock dropped to zero and the computer did that auto-layoff thing to everybody."
[0] https://www.youtube.com/watch?v=lllrpcd8vbk