This is definitely a client flaw on the part of nostr:npub120rmmsl94v2g9utt77gu2mp5mv6lv83l6573m6cg0vnkcldm7kuqunx44g's client since he is advertising publishing to 12 relays, but he actually only publishes to the 4 big ones.
What client are you using, nostr:npub120rmmsl94v2g9utt77gu2mp5mv6lv83l6573m6cg0vnkcldm7kuqunx44g?
In my library I've decided that people who advertise more than some number (I think it's 8 or something) of relays are clueless and their relay list shouldn't be trusted, so we default to reading from the big hardcoded relays from them.
> In my library I've decided that people who advertise more than some number (I think it's 8 or something) of relays are clueless and their relay list shouldn't be trusted, so we default to reading from the big hardcoded relays from them.
That's a good approach. I’ll make the change later.
Please add this to people that have only onion relays too.
Hi nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl I saw some commits that looks like fixed this problem right? if yes, why I'm not seeing posts from this profile: nostr:npub1ggfzdxa8xrrzhaut6venkrmjtw8wl25y6l0wramkc7d4dlyaflzsxxrfcq
Thanks
Two relays weren’t detected as onion relays because their format was completely wrong
ws://ws/oxtrdevav64z64yb7x6rjg4ntzqjhedm5b5zjqulugknhzr46ny2qbad.onion
ws://ws/nfrelay6saohkmipikquvrn6d64dzxivhmcdcj4d5i7wxis47xwsriyd.onion
It means?
Jumble treats them as regular relays and tries to fetch notes from them, but ends up getting nothing.
Is there any improvement on Jumble that can be implemented to mitigate this problem? Thanks.
We're unlikely to introduce special handling for every edge case, as doing so could unintentionally affect regular users. If someone wants their notes to reach a wider audience, it's important that they maintain a healthy list of relays.
Understood. Please nostr:npub1ggfzdxa8xrrzhaut6venkrmjtw8wl25y6l0wramkc7d4dlyaflzsxxrfcq fix these two relays url you added wrongly. Thanks.
Try now
I think take some time to update. Did you remove the relays? If yes, great. In some minutes I test again to see if your notes shows to me.
But I have the impression that if someone add a wrong url, shouldn't affect the other ones. Maybe he client shouldn't have allowed him add this wrong url?
When something is decentralized, it's very hard to not think about the edge cases, because many clients could implement things wrong, no?
Its URL complies with the standard, and the trailing xxx.onion is part of the URL pathname. I cannot identify it as an onion URL. If I simply classify all URLs containing "onion" as onion relays, some normal relays with "onion" in their domain names might also be misclassified as onion relays.
Edge cases like these are impossible to cover completely. An error in one client should not be the burden of other clients.
.onion/ is the term you are looking for. There must be prefix/suffix match text comparison functions, if it breaks the URL down. Scheme, address, path and query. I find it hard to believe that JavaScript lacks an equivalent of Go's url.URL type. Then it is literally just a suffix match on the address element.
ws://ws/oxtrdevav64z64yb7x6rjg4ntzqjhedm5b5zjqulugknhzr46ny2qbad.onion
The issue is that there's an extra ws/ in the URL, which actually makes xxx.onion part of the path, not the host.
JavaScript does have a URL class too. To be more rigorous, I should extract the host and match the suffix there.
