fiatjaf's avatar
fiatjaf
_@fiatjaf.com
npub180cv...h6w6
~
fiatjaf's avatar
fiatjaf 3 days ago
The latest nak v0.17.4 implements support for managing decoupled encryption keys that fix NIP-17 completely, as per See this amazing infographic that explains how it works: image If you call `nak dekey --sec <whatever>` you'll generate a new decoupled encryption key that is stored locally and announced with a kind:10044 event. After that if you use `nak gift wrap` or `nak gift unwrap` that key will be used by default (when wrapping both keys will be tried if possible). If you run `nak dekey` on another device/client (or with another --config-path) that other device will announce itself as in need of the decoupled key, then you can run `nak dekey` again on the first device and it will automatically send the key to the second -- and like that the key is shared among all your devices. Call `nak dekey --rotate` to discard the current decoupled key and generate and announce a new one. Download here:
fiatjaf's avatar
fiatjaf 3 days ago
Good features of this: - Calls /git-upload-pack on servers in arbitrary ways to get trees and blobs directly and dynamically - Once we find a git server that works we don't have to keep trying others - Syntax highlighting grammars loaded on demand - Binary blobs can be displayed as hex or readable ascii - Images, videos etc are displayed when possible - Buttons for downloading files directly - Prioritizes specific user pages and specific repositories, not trying to do everything View quoted note →
fiatjaf's avatar
fiatjaf 5 days ago
Real Nostr clients don't require any servers, they can work completely on the client side. The fact that we have apps that still work perfectly well but are now inaccessible because a domain name has expired (or whatever) is some bullshit we inherited from the "web" world that we should try to circumvent, not embrace. There are multiple ways to circumvent these flaws and build true Nostr clients that can't be controlled by anyone, not even by their original author. View quoted note →
fiatjaf's avatar
fiatjaf 1 week ago
SQRL invented the anti-phishing public key cryptography based approach to website authentication many years ago. It was a beautiful spec of one page with multiple grassroots implementations. Then they decided that the simple "I sign something with a key" approach wasn't good enough, they also had to cover a bazillion other key management things in the protocol so they brought a team of academics that turned the thing into a 300-page unreadable spec that no one ever implemented fully. LNURL-auth basically reinvented the original simple SQRL version in 2019 and got many implementations and some traction within the bitcoiner realm. But at the same time another team of academics probably by paid by some evil people were creating Webauthn, i.e. "passkeys", which solves the exact same problem and works in the exact same way, although this time the spec is much bigger than even the worst version of SQRL and apparently designed to create centralization. It took them at least 6 years to get browsers and phones and some websites to start adopting this behemoth, but so far there are no answers to what is their real purpose or to the question: "what if I lose my phone?".
fiatjaf's avatar
fiatjaf 1 week ago
Added a "spell" command to - `nak req -k 777 -a verbiricha@habla.news --outbox | jq` to see all @verbiricha spells - pick one and run `nak req -i c1214b196b3664bc7fc8c8dfaa082a24ed09b25028773bcae60fef8dfe6646fa -a verbiricha@habla.news --outbox | nak spell --pub fiatjaf.com` to run it in the context of your user (replace 'fiatjaf.com' with your npub or nip05) - `nak spell` will list your previously used spells with ids that you can use to invoke them again: `nak spell spellcgk4u9c --pub fiatjaf.com` It's not super useful, but it is something. View quoted note →