“All of the core decisions here are solid (pub key identities…”
I agree, except for the bit about public keys as identities.
I think public key identities are a step in the right direction, but there’s still a gap between that and what the ultimate solution is going to wind up being.
We need to have some layer of indirection between user identities and public keys so that users can do things like rotate keys, have multiple keys, and recover their identities.
I don’t know what the right solution to that is; I think it’s an open problem and probably one of the most important ones to solve. Keybase probably came closest to a good solution, but it wasn’t decentralized.
I was reading about algorand rekeying today, as well as DIDs and atproto/bluesky.
Both seem to use a “signed rotation” approach. Algorand keeps your public key stable while adding metadata that your spend key has changed and links the two. Atproto similarly uses the recovery key to sign a rotation op which can regenerate your signing key, additionally readjusting the tree to preattack state (by setting prev of the rotation to the last precompromise state).
This seems like an improvement of some kind, but still leaves gaps for lost keys. Keybase style approach, or multisig social recovery may also help.
Until Algorand can remove the CGO requirements and libc JS dependencies then I hope it won't ever be considered for something like this. Let's not also forget about their terrible management.
I wasn’t suggesting either of the technologies wholesale. The “signed rotation” commonality seemed interesting, with subtle differences. I’m curious to see where DIDs go, I’ve seen those crop up a few places.
UCAN also seems interesting, JWT with extra steps and attenuation. But orthogonal to this issue for the most part.
Is there a way to do what you're suggesting with identities? I don't think there is. How are you going to rotate keys without a master key?
And even if you're ok with the master key, the only way to solve this without centralized providers is with blockchains. A blockchain for rotating keys doesn't make sense.
But I do want to know if you're ok with a master key and subkeys that can be rotated.
“Is there a way to do what you're suggesting with identities”
There are certainly solutions, but I don’t know what the best solution is, hence why I called it an open problem.
An example solution would be something like having your identity be a hash of your initial public keyset, making each key have a set expiration date, adding new keys by signing them with one of the existing keys, and then storing all of the rotation operations in a transparency log.
“the only way to solve this without centralized providers is with blockchains”
That’s not true; you probably want a transparency log, but that doesn’t require blockchains.
How can you rotate that? No one knows the second key is related to the first. You still need to publish your second key somewhere along with an invalidation certificate for the first key.
Rotate keys: old key signs an event indicating that it is being rolled into a new key.
Multiple keys: nothing to change. Works like that now.
Recover your identity: Well, if you want a well-known identity use NIP-05/NIP-35 and just change your .well-known/nostr.json file to point to your new identity, the one that hasn't been stolen. Hopefully nostr clients of your followers will respect that (who knows what programmers actually will do).
I think these problems are easier than you think they are.
Indeed, ~1000 worldwide had any sort of hepatitis at all, whereas over 400 have died from Covid in the U.S. alone.
Even if their theory is right about isolation being the cause of the hepatitis cases, then it was still the right thing to do in terms of risk vs. reward.
Overall that looks really nice, so thanks for sharing.
A bit of unsolicited feedback; listing the seat post options based on rider height (regular for shorter than 6’3”, and extra long for taller than 6’3”) is wrong.
Seat post height is based on how long your legs are, not how tall you are. If anything, you should list that by inseam.
As it is, I would have no idea which option is the most appropriate.
1. dura runs as a daemon while git-sync-changes is a one shot execution.
2. dura saves locally, while git-sync-changes syncs with a remote repo.
3. dura only does the save and the restore is manual, whereas git-sync-changes does both steps automatically.
I’m glad to see more people exploring this space. I think there’s a lot of untapped potential in tracking pending changes similarly to how we track committed changes.
I wrote it because I wanted to have a complete snapshot of a build context. Sometimes composer or npm can't be relied upon to reproduce dependencies in the state they used to be, or I just want a cache of artifacts. It has been pretty handy.
State law claims are tried in federal courts all the time under subject matter jurisdiction and joinder rules. Both state and federal claims are probably at issue here. PACER would yield the answer.
I agree, except for the bit about public keys as identities.
I think public key identities are a step in the right direction, but there’s still a gap between that and what the ultimate solution is going to wind up being.
We need to have some layer of indirection between user identities and public keys so that users can do things like rotate keys, have multiple keys, and recover their identities.
I don’t know what the right solution to that is; I think it’s an open problem and probably one of the most important ones to solve. Keybase probably came closest to a good solution, but it wasn’t decentralized.