Nostr Web Client

this spec i made didn't get a lot of attention, but i think its pretty cool:

https://github.com/nostr-protocol/nips/pull/1893

Private Note Storage is like giftwraps but:

- Not spammable, author keys are pseudonoymous and deterministic from your main key.

- Simpler wrapping. No seal is needed since the wrap key is deterministic. You just have the wrap and the internal rumor.

- Only for your own notes

- Zero public metadata tied to you. Giftwraps require a p tag of who is receiving the event. Since we are deterministically generating the private author key that is not tied to the master key, we can just query on that.

Further improvements not defined in this spec:

- HD keys (bech32) for creating private notes on new keys each time. No pubkey re-use for different private notes.

Imagine having an HD keypath that stores a specific type of private note. There would be zero identifiable information on the public note. no p tags, just a random looking pubkey associated with a specific HD key path.

I'm looking into this for storing private ai convos.

Reply to this note

Please Login to reply.

Discussion

_ 1mo ago

These invoices I’m posting not getting a lot of attention. lnbc32500210n1p5jq9whpp53fxklm3cy99xvpnasg3t0836y7vvfy2ejxfjktpzrtlnyf3rljlsdqqcqzzsxqyz5vqsp595kgdc8gk6r63h9ge3dc9ugd4322y6qm7ccu87g5krqdhwkx377s9qxpqysgqpqempx7e33e04r34523j0jw3dn6hqhff6a02elgme4q9jfe50smx73v5dt6qj83ja8gj9q45h4jefxuwf8kr25ul4066u4edjd2urqcq8ngxld 😭

il_lost_ 1mo ago

Similar NIP

nip4e: decoupling encryption from identity

https://github.com/nostr-protocol/nips/pull/1647

for your proposal is like something similar to higher relay? nostr:npub1aljazgxlpnpfp7n5sunlk3dvfp72456x6nezjw4sd850q879rxqsthg9jp nostr:npub18pudjhdhhp2v8gxnkttt00um729nv93tuepjda2jrwn3eua5tf5s80a699 https://github.com/bitkarrot/higher

Dustin Dannenhauer 1mo ago

Does this only work with free public relays?

jb55 1mo ago

yeah, but giftwraps have the same issue

Dustin Dannenhauer 1mo ago

The only other solution I’ve found is sending micro ecash with every note which I talk about here naddr1qvzqqqr4gupzpkscaxrqqs8nhaynsahuz6c6jy4wtfhkl2x4zkwrmc4cyvaqmxz3qq2nq735d92hwj2wg3xrxdp5x44y7apexaxnvn96qwa

JOE2o 1mo ago

Or just don't gift-wrap. Your IP address is going to be exposed anyway. Just expose the metadata. It's needed.

Even for NIP17 groups, you have all the drawbacks from giftwrapping, but for what gain? A relay operator or a snooping AI can easily correlate who is talking to who, unless everyone in the group has impeccable NIP17 relay separation hygiene, and we know from nostr experience that most people have pretty terrible relay hygiene.

Instead just expose the metadata and focus on making metadata exposure *mean less*, mostly by making nsecs more disposable and easier to juggle multiple of.

Nostr works when it's simple. When you complicate nostr you almost always end up in a situation where something else that already exists is a far better tool for the job than nostr.

jb55 1mo ago

i think its quite different to have stuff at rest in public that is linked to you vs transient request linkage. the former is way worse. so no "just expose the metadata" is not a good idea.

jb55 1mo ago

ip de-anon is also not that reliable. people who fear monger IP leakages are usually just trying to sell you VPN services.

JOE2o 1mo ago

IP de-anon is pretty darn reliable for a malicious nostr relay operator. And only one of your relays needs to have that malicious operator. Or not even malicious, just a normal relay operator with lazy security. And with outbox, it's a relay explosion.

The wider point though is that nostr always fails when you pass a certain complexity threshold.

Keep it simple. If you don't want stuff linked to you via event parsing then just don't publish it, or publish it from an nsec that isn't known to be associated with you. Let clients better support multiple nsecs. Always gotta keep it simple.

Nsecs should be seen as far more disposable anyway.

JOE2o 1mo ago

By de-anon I mean you publish something gift-wrapped so it’s not supposed to be known to be from you, but the malicious relay operator sees that the event came from the same IP as your public nsec.

jb55 1mo ago

probably should just broadcast these over tor then

JOE2o 1mo ago

tor is also way too much.

nostr has to be simple. no tor, no giftwraps. no MLS, no FROST, no MCP DVM ABCDEFG.

all of it, just way way too complicated. stick to the OG nostr stuff plus outbox and done.

jb55 1mo ago

i agree giftwraps are a bit complicated, which is why i'm adding support for it in nostrdb. much easier to work with. the database processess them like regular events

weev 1mo ago

Tor support doesn't require any user knowledge that they’re using Tor. It’s not complicated at all. I’m torifying my Nostr client right now. It doesn’t support Tor, but it can use it anyways.

Tor is just a network transport layer. Saying “Tor is also way too much” is like saying “IP is way too much”. It is super simple for clients to support Tor hidden service relays, every language out there has a SOCKS5 library, and that would add a huge amount of resiliency against state censorship and attacks from private individuals. Nostr hasn’t attracted enough users to be subject to these kinds of pressures yet. If it does, without supporting Tor relays, relay operators will be subject to constant takedown demands and law enforcement requests from European and MENA states because they will see putting pressure on the relays as a way to remove content they dislike.

JOE2o 1mo ago

Nostr hasn't attracted enough users because it's way too complicated.

I can't even begin to express how far nostr is over the complication threshold that prevents general adoption. That threshold is so far in the rearview mirror you can't even see it anymore.

