When will it be available?
nostr:nprofile1qqsxg45ph8gx0vdrvtzta6xal7v86frx6jvstsnvhrlvtehmwwh4epqpzemhxue69uhhyetvv9ujuvrcvd5xzapwvdhk6qghwaehxw309aex2mrp0yh8x6tpd4ehgu3wvdhk6qg5waehxw309aex2mrp0yhxgctdw4eju6t04vkzjx's Push client keeps the websocket connection to your inbox relays always runming, displays the notifications and then redirects to your favorite Nostr Client when you click on it. 
Discussion
It all depends on how many sats he gets :)
Partialy unrelated, but are you accepting sats to fix the "Don't send non-chat related events to DM relays" or the "don't spam Outbox relays with 10002 events so hard once a day" problems? Sorry for keep bringing this up continuously but my Amethyst / Haven experience has been a pain lately.
Yeah, I still need to see how that non-DM message is getting there.
But the 10002 are supposed to be everywhere, in all relays the app has access to. That is written in the NIP. It's really important to find up-to-date 10002 events for any key as fast as possible.
nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqppemhxue69uhkummn9ekx7mp0qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qyghwumn8ghj7mn0wd68ytnhd9hx2tch2deau - I'm pretty sure that there's a bug regarding kind 10002 as well. Try adding Citrine to your Outbox and keep it there a couple of days. Check the event count for kind 10002. I'm using several other NIP-65 eenabled Nostr clients and none of them are writing 10002 events to my Outbox at the same tate as Amethyst. It's bad enough that even with a configuration of 100+ request per seconds I'm getting rate limited on my own Haven personal relay.
Is your Outbox accepting 10002 events and saving them or just rejecting them all the time?
We have an auto-update tool that if a relay sends an event that is older than what the app has, the app replies with the newer event. If the relay does not accept the newer event but still has the old one, the app will continuing blasting the relay until it updates it because having outdated info is terrible for these types of events.
nostr:nprofile1qqsw9n8heusyq0el9f99tveg7r0rhcu9tznatuekxt764m78ymqu36cpz4mhxue69uhhyetvv9ujuat50phjummwv5hszymhwden5te0wahhgtn4w3ux7tn0dejj7qg4waehxw309an8yetwwvh82arcduhx7mn99uuwx66a, any chance that Haven Outbox is rejecting kind 10002 events (other tha. Due to rate limiting)? I don't see anything obvious in the code.
FYI, this is true for any replaceable event. If the relay sends an outdated event, the app will immediately send a new version if the app has one.
For relays, the recommendation is to either always accept replaceable event updates, even if people are not paying anymore, OR delete old versions from your database.
this is one of the "directory" event kinds that i talk about, events that should be broadcast everywhere, because they provide information about the addresses of things that need to be accessible everywhere
they are small compared to follow lists, i think the proper relay behaviour is to accept them if it has old copies also
Some of them are massive (20+) relays because some clients just import everything from kind3 automatically. We need to find a way to discourage that.
turning these lists into CRDTs is key to cutting down this... follows, relay lists, mailboxes, all of them could be add/subtract ops one per time
i forget the nip number, maybe 87? there is some proposal for this that applies this and extends the capability of lists but i'm not sure if relays have been added to that
Vitor. Got it. Quick quesiton, event kind 10002 is signed by my own key when using Amethyst right? (Just checking as currently Haven only accepts events signed by the Outbox's relay owner). In my case 10002 is the only spammy event. I don't think that neither Citrine nor Haven are rejecting the events AFAIK (but I will double check). One way or another I think that Amethyst should implement an exponential backoff policy. As it is, it's basically spamming "non-compliant" relays.
Your 10002 is signed by your own key, but we download 10002s of the authors of every like, zap, post, reply, report, edit + every pubkey mention in any post. So, for each post that appears in the screen, there is likely a 1-100 10002s from other folks being downloaded.
Got it. But is Amethyst trying to download or broadcast these (as in, other people's 10002 relay lists) from/to my own Outbox relay? As in, is my interpretation that Amethyst should only be trying to write my own 10002 events to my Outbox relay and downloading 10002 events from everyone else's Inbox relay correct? Or should my Outbox relay be expected to accept other people's 10002 events?
No, it only reverts back to the relay that sent the outdated event. So, this usually only happens when somebody had permissions to insert, the relay received a bunch of 10002s and then the relay closed that permission.
That being said, I would keep a copy of everybody's 10002s in my outboxes because it helps clients figure out where to send things if your relay has seen them before.
Makes total sense. Thank you. So in Haven's case this likely isn't the problem, as in, the Outbox relay only ever accepted events signed by me, and as far as I can tell, it accepts all events signed by me, including replaceable events (unless I consume all my "tokens", then it starts rate limiting). So I'm still at loss about what's triggering the 10002 event write "loop".
How does Amethyst check if my Outbox relay latest 10002 event is up to date? (Can you roughly point me to this code in Amethyst?)
ohhh I just logged into your relay and it sent ALL the past versions of your own 10002 events. There are 44 10002 events coming down to Amethyst just for yourself. For each one of the 43 outdated events, Amethyst replies with the new one.
nostr:nprofile1qqsw9n8heusyq0el9f99tveg7r0rhcu9tznatuekxt764m78ymqu36cpz4mhxue69uhhyetvv9ujuat50phjummwv5hszymhwden5te0wahhgtn4w3ux7tn0dejj7qg4waehxw309an8yetwwvh82arcduhx7mn99uuwx66a something is wrong with haven's replaceable code. A filter by kind 10002 should only return the latest event, not all versions.
You can test it here: https://lightningk0ala.github.io/nostr-wtf/query
with filter: [{"kinds": [10002]}]
Yep I saw this too, I will have a fix for it this week. Ty gentz
nostr:nprofile1qqswa8vhnelpgx9f7arjhtuzmjtqs2sdgfgmw77tzu9xankf87kl7eqprdmhxue69uhksctkv4hzuctrvd5k7mre9eek7cmfv9kz7qgwwaehxw309ahx7uewd3hkctcpzdmhxue69uhhwmm59e6hg7r09ehkuef00yxkae nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqppemhxue69uhkummn9ekx7mp0qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qyghwumn8ghj7mn0wd68ytnhd9hx2tch2deau I am running these reqs and only getting one from my relay, can you please show me some screenshots of this not working?
Nevermind I see it on desktop but not phone
Check the notes I’ve tagged you in over the past few days. If you want to reproduce the problem yourself, just add a relay to your Inbox/Outbox list using Amethyst, save it, and sign the new 10002 event. Repeat this a few times and either use Vitor’s filter above or my "Citrine fix" script. Both will return more than one kind 10002 event.
Also, it seems Haven is accepting but silently ignoring Kind 5 Deletion Requests, so my script doesn’t fix the issue. Deleting the Outbox database and reimporting notes from well-behaved relays does fix the problem.
Delete is fixed now on the inbox relay
Fiatjaf still working on kind 10002
I sent him some ⚡⚡⚡🫡