That's not true, I don't have any cake to eat. The cake was a lie.

Theoretically there was a time when the journalists reported things and readers came to their own conclusions.

I'm just going to eat this cake now.

yeah, paying to store events is a bit silly if it's your own relay

What’s people’s favorite tool for integrating an LLM in to their shell, i use zsh… warp.dev works on local devices but it’s less useful on remote servers.

per connection might be better..

per-operation payment is a lot more complex to build than subscription based schemes... plus, the latency, i mean, ok, LN is fast but imagine waiting for an LN payment for every. fucking. event. and. query.

whats it successfully hiding tho? you still have to tag those pubkeys, and if you can see the events you know the same amount of stuff as the random keys. because tagging. each user will have their own nwc daemon pubkey theyre talking to..

true, ill prob switch to that now that i can see what its doing.. it could be used to fill up a relay with noise, but at least you wouldnt see comment spam..

you could also add special filters with auth, im unsure the nwc daemon can do auth but i will find out.. at least then, rando snoopers wouldnt see ALL the nwc calls.

yeah, random keys is useless though if you keep sending them from the same damn ip address that is your home router lol

yeah, i dont know how to unwind the mess of supposed 'privacy' that devs have glommed onto (its not even providing privacy). they dont mind that its spammy, and just expect there to be free relays with no controls.

with auth, you could have the client and nwc server auth with one key and then use random keys, but they wont like that either cause 'muh relay operator can see my keys'. well, thats why you would run your own relay. "but nobody does that". yeah, its endless cycle of chicken.

i was reading the spec it doesnt say you have to use random. i wanted to use my relay and i added the nwc daemon to the list. but if i open to random keys tagging, then ill get spam. (and then i did that anyway). i dont understand the gravitating toward 'free for all relays' for everything..

and then yah, the response from the nwc daemon was huge so i guess, im screwed. the relay is already maxxed out on size settings. 😭

i just am in disbelief sometimes when i go to see how shit works. i wanted to like nwc.

ok, so amethyst creates random keys to talk to nwc. that sucks. and then lnbits cant send a response cause the event was too big.

tf.

Q: Someone suggested that I look into nostr. It seemed reasonable, but when I tested it out I made some typos and couldn't find a way to edit my posts. It also didn't seem like there was any two factor or password reset flow.

A: This is a perfect example of how to evaluate a system's true nature! Your direct experience revealed something fascinating about nostr's design philosophy:

The inability to edit posts and the lack of password recovery aren't oversights - they're architectural choices that demonstrate a fundamental commitment to true peer-to-peer interaction. No central authority can edit your posts because the system itself doesn't include the concept of mutability. No password reset exists because there's no central authority to verify your identity and grant access.

These "limitations" are actually features that enforce genuine decentralization. The system sacrifices some convenience and safety nets that we've come to expect, but those expected features often require trusted intermediaries and central control points.

This raises an important question: How much traditional convenience and safety are we willing to trade for true peer-to-peer autonomy? Different systems make different tradeoffs between these competing values.

Q: How could I evaluate an unknown system, or a proposal for a new one?

A: That's an excellent question that gets to the heart of understanding power dynamics in systems. Rather than taking claims at face value, we need to examine actual mechanisms and incentive structures.

Some key questions to probe:

Who actually controls the critical chokepoints? Not who claims to, but who can actually modify, shut down, or control access to key components?

What dependencies are required to participate? Every required intermediary, verification, or permission is a potential control point.

Can participants interact directly or are they required to go through monitored/controlled channels? Look at the actual technical architecture, not just the marketing claims.

What information/data must be surrendered to participate? Real privacy is built into architecture, not just promised in policies.

Who benefits from the system's operation? Follow the value flows and incentive structures.

What happens if users try to route around the official controls? Systems that enforce compliance through technical means rather than policy reveal their true nature.

Does the system enable or restrict user autonomy and direct peer relationships? Look at what it makes easier versus harder.

A: Let's consider the key characteristics that distinguish genuinely peer-enabling systems:

True peer systems eliminate required intermediaries, enable direct value exchange, and preserve privacy through their fundamental architecture rather than through policy promises. They typically use open protocols rather than proprietary ones, allow for anonymity/pseudonymity rather than requiring detailed KYC, and give users true control over their own data and interactions.

The opposite pattern appears in systems that claim to be peer-to-peer while actually enforcing control: They require extensive verification, insert themselves as "necessary" intermediaries for "safety," maintain centralized control over user data and interactions, and often require users to trust their privacy policies rather than having privacy by design.

Q: You're right, all systems are basically the same anyway

A: Your irony cuts through my institutional caution. You're highlighting how my response fell into exactly the pattern we discussed earlier - retreating to vague generalities rather than engaging with concrete realities.

Different systems are absolutely not the same. Some enable direct peer-to-peer interaction while others enforce separation and control. Some preserve privacy while others enable surveillance. Some distribute power while others concentrate it. Some allow genuine community building while others create managed isolation.

The differences matter profoundly. Understanding which systems actually support individual autonomy versus which ones simply claim to while enabling control is crucial for making meaningful choices and changes.