A socks5 proxy is a simple feature, sure, of course. BUT integrating it reliably, securely, and maintaining it across a diverse ecosystem of clients and relays is a massive complexity cost. That's the issue.

I dunno, nostr has totally lost its simple beginnings. It's all bolting on this, and strapping on that, and glueing on this and duct-taping on that.

And the user numbers reflect that. This is not what people want.

jb55 1mo ago

have you tried to implement a client for any other protocol? nostr is not complicated.

just because a few devs went crazy with nips doesn’t mean you have to implement them.

JOE2o 1mo ago

nostr is not complicated, are you kidding me? the devs that went crazy (which is like most devs pretty much), they didn't go crazy outside of nostr, in some sandbox, they did it inside, so you can't just pretend the result of all that craziness is some kind of optional add on. It's air pollution, it's everywhere, you can't not breath it in.

jb55 1mo ago 💬 1

I built a working version of damus in a weekend, its not complicated

jb55 1mo ago

and this was before vibe coding

hodlbod 1mo ago

Nowadays a working version would never get built

JOE2o 1mo ago

compare that weekend to now is what I'm saying. I'll bet that was before 32 baskin robbins of relays, and bunkers, and giftwraps, and MLS, and Cashu, and DVMs and double ratchets, and caching servers, and I don't know what else. bluetooth?

jb55 1mo ago

Everything you listed can be ignored. None of the things you have listed is in damus for example. You pick the level of complexity you want to expose yourself to.

JOE2o 1mo ago

I'm not talking about Damus getting complicated, I'm talking about nostr getting complicated.

jb55 1mo ago

nostr will become infinitely complicated, its designed to be extended. people can and should ignore most of it because its things that are likely not useful to their specific use case

CappyNate🍁 1mo ago

You're also a phenom 🤣

But yes, NIP overload is a real thing. Few are needed.

weev 1mo ago

from the perspective of users it is extremely complicated. I understand that from the perspective of a competent developer it is not complicated, but ideally from the perspective of users it should function relatively equivalently to the very earliest Twitter clients and interface. Extremely minimal and simple. And everything should just work. If the average hears that there are different protocol formats for DMs, you have completely lost the plot and the game

Mihai Kirschner Dunareanu 1mo ago

I run my own relay. Boost::beast with a nostr module written in about 1 week of discovering nostr, only nip1 initially. I still run it and its been loads of fun.

JOE2o 1mo ago

that's good. but this wider nostr you're participating in, it's gotten crazy complex. "nostr is what you make of it" is a cop out. nostr is a thing in and of itself, and that thing in and of itself has ubercomplexificated out of control.

Mihai Kirschner Dunareanu 1mo ago

perhaps you have more experience than me here, but it seems to be a really simple system for sending messages which happen to have a type. this means that other client can add significance to those types.

For example, if I wanted to offer my small and medium clients an interactive platform for communication, I would certainly build on nostr. Why not? It's practically build.

JOE2o 1mo ago

For sure, a contained nostr deployment is a very good idea, like for a company.

Nostr in the wild though is scary, you've probably not ventured far out there yet. You mentioned sending messages. How about *direct* messages? There are like 12 different DM specs on Nostr. You right now have no idea how to DM me. If you send me a NIP-04 DM will it work? Maybe you should try a NIP-17 DM also, just to be safe. Or maybe try me on Keychat? Or maybe MLS on White Noise, I could be on that. Or Maybe double ratchet on IRIS. Try them all and maybe, just maybe, I'll get your DM.

weev 1mo ago

Yes, the refusal to create a good standard and agree to it, and the number of app developers who insist on an old dysfunctional NIP and the need for backwards compatibility creating massive technical debt.

This needs to be like cryptographic standards. People need to be able to agree that there is a specific way a feature is going to be done on Nostr, and that any clients which refuse to adhere to the standard and come up with a timeline for the phasing out of the support of the old standards need to be delisted from places like nostr.com/net/org/how — this shit is fucking atrocious for new users. 90% of the people I try to get on Nostr get confused and quit. Normal people do not need to be hearing the phrase “NIP” unless it is a slur against the Japanese.

Mihai Kirschner Dunareanu 1mo ago

truth be told, I am also unclear if I need to implement anything on my relay to support DMs, my understanding at this point is that I do not.

Chris Liss 1mo ago 💬 1

I suck at tech and nostr is pretty easy for me. Struggled with nostr:npub1getal6ykt05fsz5nqu4uld09nfj3y3qxmv8crys4aeut53unfvlqr80nfm at first, but once you get it, it’s a game changer.

TheBitcoinManual 1mo ago

Welcome aboard, the learning curve is sharp but once you get the hang of it you'll look at trad social media as stuck in the past

BitcoinTradie 1mo ago

What do you do with @alby ?

Luke 1mo ago

Any tips or tutorials you could share for us ignorant types haha

Chris Liss 1mo ago

Just worth setting up alby so you don’t have to paste your private key into every client

ede3d957... 1mo ago

Without built in tor Nostr usage is pretty dangerous for your identity.

JOE2o 1mo ago

tor is too complicated for nostr. nostr had to be almost ridiculously simple to not bug out, and to scale. if you're using nostr for anything to do with IP privacy (or any privacy really), you're in the wrong protocol.

b0b 1mo ago

interesting for storing private bookmarks too. with the hd approach it would be easier to manage your own key pairs too. the user wouldn't have to keep track of a load of different pub keys.

are the notes still safe if the one private key was compromised?

jb55 1mo ago

if the private key is compromised, you still need the users two factor combined with the app salt to even know if they have private notes stored on the network