Replies (41)
These invoices I’m posting not getting a lot of attention. lnbc32500210n1p5jq9whpp53fxklm3cy99xvpnasg3t0836y7vvfy2ejxfjktpzrtlnyf3rljlsdqqcqzzsxqyz5vqsp595kgdc8gk6r63h9ge3dc9ugd4322y6qm7ccu87g5krqdhwkx377s9qxpqysgqpqempx7e33e04r34523j0jw3dn6hqhff6a02elgme4q9jfe50smx73v5dt6qj83ja8gj9q45h4jefxuwf8kr25ul4066u4edjd2urqcq8ngxld 😭
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/higherDoes this only work with free public relays?
yeah, but giftwraps have the same issue
The only other solution I’ve found is sending micro ecash with every note which I talk about here naddr1qvzqqqr4gupzpkscaxrqqs8nhaynsahuz6c6jy4wtfhkl2x4zkwrmc4cyvaqmxz3qq2nq735d92hwj2wg3xrxdp5x44y7apexaxnvn96qwa
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.
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.
ip de-anon is also not that reliable. people who fear monger IP leakages are usually just trying to sell you VPN services.
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.
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.
probably should just broadcast these over tor then
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.
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
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?
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
Without built in tor Nostr usage is pretty dangerous for your identity.
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.
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.
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.
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.
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.
I built a working version of damus in a weekend, its not complicated
and this was before vibe coding
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.
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?
Nowadays a working version would never get built
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.
I'm not talking about Damus getting complicated, I'm talking about nostr getting complicated.
You're also a phenom 🤣
But yes, NIP overload is a real thing. Few are needed.
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
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
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.
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.
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
What do you do with @alby ?
Any tips or tutorials you could share for us ignorant types haha
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.
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.
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.
Just worth setting up alby so you don’t have to paste your private key into every client
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.
