Yes, the architecture of apps is very wtf as a practical matter.
Remember that a fake twitter demo was the first client, and it became the "current thing". No logic or reason behind it, and no attempt to be better at any particular thing, just a mindless protest at centralized platforms.
Did you know that every DM you send is making your key weaker too? Most clients are still using NIP04 and now those keys are compromised if users sent a lot of DMs.
Reality has started to set in with at least a small contingent of devs that usability and scale must be considered. This hard work will likely lead to nostr winter in my estimation, as the sugar rush of useless clients fades.
Nostr's real potential is in the projects you haven't heard of yet, contribute to those and tooling.
Did you know that every DM you send is making your key weaker too? Most clients are still using NIP04 and now those keys are compromised if users sent a lot of DMs.
Remember that a fake twitter demo was the first client, and it became the "current thing". No logic or reason behind it, and no attempt to be better at any particular thing, just a mindless protest at centralized platforms.
I think that's very important use case and apps like Damus are focusing and trying to improve it.
Maybe eventually, but it's important to remember it was a proof of concept and that things like Damus not only put the cart before the horse but then whipped it to death.
It's a pattern of behavior with these attention seeking devs who have a history of doing stupid and unsustainable things and then whining about it "bankrupting me". The Jack bailout is the worst thing that has happened to nostr yet.
Now as evidenced per the OP, Nostr is being judged on the usability because of this.
Did you know that every DM you send is making your key weaker too? Most clients are still using NIP04 and now those keys are compromised if users sent a lot of DMs.
You are right kind:4 messages suffer a crypto problem, this sucks, but to be precise and fair, this impacts "only" the DMs itself, not the full key; the theoretical risk is to leak the previous conversations.
When the new protocol (NIP-44) is in place, clients will adopt it, and users will have a new robust private channel with the same key.
Note: I am not an expert in cryptography by any means, I am just following the discussion.
we're extremely early with nostr.. like bitcoin in 2010..
it can be frustating because our mindset is still attached to centralized platforms that can manage these issues easily..
it will take time for the real potential of nostr to flourish
I think the entire structure of Nostr is not ideal. Someone made a post this February opposing Nostr and I commented on it with some ideas and concerns, you can see my response here: #132080
Some other user also gave some pretty cool ideas: #132079
I don't think the problem with Nostr is about the clients, it's about the protocol itself, and unfortunately there isn't enough discourse around this, from what I've seen. Tbf I have been away from the space for a while, so things may have changed in the meantime.
The whole thread I linked is pretty interesting, it might be cool to give it a read to get some perspective on Nostr and its capabilities (or lack thereof)
Lots of good advice here. Hope you find this useful.
Go to NostrSync.live and backup/rebroadcast all of your notes. That should fix a lot of what you’re seeing. Then give some thought to how nostr works and adjust your relays accordingly.
0: metadata: the content is set to a stringified JSON object {name: <username>, about: <string>, picture: <url, string>} describing the user who created the event. A relay may delete older events once it gets a new one for the same pubkey.
Normally every client should check if you have published a newer event with this kind and tries to look for it on a certain relay. This is where the pain begins...because every client has maybe integrated some caching and/or other logic to request & check that info...
Maybe now you've deleted the relay where your DM live...when using Snort I expect to use the Snort relay as one of your defaults.
Use your frustration to master Nostr, I know you can ;-)
Al the sense, logic and other smart things are be found in the clients. @kieran is the builder of Snort, he knows the answer
Case is it’s all very complicated like many other topics within Nostr as wel. But I’m still a big fan… Nostr is a quite simple protocol, the problem is of all different implementations of the NIPs in the apps. And then you have suddenly unexpected behaviour in clients…
Dm's on damus are pretty smooth, I'm using Primal/Damus mostly. Nostrudel is pretty feature rich. I'm sure these issues will get ironed out eventually, we're still early.
This is why every other attempt uses either a blockchain for user profiles (Farcaster uses Ethereum, Lens uses Polygon) or a centralized server (Bluesky). This is a difficult problem.
Regarding profile changes, Nosta should do the trick, as it uses the Blastr relay to send your profile info to all known relays. My to-do list also includes detection of outdated info and helping users fix that.
Note that it's my project so I am biased, and I try to make it specifically about profile creation, editing, and display (and stay away from all feeds and messaging). Do one thing, and do it well (which is already tricky enough).
0, see NIP-01: https://github.com/nostr-protocol/nips/blob/master/01.md#kinds0: metadata: the content is set to a stringified JSON object {name: <username>, about: <string>, picture: <url, string>} describing the user who created the event. A relay may delete older events once it gets a new one for the same pubkey.