Lez's avatar
Lez
lez@nostr.hu
npub1elta...cume
Inventor of nsite, building tribewiki.org. Biohacker.
Lez's avatar
Lez 0 months ago
Communities are by nature socially centralized. Therefore the right design in my opinion is to have its content bound to pubkeys rather than server addresses. The data can still be redundant if community members take care about archival and hosting. For public communities - like opensource development - this is definitely the way and the data should be widely replicated. This is a key property of #communikeys. My humble opinion about privacy is: if you need personally, generate a new pubkey for the kind of interaction you want to be hiding. View quoted note →
Lez's avatar
Lez 2 months ago
Be here for the fun, not to win. This is how we win.
Lez's avatar
Lez 5 months ago
Végül, megküzdve a technológia hétmilliárd fejű sárkányaival, a nostu.be oldalon sikerült a Huszonegy podcast mai Nostr-es adását megosztani. Csekkoljátok, egész jó kis beszélgetés volt, és még nyereményjáték is van benne: Nostr pólót lehet nyerni! View quoted note →
Lez's avatar
Lez 5 months ago
I need a simple JS nostr in-memory event store. Filters should be supported. e.g. events = eventstore.req({kinds: [1,6], authors: [pubkey1, pubkey2]}) window.nostrdb is good, but I want it to work in nodejs. nostrify/NSet is good, but I need it to understand the filter API. There is a test relay, in-memory (dunno the name), but it listens on a port, I don't need that. Any ideas? I am kind of clueless where I should seek such information, but that's a story for another day.