Avatar
freedom dev 𓅦
58b295a1a5f7b8e7d507777acbcbf7691a0b39c768da2695220a89a6da85ca67
Working on freedom tech. For hire.
Replying to Avatar Gigi

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.

Replying to Avatar semisol

https://youtu.be/b2F-DItXtZs

Take this video, replace the 2nd bear bullshitting about MongoDB with 50% of Nostr developers, and replace MongoDB with insert new crap NIP here

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.

Replying to Avatar Colby Serpa

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.

Neither is irssi (it's IRC, yet it supports OMEMO encryption).

OMEMO is an encryption protocol, not a messaging protocol.

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).

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.

Replying to Avatar JeffG

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

https://omemo.top

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/