Thread

nostr:npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9 has a profile now.

Thanks for the kind words about Jumble! Jumble follows the inbox/outbox model, so it only fetches notifications from your read relays I tested with your npub and saw you have two read relays: * haven.ciori.net/inbox – only returned one event, which is the notification from a year ago that you mentioned. * wot.utxo.one – returned a rate-limited error, so no notifications showed up from there. If you wait a bit before checking the Notifications page again, they should appear. I’m not sure what rate limit wot.utxo.one enforces, but Jumble’s request frequency is already pretty conservative. Not sure if you’ll even see this reply though, haha

I am using other clients as well so I can see the reply. I tried waiting, but still only that notification is shown. Strange how my haven relay only returned that notification, I will investigate that, thanks for the info.

Given that many clients currently don’t follow the inbox/outbox model, I’d suggest adding a large public relay as one of your read relays. That way you can minimize the chance of missing notifications. Since Jumble supports enabling WoT filtering, you also don’t have to worry about getting spammed.

Yeah, might do that, but the thing is that I never had this notification problem on other clients like amethyst, nostrudel, gossip and coracle.

They might have added some compatibility for you, fetching notifications from more than just your read relays.

Yeah I can confirm something strange is happening with my haven relay (and also the wss://wot.utxo.one nostr:npub1utx00neqgqln72j22kej3ux7803c2k986henvvha4thuwfkper4s7r50e8 one? Not sure though). My haven inbox relay had only that single old event and even after trying with a new npub (which I followed to be sure for it to be in my web of trust), the new npub wasn't able to broadcast a test event (in which I tagged my main npub) on both my haven inbox and the utxo relays, I get the error of not being in the web of trust, which is strange since I follow the new test npub (?). So for all these months/years I wasn't getting notifications and events from those two relay, but from other relays (probably through blastr and/or read only app relays not tied to by npub inbox/outbox). For what concerns Jumble, as soon as I added the damus relay to my inbox ones I was able to see all the notification events I expected to be there (maybe not all, but you get the point). Now why isn't my original two relay combo not working? I don't really know.

This is Nostr, everything’s a bit chaotic, so don’t be surprised, haha.

Yeah I expected it to be, but not that much 🤣. And to add to the strange things: This https://njump.me/nevent1qvzqqqqqqypzpmsrqjawp4r8nwe5x37w8vdcqjpzv2ucz27scr27rxj7y3zsgwm4qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcqyqnz2c307jjfeh7w6yjdzzv474784zgqd0w9w0dg2uph08wdxk0ux750wf6 is an event for which I got notified about (on nostrudel and amethyst for example) and with nak I can see that it is present on the wss://wot.utxo.one relay, but then why wasn't it displayed on jumble notifications? I am trying understand the inner workings of these nostr clients, but boy is it difficult 🫠

I’m not sure why either. wot.utxo.one returned a rate-limited error, so Jumble couldn’t get your notifications from there. It’s possible Jumble sent multiple requests to wot.utxo.one when starting up, causing the notification fetch to be rejected. This might be something I need to optimize.

It seems I cannot see any nostr:npub1rxysxnjkhrmqd3ey73dp9n5y5yvyzcs64acc9g0k2epcpwwyya4spvhnp8 posts on my "Following" feed on Jumble, even trying to load the profile shows no posts or replies. No problem on other clients. The nostr strangeness continues...

Same for me:

Jumble fetches notes from a user’s first four write relays, and unfortunately, none of his notes could be retrieved from those relays.

Why I don't see your note above on your profile page nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl ? https://blossom.primal.net/28469841da6e645fd753f4d733e3575b6711a43923d03b7715282851f456b098.webm

I don't know if you mentioned me too, maybe not because I didn't receive notifications too.

Same problem

But I thought shouldn't exist this problem when both users use a client with outbox model.

What I meant is that my network might have had some issues, causing the note not to be sent to certain relays. Jumble considers the send successful as long as it reaches one relay, so this kind of situation can happen.

Hum, maybe nostr:npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9, in these cases, could retrieve automatically and send to the other relays?

Do you mean having the app check every time it’s opened whether recently sent notes reached the appropriate relays? I think that would be too complicated. There are many reasons why sending might fail — it could be a network issue, a relay outage, lack of write permissions, and so on. Many of these situations are beyond what the app can handle automatically. I think Jumble should show which relays it’s currently sending to, which ones succeeded, and which failed. For failures, it should allow users to manually retry sending. I’m still thinking about the way to present this information.

Maybe when fail, show a message warning that the user we are replying may not be notified if we do not retry to send again.

It’s not necessarily that writing to the read relays of the people you mentioned failed, it could also be that writing to your write relays failed. There are just too many possible scenarios, haha. Sometimes only one or two relays fail to write, but it usually doesn’t affect usage.

Would it be possible to chose those four relay randomly, instead of the first four ones? Maybe this could mitigate the problem.

I could increase the number of relays used, which should help a bit. Random selection isn’t ideal, since clients that follow the outbox model usually write to the first few relays first, so in theory those are the ones with the most complete data.

I think the doc should be reworded on the read write relay screen to say that the first 4 are chosen instead of "ideally be kept between 2 and 4". I will try to submit a PR if I remember

But what causes the people not receive notifications is fail writing to the people read relays. I think it's not a big problem fail to write to our own write relays, the problem is reply someone and this someone do not receive any notification.

nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl Why not use some big relays in these cases? or if no notes be found, when user click to retry (could be something automatically), search for other user relays on his relay list?

Exactly, there should be some fallback strategies in place.

Yeah, if we can show the sending status to the user and allow them to retry, it would be more reliable.