Forest @forestjohnson@pixie.town

@Ninji rookie mistake, they forgot the ".. or else you're going to jail" suffix on that part of the prompt 😆

@jonah to be fair the "lose phone = lose account" problem also happens with passwords, because of the issues with passwords outlined in the article: people chose passwords that are hard to remember, and then don't write them down.

I just don't like how with passkeys, there was an explicit design desicion by apple and google to _prevent_ someone from writing them down or copying them.

So maybe my complaint is only valid for a specific kind of person who wants to have their own copy of their credentials.... But IMO if you don't have your own copy, do you really have it at all?

I tend to lean heavily into the A and I parts of the CIA triad because in my experience that's where 90% of losses and issues occur for average computer users, while at the same time I believe the public consciousness has a bit of a blind spot around it, and usually blames the victim when loss does occur. "You should have backed up", "you should have used vaultwarden", etc.

@jonah mostly my complaint is with the way the mainstream passkey UIs hide whats happening from the user and take a "we know better than you" approach; there's no affordance for backup.

IMO its similar to how totp 2fa started. Then 2-3 years later after everyone started losing access to thier accounts end masse and complaining loudly, 2fa backup codes became the norm.

Same will happen with passkeys IMO. I'll wait.

@jonah well for starters if you register on a site on your phone, opt for pass key, and then lose your phone, you lose the account access.

It takes another system like strictly disciplined redundant device use or more realistically, a password manager, to be able to keep the passkey across device loss.

Note im not including google or apples own password managers in this, IMO they dont count because

1. It can be taken away from you, you use it at the pleasure of the company.

2. they don't allow export AFAIK

@jonah @privacyguides Sorry, maybe that was too harsh, but I really think the article should be amended to... Place a explicit bold red warning about the risk of loss at the top of the passkey section.

I know that it does mention that it's possible to sync them and it's possible to have multiple passkeys, but... It doesn't show how, and it doesn't mention that that's not the default.

@jonah @privacyguides Oooof, ooof, ooof, this is really irresponsible.

This article only mentions the cons of passwords and only mentions the pros of passkeys.

Most paskey solutions are completely non-portable, proprietary, locked to a single device, and have no backup. So if you lose your device, you lose everything.

I don't think we should be advocating for a passkey usage until there's a coherent story about what happens when you lose your device.

@autonomic

Njalla ?

If you want fully "cooperative", there's always namecoin .bit domains. They just... Require a custom client, and dont auto-renew, and.... 😥

@neil boogertown usa

@kawaiipunk Okay, I didn't actually make this food. It's from a local diner, but I just wanted to share the pictures.

@kawaiipunk

@kawaiipunk

@kawaiipunk you are making me drool, but I just want something green added, and btw can I drench it in hot sauce? ❤️‍🔥 that's the USA punk way, lol ❤️

@djh I'm starting to remember this now.. The z curve has slightly more discontinuities iirc but its also easier to find the sub sections. My method is kinda "brute force" based on sampling a reduced resolution version of the curve in order to decide where to split up the sections before running the actual DB queries.

But in my opinion, the most important thing to call out about all of this is that you don't need different database software / you don't need to modify the database at all. The app that talks to the database just needs to Use this "one weird trick" to generate keys and query ranges.

@djh

i don't understand what the bigmin thing is, Are you talking about an in-memory search or a database (on disk)?

I made my own version of software that does this. It uses a different space filling curve but the idea is the same. How I thought abt the query running really far outside the requested area: essentially you have to decide whether you want to prioritize fewer individual IO operations or less wasted IO bandwidth.

Since data on disks is laid out as one sequence, typically it's faster for a disk to read a little bit more data if it only has to do one single sequential scan, as opposed to reading a bunch of different little bits and pieces.

My solution simply downsampled the curve until It was no sweat for the computer to make a list of every single point on the curve within the queried area. From there, I settled on an algorithm that looked at the points on the curve and decided how many segments it would split them into. If the distance between two points was larger than the queried area, then I wouldnt join those two points into a contiguous segment, I would split the segments at that point.

The cool thing: this 1 rule perfectly expresses the trade-off between how many IO operations and how much wasted bandwidth. And it's tweakable at query time, not at indexing time. So you can set a coefficient for that threshold depending on the performance characteristics of your disk when handling your given data set.

https://sequentialread.com/building-a-spatial-index-supporting-range-query-using-space-filling-hilbert-curve/