Most #nostr clients still suck in terms of discoverability. But they don't have to.
They don't have to because we have all the right building blocks already, we just lack courage to steal. Yes, STEAL. I'd encourage everyone to steal—not copy—what other clients did well. In the spirit of "good artists copy, great artists steal."
Let's take a web-based reddit client for example, one that still works (sometimes) despite all the horrible API changes: https://www.popular.pics/
If you visit that site in your browser, you'll be greeted with something like this:

It's a viewer that supports multiple subreddits by default. You open it, and it just works. It has sensible defaults. (Important!) It defaults to multiple subreddits from the get-go. Subreddits that are visual, i.e. subreddits that have users posting visually pleasing images.
You can change these defaults easily, and the URL will update accordingly. This one is for subreddits concerning #nostr #bitcoin and #memes for example: https://www.popular.pics/reddit/subreddits/posts?r=nostr,bitcoin,memes - easy to share & easy to see what's going on. Steal this. Please.
Of course, if this is a nostr client (and if you're logged in) this should default to your personal web. The people and hashtags you follow; the communities and relays you are part of, etc. Bonus points if you implement an "expand" button which will expand your personal web by one degree, i.e. shows "friend of a friend" kind of stuff. Not only people you follow, but people followed by people you follow. Another click and it's two degrees. You get the idea.
Back to the interface, and the problem at hand: discoverability. As you can see, every image card quite prominently shows the subreddit it was posted the as well as the user who posted it.

Apart from the beautiful masonry layout (did I already mention that you should steal this too?), that's the one thing I like most about this image interface: it's so fucking easy to discover stuff. You click on a subreddit, and boom, you see all images from this subreddit.

You click on a username, and boom, you see all images from this user.

You will discover new subreddits via the "user" view (most users post to multiple subreddits) and you will discover new users via the "subreddit" view (most subreddits have posts from multiple users). You can spend DAYS just clicking through stuff, and we could do the same on nostr with #hashtags (or NIP-72 communities) and usernames (yay, we have those).
Even more, you could go from user to NIP-05 provider, which basically gives a list of users under a single domain. Or you could show what kind of actual lists (NIP-51 lists) the user is part of, so you again have a list of users which you could use as a base for your exploration, populating the grid view which is the base of this image client. And again, because this is nostr, we get a "ghost" mode FOR FREE. You can use someone else's npub and look at things through their eyes. Some clients implement this quite well already. Most people have no idea that this is possible (because we suck at discoverability, including discoverability of features).
Pinstr is ALMOST there, but it takes like ~5 clicks to get to a hashtag (and it doesn't always work for me). Slidestr has potential and is also ALMOST there, but again, it takes like ~3 clicks to get to a profile and open it in Slidestr and you have to know exactly what you're doing, which isn't exactly discoverability-friendly. Same for hashtags, which are even more hidden, as as you have to open an almost invisible menu at the bottom of the image view.
Don't get me wrong, I love what we have. But we shouldn't be afraid to steal what other clients did well in the past, especially stuff that has been around for a long time. To me, the popular pics client is near perfect. No pop-ups. No modals. No unnecessary clicks. Everything makes sense and is in the right place. It doesn't waste space and is beautiful to boot.
I think we're very close to greatness on many fronts, and I hope that—with some technical improvements that are around the corner, as well with some help from #nostrdesign—we can finally kick some ass in the discoverability department too.
Today I saw two presentations of e2ee messages for Nostr (direct and group messages).
None of them based on the industry's standard - OMEMO.
I suggest we steal from mov.im folks their web implementation of OMEMO, no need to reinvent the wheel.
New specification called "Nostr Lite" or some similar name, with the bare minimum to function and none of the bloat.
Nice.
How is this different from porting OMEMO? https://omemo.top
nostr:npub1cldxy9f5shk0kxm90yk8nn3lum7wdmta3m6ndjcjr4aqcuewjt0sx3rps5
Good evening, sir.
Are you still maintaining nostr-relay?
Found a bug - it is not compatible with sqlalchemy anymore.
Is there a better way to reach you?
nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc
nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8
nostr:npub1t89vhkp66hz54kga4n635jwqdc977uc2crnuyddx7maznwfrpupqwra5h9
Reading this thread has been illuminating:
https://old.reddit.com/r/signal/comments/10edi7b/signal_encryption_vs_xmpp_omemo/
To sum it up:
1. OMEMO is essentially Signal's encryption protocol (and it is web, thanks to movim folks).
2. The rest of the Signal protocol is snake oil.
3. Anonymization should be worked on a different layer.
For point three I have a solution in mind that would like to discuss with anyone interested in funding the project.
to me giftwraps are an optional thing that enable more privacy-related features that you can ignore.
This is what I was thinking. People messaging me from Damus and I never knowing.
I'm afraid this would increase centralization, the fragmentation of the network and break compatibility with other clients.
OMEMO is pretty cool. How does OMEMO accomplish syncing between user devices? nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s
According to Straub, OMEMO uses the Double Ratchet Algorithm "to provide multi-end to multi-end encryption, allowing messages to be synchronized securely across multiple clients, even if some of them are offline"
Bold claims. Sounds like exactly what we need… 🤔 
Yes, it is exactly what we need, and it's already been implemented in web clients.
Are there any guides you’re aware of on how to expose a client as an onion service? I’ve been meaning to do so with nostr:npub15dc33fyg3cpd9r58vlqge2hh8dy6hkkrjxkhluv2xpyfreqkmsesesyv6e.
This is for OpenBSD, but still helpful to learn how it works. It's pretty simple.
https://nox.im/posts/2021/0724/hosting-tor-hidden-services-with-vanity-onion-addresses/
Neither is irssi (it's IRC, yet it supports OMEMO encryption).
OMEMO is an encryption protocol, not a messaging protocol.
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
In other words, why reinventing the wheel when OMEMO does everything and has already been implemented on the web?
I can send OMEMO messages between XMPP and IRC.
But that's besides the point. My comment about having one standard was about not having one for DM's and another for group chats, when everyone is using only one (because group chats serves for DM's).
We got nostr:nprofile1qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0qyfhwumn8ghj7ur4wfcxcetsv9njuetn9uqzq9eemymaerqvwdc25f6ctyuvzx0zt3qld3zp5hf5cmfc2qlrzdh0dmngeh 's Double Ratchet DMs incoming. Who is going to code MLS for Group-Ratchet DMs?
Ideally there should only be one standard. It would be especially interesting if it was compatible with other technologies, such as XMPP and IRC.
https://mov.im already has e2ee group chats on the browser.
Why not adding Nostr to this list? https://omemo.top
I could work on it if there was (bare) minimum funding.
https://mov.im already has it and it's opensource.
It would be nice adding Nostr to this list https://omemo.top
What security is lost by using OMEMO exactly?
E2EE DMs are coming to Nostr 🔒
After being nerd sniped by hearing nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 mention OTR for the millionth time on the Bitcoin Review podcast, I spent the last few weeks digging into OTR, the Signal protocol, and a grab-bag of other cryptography.
The end result is that I (am pretty sure at least) that I found a way to do E2EE (end-to-end encrypted) DMs on Nostr in a way that is both forward and post-compromise secure AND doesn't require any centralized servers.
Demo video: https://share.cleanshot.com/nMKk6cn0
Live demo app: https://drdm-demo.vercel.app
And finally, the NIP (for those of you with bikes in need of a shed): https://github.com/nostr-protocol/nips/pull/1206
Huge thanks to nostr:npub1klkk3vrzme455yh9rl2jshq7rc8dpegj3ndf82c3ks2sk40dxt7qulx3vt and nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft for the chats while I worked out the details.
This is amazing.
However, why using anything other than OMEMO? It's already supported by browser clients, like https://mov.im
nevent1qvzqqqqqqypzq9eemymaerqvwdc25f6ctyuvzx0zt3qld3zp5hf5cmfc2qlrzdh0qqswlyjp5x62407g5pztyhyhr22skkx53vfz7zx68y6muqvmd5pqr4q4t2px9
nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr
Good morning, sir.
Failure to register protocol handler is breaking the load of the Next version:

Not the case with the Production version.
I believe that it should fail with an error, but not break the entire app.
I found this error trying to access the Next version of noStrudel on Firefox through Tor, which led me to having to configure `dom.securecontext.allowlist_onions: true` to fix it. So, it isn't a total show stopper, but still would be interesting to fix, because who knows what else makes it break besides trying to access on FF through Tor, and it doesn't happen with the Prod version (it fails gracefully).
Cloudflare breaks the outbox model for us, Tor and VPN users. Nobody seems to care.
This is a problem that has more to do with the centralized nature of the internet and its infrastructure, and less with the protocol.
I'm trying to create a solution, I got something in the making, but without funding it's almost impossible.
One more, this maintained by me, and not very powerful yet, but still an option:
ws://pzfw4uteha62iwkzm3lycabk4pbtcr67cg5ymp5i3xwrpt3t24m6tzad.onion:81
It is maintained by unix enthusiasts and they offer many free services: https://envs.net/
New onion address for the "Next" version of Nostrudel (next.nostrudel.ninja) for access through the Tor network:
http://pzfw4uteha62iwkzm3lycabk4pbtcr67cg5ymp5i3xwrpt3t24m6tzad.onion
Remember to add at least one onion relay on both inbox and outbox relay configurations, such as
ws://bitcoinr6de5lkvx4tpwdmzrdfdpla5sya2afwpcabjup2xpi5dulbad.onion
Remember that "Next" is never production ready, but a work in progress, therefore it may contain bugs (for example I had to reload it once for it to load my timeline), it's normal.
Looking for the Production version? see:
Once again, shout out to nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr for this fantastic client!
Adding a new onion relay!
ws://pzfw4uteha62iwkzm3lycabk4pbtcr67cg5ymp5i3xwrpt3t24m6tzad.onion:81
nostr:npub1ktt8phjnkfmfrsxrgqpztdjuxk3x6psf80xyray0l3c7pyrln49qhkyhz0
nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9
nostr:npub1f6ugxyxkknket3kkdgu4k0fu74vmshawermkj8d06sz6jts9t4kslazcka
#tor #onion #privacy