Forest @forestjohnson@pixie.town

@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/

@jamiem @notplants @mayfirst

I'm blocking the ui thread until I know whether the email was accepted or rejected. So I can't just wait 30 seconds for a bounce notif and then assume success. No one would use this site if you have to wait 30s every time you log in

@jamiem @notplants @mayfirst

I had considered that option, but I decided against it because I want to be able to tell the difference between time out and a success.

@drahardja get in the Eva shingy