Relay would run through all pubkeys and check if they are inside the bloom filter to get the set of keys I am interested about and then running the usual query. 

 There is not a lot of privacy gains. The relay does know which keys are in the set, with a small error rate (0.01%). So, it doesn't really create a big enough annonimity set.  

 % of all nostr keys. 

But once the client receives the data, it can filter further to the matching IDs. So, you will see the same thing, but there will be X number of posts returned that are not in your follow lists.

i.e. errors consume data but doesn't change your UX 

 Aren't bloom filters faster than string comparisons? Maybe they aren't faster than pre-computed indexes?

Also, I assume relays would pre-compute and store the set of hashes needed for a standard Nostr Bloom filter.  

 Isn't that in the same ballpark of what zip/zlib compressions alredy do? 

The Websocket connection can be compressed using gzip, etc. So, whatever we do needs to offer a significant again when compared to a an already compressed representation of the keys in hex strings.  

 I mean.. isn't that what was supposed to happen? 

 Thank you. Favorites already exist, you just need to use a list client to manage your follows lists, like listr.lol  

 Should threads be included in conversations or should the tabs themselves be removed and display only one feed? 

There are so many replies that adding threads to conversations will almost certainly make new posts invisible or just very hard to find. 

 Or get the Play version with translations. Most of us don't even realize we are talking through a translations.  

 There are two option when you download, the Play and foss. Play uses Google's in device translate. Foss doesn't have it because there are no open source in-device models for translation yet.  

 No, there are too many kind1s to keep track on our server :( 

 Absolutely none of them or just a few?  

 Is your wifi metered? We recently changed this to consider metered wifi as mobile. I wonder if we have a bug somewhere. 🤔 

 Then the anonymity is gone. :)  

 How were nostr devs able to create so many apps?? It doesn't make any sense! How the hell can somebody make apps by just writing text files without any database of AI tools? It must have been aliens.  

 Get YT premium and all ads are gone. I will never go back to free YT.  

 I rarely watch videos on a browser. :( 

 Inbox.nostr.wine auth.nostr1.com and personal relays from relay.tools 

 Mame sure to have public home and public inbox relays setup, otherwise the app doesn't know where to get your posts to send notif.

Also, the nos.lol relay is misspelled on your DM list  

 Harder to sync, right? Because the posts will look anonymous for everybody that doesn't know by xpub 

 Randomly. So every post looks anonymous until you get the person's xpub. It's similar to using a new Bitcoin address for every transaction.  

 It would be the type of thing you give to the people you trust, likely rotating it here and there.  

 We could make a filter by xpub instead of the pubkey :) 

 They can't. That's the point. :) 

 Yeah indexing will be harder, unless the client breaks it down and queries by a set of pubkeys directly. But for that to happen, relays must abandon the filter limits they have today. 

Essentially, they will have to go develop a function in say SQL that assesses if a pubkey is inside the set of an xpub or not. Key derivation is heavy, so maybe there must be a new xpub crypto scheme that makes it easier for indexing.  

 Imagine having several sub feeds per seed by simply exposing followers to separate key derivation paths. You can build your specialized feeds in a folder structure. 
nostr:nevent1qqsq9j74sjxsw5sds30udxjr35udc2j6avj86se5r9gvmrt9kp9mqqqpz3mhxw309akx7cmpd35x7um58g6rsd3e9upzq3svyhng9ld8sv44950j957j9vchdktj7cxumsep9mvvjthc2pjuqvzqqqqqqy56ssds 

 Yep 

 But priv keys will be used only once. There is no need to expose the private keys.  

 yeah no, my suggestion was for regular anonymous posts, not for DMs or identity management. The point was to have a seed that you can expose your xpub to friends and colleagues, but not to the whole web. It can leak, so it is never actually private.  

 It all depends on how much data is needed for each custom feed. It will be hard to make good trending topics work with only local info.

