Keep nostr wired 🫡

Downstr?

I can’t believe it’s been ten years since Daft Punk dropped Random Access Memories! Great album!

Ps>return ($silence -eq $violence)

$false

Not legally the same. One is an attack on a concept, the decentralized protocol, the other is on an asset owned by an individual (or org). The CFAA prohibits unauthorized access to an individual’s or company’s computers or systems. Blockchain / protocol vulnerabilities can be exploited without the unauthorized access

I find that if you have little to no exposure to mainstream/social media, these cultural trends barely exist in real life. Everyone fit continues being fit. Same for unfit

I totally disagree 😉

Yes, when you “hack” someone else’s server you are performing “unauthorized access”. Not so with a contract or protocol weakness that can be exploited by, say, submitting (malformed?) transactions to your own node, so you never did any unauthorized access. That’s the difference

ICANN/Verisign Proposal Would Allow Any Government To Seize Domain Names

https://m.slashdot.org/story/413388

https://m.slashdot.org/story/413388

Use protobufs from grpc

Real Bitcoin/nostr devs can explain bech32 address encoding

That’s what the human readable part (HRP) of a bech32 address is for!

Almost like the IRS new they’d need more agents to focus more on the earned income from us working stiffs

Apparently Satoshi’s work of art is fine to dump on our storage without permission but U2’s work of art is not?!?!

Yeah that checks out

I’m trying to build a powershell client which might help. Focus right now is porting a reference bech32 library to powershell

This is why I proposed a “burn notice” event to @nostr.build. Anyone with the private key for an npub should be able to issue a “burn notice” event that includes a reason, say “key_compromise” or “migration”. If nostr / npub+nsec will be used for authentication, then key revocations must be made possible. In bring-your-own identity models, the user is the credential issuer (not a centralized identity provider) so the user (or private key holders) should be able to notify the nostr network (via the nostr signed event) that the key should not be used or treated with extra care. Nostr clients could warn appropriately for interactions with burnt nbups and websites using auth like described above could also handle appropriately.

With proper client handling decisions around burn notices, it could be made only attractive to the real user to issue a burn notice, and disadvantageous for an attacker with the private key to burn it intentionally.

For example, the burn notice event should include a hint to the new npub but clients should be careful about allowing interaction with new npub. NIP-05 verification could enable smooth transition to the new npub since control of the dns domain is demonstrated in addition to having the private key. Attackers would also need to gain control of the nip05 domain to abuse burn notices in their favor.

Also, npub / nostr authentication to websites should add TOTP codes (not passwords!) on top for mfa

🎶Tide is high but I’m hodling on

🎶there’s only gonna be twenty one

🎶million

🎶million

Right now it’s adhoc “hey, here’s my new npub, everybody”

For self-reporting key compromises and publishing what your new npub is