For folks who don't know how passkeys work at a technical level, take a look at this implementation guide: https://webauthn.guide/
I don't get the passkey hate -- moving to public key challenge for authentication is a strong step forward for web security. Each browser / OS safeguards & backs up the private key (and even if that's lost, you can still reset your auth credentials using a normal "forgot password" flow).
The linked article does a quite good job explaining why hating passkeys make sense.
Here's a key quote, but I do recommend reading the whole article.
> Since then Passkeys are now seen as a way to capture users and audiences into a platform. What better way to encourage long term entrapment of users then by locking all their credentials into your platform, and even better, credentials that can't be extracted or exported in any capacity.
I don't believe this is necessarily true, as far as intent goes. I think Apple and Google focused on a core use case, shipped it, and subsequently lost interest or fired everyone involved.
Unfortunately, this scenario is indistinguishable from one in which they deliberately mishandled the specs in order to lock in users.
Thanks for your faith. I work on the team shipping passkeys at Google. We are very much hard at work to realize the full potential of passkeys. Platform lockin serves no one. That is no one's intent - independent password managers storing passkeys is already a thing today. More interop will come once relevant standards are blessed.
This is precisely like the imaging standards trying to replace JPG. After two decades of vendors like Google trying to establish a new standard, I can’t send anything other than an SDR sRGB JPEG to anyone, especially to an Android user.
The current post-JPG formats may as well be called “the Apple format”, “Google image”, and “Netflix pics”. There is no practical interoperability to speak of.
I’m seeing the exact same dynamics play out with PassKeys: lip service to interoperability, meanwhile consumers are left twisting in the wind, locked out of their lives because Google can’t play nice with Apple. Or Microsoft. Or anyone else.
“Interoperability is coming” is a statement in the same category as communist dictatorships promising true socialism and freedom… you know. Eventually. Just not now. Or next year… maybe later.
There is a significant amount of interop that already exists, that folks are looking past or just already taken for granted (which is actually fine too!). While on a Windows machine using Edge, you can save a passkey for your Google account to your 1Password vault, and use it to sign in to that Google account on Chrome on Mac (if you have signed in to the same 1Password account on the machines). Or you could use a passkey you saved to your iPhone / iCloud to sign in to the Google account on ChromeOS. This is the level of interop that exists today. This did not just happen magically - all these companies (and more) worked hard to make it happen.
Also speaking for Google accounts, passkeys are an additional option for users. Using a passkey is not preventing you from keeping any other sign in method on your account that you feel has less of the lockin risk.
If you can enumerate the few specific scenarios that work, after “companies worked hard to make it happen”, then there is no interoperability to speak of.
This is like someone from North Korea saying that they are free because they’re allowed to go to three specific cities in China for work.
Interoperability is an afterthought.
Even if that NK citizen is allowed to go to dozens of foreign countries, he’s still not free. There’s a fundamental difference between enumerated positives and enumerated negatives. Interoperability would be if every combination worked with only a handful of exceptions.
PS: Literally just after I made the comment above I had to add a PassKey to PayPal and only 1 of 4 scenarios that I tried worked.
I notice you responded to this and not any of the other critical threads (at least, at time time I'm posting). Tell me you're defensive and have no leg to stand on without telling me you're defensive and have no leg to stand on.
> This is precisely like the imaging standards trying to replace JPG. After two decades of vendors like Google trying to establish a new standard, I can’t send anything other than an SDR sRGB JPEG to anyone, especially to an Android user.
Android supports WebP since Android 4, HEIF since Android 8 and AVIF since Android 14. They are only missing JPEG XL, but to my knowledge neither iOS nor Windows support that format natively either.
Regarding interoperability and support for open formats Android/Google is way ahead of Apple or Microsoft in my experience.
Having a library in the OS and actual interoperability are vastly different things. Not only do most consumer chat apps completely disregard HDR, but even worse, sending HDR images via almost any such channel has a high chance of the colours being mangled or -- at best -- silently converted to 8-bit SDR.
Also, unlike Apple iPhone users, people with Android phones tend to get stuck on older major versions and can't upgrade. Easily half of all Android phones out in the wild can't correctly tone map or display either wide-gamut or HDR still images.
You can absolutely do public key challenge authentication with passwords. You can use argon2 to derive the secret key for your account from your password and use that to encrypt a challenge message
I've used ChatGPT to write my tests. It's pretty effective at getting the first 5-6 use cases written out, but in a style that isn't correct. Copy/paste a code module, ask it to write the tests.
Then, in the same context, you correct it by providing it with more information about how you like to structure the tests. It starts to understand the "style".
Then, you start to provide the context with testing concerns. By the end of it, the AI context is pretty good (80-90'ish%).
It's nice, as a developer, to be able to say: "test that asset is deleted when DELETE /asset/:id", and the AI converts that into a proper test case, using familiar variables / test structure / corrects the abbreviated text into a proper test title, etc..
I think most stressful development environments happen because a manager either isn't familiar with how software development is done (resulting in unreasonable expectations), or the manager isn't communicating expectations upwards effectively.
It's important to understand when the business needs a certain capability, and that should be communicated to the development team (so that the correct scope tradeoffs can be made). Bonus points if the business can communicate the challenge they're trying to solve as opposed to the desired output. (Sometimes, you can start with a simple shell script that relieves the pressures of the business while iterating towards a more feature-rich solution.)
It's also important for the business to understand that the goal is a minimum functional implementation for the capability, and that there are development quality standards that must not be sacrificed to hit a date (bad code is a liability). Also, they have to understand that the date they are communicating to the development team is a "I would like it by this date", not a deadline / guarantee that they'll have that software capability on that date. (As a consumer, I do not set deadlines on a provider in many industries.)
Finally, a manager needs to understand the project health on a regular interval and communicate progress and confidence levels as the project continues. This is usually where expectation management goes wrong -- because the conversation about the work becomes metrics driven (instead of talking about the true story of what is actually happening with the work).
Everyone involved needs to understand the flexibility required to develop a useful, trustworthy product -- and that the time required will vary depending on a number of factors (some knowable / mostly unknowable).
As long as there is trust and expectation management between all stakeholders, a program will usually go positively (and relatively stress free).
(Lessons learned from shipping enterprise software applications & running a development consultancy.)
What are the expectation from a developer in this world? I ask because you listed a bunch of expectations from management and business. But the “system” consists of a third element too - developers! What are your expectations of them, in this idealized set up?
- Transparency about the work.
(Communicate progress without being prompted. Share screenshots & be excited about what you develop!)
- Don't be a hero. (If something is difficult, collaborate with the team and don't go it alone.)
- Be minimal. (Development is an additive process, and it's easy to "chrome plate" a development story. Be minimal and discuss above & beyond opportunities with the team before working on them [or just create a ticket for later discussion].)
- Don't compromise quality. (It's easy to want to skip tests or refactor later, but that carries invisible costs & churn during PRs.)
- Refactor as you go, but don't over do it. (Nobody likes a 1000 line PR. A major refactor means large code change [risk], large review, churn on correcting the PR, long time before feature is merged, ...)
- Solicit feedback when you do want to cut corners. (Explain what the cost is in a quick implementation and why it's a good idea to implement minimally at this phase. Identify ways to mitigate risk / make refactor simple later.)
- Don't overwork. (Developers tend to work harder in off hours and burn themselves out. What they don't realize is that their total contributions to the team go down significantly when they overwork.)
- Be honest. (In a team development setting, some folks will communicate that they're further along on a story than they actually are, with the intention of making up the development effort. This causes overwork -- and the rest of the team can pick up on the dishonesty. I would rather have a member of my team say that they're having an issue with solving a problem [or there are external life factors] than feeling like they have to go it alone.)
- Ask for what you need. (Organizations can easily pull developers into meetings and monopolize their time. Push back and ask for focus blocks.)
- Be candid in retrospectives. (It's the one venue where management is literally asking you what could be better. So many times, people are waiting for someone else to speak before they voice their opinions. Have a conversation with a team member before retro to validate your opinions if you are self-conscious about them.)
- Be candid in 1:1s with your management. (Typical management will lose the developer perspective and rely on feedback to be able to adjust team policies. If there's no feedback, then problems fester.)
--
I get that this list leans on being extroverted -- and that some folks are introverted. It's totally a vulnerable position to put your hard work / opinions out in front of a team for review. It's even more intimidating (impostor syndrome) when you're working with really smart people.
A good manager will mentor their staff on how to follow through on these expectations, and will also actively work to make the team environment a safe space for constructive conversation.
There's a lot more micro nuance depending on the team and business environment, but generally, I believe this is a good starting point.
If I wanted to create a consumer hardware product that packages the PDS host in a user-friendly interface, does the software license permit that?
Also, services like Twitter started off with a developer friendly open API, and then it got closed off when the business needed to make money off the platform. What's the difference with Bluesky?
It's MIT/Apache 2.0 licensed, so yes. However, because it's also an open protocol, even if it wasn't, you could write your own under whatever license you want.
> What's the difference with Bluesky?
BlueSky is built off of an open protocol, called AT. https://atproto.com/ BlueSky is a particular app built on the protocol. As such, there's no way to "turn off the API," as BlueSky itself is a participant in the open protocol.
They could like, re-write everything to be a central service, port the user data over to it, and then pull out from the network, but then two things would happen:
1. stuff would break, as it's no longer part of the network.
2. since there is true account portability, users could simply swap to a different PDS and client, and re-route around the damage.
Also given that it's against their entire stated mission and goals, it would be social suicide.
Ok, I think I understand the hype now — this is sweet? Thanks for the reply.
When I was thinking about rolling my own federated social service (during the whole Twitter / Mastodon shuffle), I started thinking about the negative impacts of federation. “How can I build a kill switch into this thing in case bad actors start to participate?”
Of course, that means a central authority having moderation control.
But then, part of me thought.. does there need to be a kill switch? Do we want centralized moderation control? If laws are being broken, or social issues are being pressed to the fringe (*lons X), then the ISP would intervene. Or… the responsibility of moderation shifts elsewhere than the provider of the software. (To where do moderation responsibilities shift, if anywhere? I think is still a question.)
I personally landed at the spot of: it’s really no different than what the WWW provides — it’s just easier access. But, is that easier access to self host content and media dangerous? (lol I guess I’m still conflicted about what could happen with wider ease-of-access to self hosting.)
… back to sleep. This stuff literally keeps me up at night lol
(I didn’t get to the other comments further down in this post that talk about content moderation .. but I’m seeing them now!)
I think you mean automatic reference counting (ARC) — and ARC happens at compile time as part of a static analysis pass. (The compiler is basically adding retain/release code for you.)
At runtime, it’s functionally close(ish) to malloc/free and doesn’t carry much overhead.
In my understanding, it’s both: you’re right about Automatic Reference Counting (ARC) being a compile time pass. But the reference counts that they use for said retain/release are atomic reference counted (ARC).
ARC certainly helps ARC be more performant than ARC without ARC due to the elided traffic on the count. (lol)
I’ve been evaluating FreeBSD, and the primary thing that I miss is the ease of use that comes with using docker images.
The jails system + zfs is pretty nice. If there was an ability to snapshot a jail and easily package it as an image… I wouldn’t look back at docker again.
I admit that I'm not familiar with docker, but I had assumed their import/export would deal with images. Or is that not true?
See https://pot.pizzamig.dev/Images/
I don't get the passkey hate -- moving to public key challenge for authentication is a strong step forward for web security. Each browser / OS safeguards & backs up the private key (and even if that's lost, you can still reset your auth credentials using a normal "forgot password" flow).