It's similar to translations. In-device translations work really well for simple things/notes but if the text requires advanced knowledge to translate well, online services win.  

 Negentropy / time syncs are not optional, IMHO. We will have to add to the mandatory core of Nostr if we want to scale this. We can't keep downloading everything over and over again just to check if the local instance has all the data it needs. 

I am getting more into DVMs that return a Snark/Stark proof these days. I think it could provide some interesting possibilities for verifiable computation. 

If you have the IDs of the events you want to include locally, you can send the IDs alone for a verifiable DVM to compute and return with a proof that it did what it was supposed to do. 

It gets even better if we can add some homophobic encryption to event data. 

Future is bright.  

 Too bad all of these ZK implementations wasted time in the shitcoin world. They don't need blockchains to offer verifiable computations. 

 yep. People have not understood that using client defaults is not very different than just staying on twitter. 

 ?? why is that? that looks more like a bug than a need to move away from upstream. 

 They just need to do this: https://github.com/retrnull/garnet/issues/2  

 It was passed forward, so technically yes. But it might not have gotten to the final owners yet since there might be layers or layers of corp structures to go through.  

 nice idea! 

 You are supposed to do your research and figure out which relays you want to: 
1. Hold your notes for others to see (Public Outbox/Home)
2. Receive people's reactions to your notes (Public inbox)
3. Receive DMs from everybody (Private DM Inbox)
4. Store your private data, like drafts, app settings, etc (Private Storage). 
5. Locally cache information (Local Relays)
6. Do search for you (Search Relays)
7. Authorize the app to download posts from (General List). 

You can use Nostr without setting them up, but I can guarantee you will be losing your posts, missing DMs, missing Zap notifications, and make your private posts public until you set it up.  

 not yet. 

 feel free to ask more questions. 

Hopefully people start making lots of content for each of these.  

 no need to be the first thing, but at some point you will need to handle it. Self custody has responsibilities. No one will solve this problem for you without selling you and your data for profit. 

 I think it is because we don't reply to the e-tag, but to the a-tag so that when the version changes, the reply stays.  

 I am not complaining...  

 You are possibly right. But who knows... maybe there is a way...  

 The vanity key I want takes 283 years to find in an M2 Max :) 

So, I am looking for options. :)

But yes, https://github.com/grunch/rana 

 I was always scared to implement this and publish the user listining to an XXX video 🥲 

 Amethyst always does the case the user has written in he post and another one in lowercase. 🫢 

 One of the many ideas that never get merged 

 Amethyst has custom feeds based on NIP-51 lists. They show up at the top bar and users can select any other npub list they created for themselves. Now we are also doing NIP51 lists over the Outbox model, so changing the list modifies the relay list that the app is connected to. 

 Go to the Settings/Apps/Amethyst and force close the app. 

 I didn't say delete... :) 

Just stop using telegram to discuss Nostr. It doesn't make any sense. 

We have had NIP-28 for a while and people still used proprietary platforms to discuss Nostr. Let's see if NIP-29 people can start switching over.  

 Agree, but we do have other options of chats, including public ones that Amethyst implements. NIP29 is for those that want moderation by a relay.  

 Thank you! Fixed: https://github.com/vitorpamplona/amethyst/commit/6b193894bd6610f4b88482c44c0598f048c3b286 

 hum.. yeah, I keep wondering if we should add more debug stuff into the App. It's hard because it's not a user feature and it will consume some messages, but maybe I can do an LRU-based cache of the latest messages. Some filters are really massive so keeping copies of large strings in memory is no good. 

Also, FYI, the 7/10 number includes timeout. The 3 relays might have just sent a time out and amethyst will wait a minute before trying to connect again.
 

 We just don't make them in the app yet. :( 

Listr.lol can help you setup lists 

 Would that be self-custodial to them as well or am I in custody of my friend's/family funds?  

 Storing Delete Events for each note when the user wants o delete the whole account is a burden to any relay. My delete events alone are already 5 MBs or so.

On the enforcement side, as a person manages HIPAA-compliant data in Nostr relays, I strongly disagree. Enforcement is just one fuck up away.