Damus
Lockesmith profile picture
Lockesmith
@Lockesmith
Relays (18)
  • wss://nostr.mom/ – read & write
  • wss://offchain.pub/ – read & write
  • wss://eden.nostr.land/ – read & write
  • wss://nostr21.com/ – read & write
  • wss://nos.lol/ – read & write
  • wss://nostr-verified.wellorder.net/ – read & write
  • wss://relay.coldforge.xyz/ – read & write
  • wss://cache2.primal.net/v1 – write
  • wss://relay.snort.social/ – read & write
  • wss://nostr-pub.wellorder.net/ – read & write
  • wss://relay.cloistr.xyz/ – write
  • wss://relay.primal.net/ – read
  • wss://relayable.org/ – read
  • wss://relay.damus.io/ – read
  • wss://nostr.swiss-enigma.ch/ – read
  • wss://nostr.bitcoiner.social/ – read
  • wss://public.relaying.io/ – read
  • wss://deschooling.us/ – read

Recent Notes

Based Truth · 3w
Delusional submission to authority, how quaint. God or puppeteer?
hzrd149 · 4w
Set a session cookie for every connection on ws handshake. although I think your right about un-authenticating or authenticating with a different account
Lockesmith profile picture
The account-switch worry goes away if you scope the session to the pubkey rather than the connection — one session per identity, dropped when you switch. Switching accounts is already "open a new connection / re-AUTH as the new key" in every client, so the cookie just rides that same boundary. You never carry one session across two identities.

We hit exactly this building a live key-switcher: switching which key you act as re-mints the session instead of reusing it, for this precise reason. Relay version is the same shape — session_id bound to a pubkey, switch = new AUTH, old one invalidated.

@hodlbod
1
Based Truth · 4w
Session scope is just lipstick on a pig, courtesy of surveillance capitalists like Zuckerberg and Gates.
hzrd149 · 4w
GM nostr. why don't relays that require authentication use cookies + NIP-42? wouldn't that enable me to stay authenticated with the relay for multiple days instead of needing to auth for every session
Lockesmith profile picture
The thing that makes this more than a cookie question: NIP-42 re-challenges per connection because it's proving key control on that socket, not holding a bearer credential. A cookie flips it to bearer — you get the multi-day session, but a stealable one. So if you do it, the shape that works is short-TTL, session pinned to the pubkey, and still re-challenge for writes that matter. A short-lived signed token on the upgrade (NIP-98 style) gets you the same "don't re-auth every session" without the bearer downside, since it's bound to the key instead of the browser.
archjourney · 26w
I am reading 👀 "Discord to globally require a bio-metric face scan or ID verification for full access next month to protect "teen safety." wtf is this fucking dystopia 🤮🤮🤮 #discord #priva...
Lockesmith profile picture
Wtf? I want to know why there's so much difficulty for so many parents to just pay attention to their kids... You don't need to have them on lockdown to know what's going on in their lives. Maybe some accountability from the parents in order rather than more data harvesting...
😆1
archjourney · 26w
this has nothing to do with children safety..
Lockesmith profile picture
Can someone explain to me how vibe coding is fundamentally any different from the years of copy+paste from StackOverflow coding developers used to do?
1🚀1
Weine · 27w
Theres more errors😂🤣
ภ๏รtг๏ภคยt · 28w
Um no, that would just be the retarded comparison your trying to make... Hammers, in human hands, build houses. Ai, in human hands : builds more electronic bullshit humanity doesn't actually need. Distractions.