nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcprpmhxue69uhkxetvd3shytnwdaehgu3wwa5kuef0qyv8wumn8ghj7cmjv4shgu3wdehhxarj9emkjmn99uq3wamnwvaz7tmfde3x77pwdehhxarj9emkjmn99uq3samnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5hsqgpass40an279ylj3dnz0yehqj3lhr8p2w4fr4us4vgldf6j639y95kglx9x have you tested coracle and filter.nostr.wine together? From what I can tell it should work fine, but I don't have a subscription. If you want to give me some free time I can look into it.
What is the best relay setup, paid or free?
I'm using nostr.wine (filter.nostr.wine and inbox.nostr.wine) with Amethyst on mobile and Coracle on desktop.
Intention is to have one relay connection I trust, that takes care of aggregation, spam filtering and broadcasting my notes correctly.
But I've been having issues on and off for months: sometimes notes do not load, other times my notes never reach the relay. I talked to nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqelpt5w and to nostr:nprofile1qythwumn8ghj76twvfhhstnwdaehgu3wwa5kuef0qyghwumn8ghj7mn0wd68ytnhd9hx2tcprpmhxue69uhkxun9v968ytnwdaehgu3wwa5kuef0qyv8wumn8ghj7enfd36x2u3wdehhxarj9emkjmn99uq3samnwvaz7tmrv4kxcctj9ehx7um5wgh8w6twv5hsqgpass40an279ylj3dnz0yehqj3lhr8p2w4fr4us4vgldf6j639y95gle4xw , both responsive but can't figure out why. I don't have time to keep debugging - it should just work. And now, Coracle is "Waiting to connect" on both filter and inbox, so can't even read mazin's reply or answer back.
Nostrudel is completely broken with this setup, and Primal has other problems.
So, go back to the left curve solution and add the 10 biggest free relays?
#asknostr
Discussion
No I haven’t - not in a long time at least. The truth is any client that forces automated outbox relay crawling breaks the value proposition of filter (reading from one high performance relay with spam control).
I’ve added 3 months for you. Let me know if I can help in any way.
Also added time for inbox.nostr.wine if needed.
Thanks, just tested the integration. It seems to be working basically correctly, except that inbox is misusing the `auth-required:` prefix to block non-DM filters, even when auth is already successful. Coracle handles it fine, but it may confuse other implementations, `blocked:` is the correct prefix. nostr:nprofile1qyghwumn8ghj7mn0wd68ytnvv9hxgtcqypex583xrnryw3n5aq59uw23kwa38xlf5aeart85nhyx3kuxrgwpzjh056v the reason you might not be seeing inbox connect is coracle requires the user to enable messages to avoid a million signature requests. Try visiting the messages page and see if it connects. nostr:nprofile1qyv8wumn8ghj7cmjv4shgu3wdehhxarj9emkjmn99uq3zamnwvaz7tmwdaehgu3wwa5kuef0qyv8wumn8ghj7enfd36x2u3wdehhxarj9emkjmn99uq3samnwvaz7tmrv4kxcctj9ehx7um5wgh8w6twv5hsz9mhwden5te0d9hxymmc9ehx7um5wgh8w6twv5hsqgpass40an279ylj3dnz0yehqj3lhr8p2w4fr4us4vgldf6j639y954mdm05, I'm also seeing none of my recent messages coming from inbox. I'm not sure if this is intentional adherence to outbox (in which case it's correct), or if your scraper/multiplexer isn't working as intended.
I'll update that response prefix for inbox.
I’m not sure I understand the second part. What do you mean your recent messages coming from inbox? filter.nostr.wine is the aggregator/broadcaster, not inbox.
Ahhh I see whats happening here. This was updated recently to support multi-auth per connection. If you try to make a REQ that another user could be authorized to make, it will tell you auth-required instead of restricted to give you the opportunity to AUTH again with an additional pubkey.
Does that make sense with what you saw?
Interesting. It does explain what I saw, but I'm not sure it's accurate in this case (because filter will never serve kind 1s). It's also not very helpful, since how can the user know which user they should auth as? It seems like it would be entirely up to the client to choose which keys to use. See this recent PR for how multi-user auth has been proposed: https://github.com/nostr-protocol/nips/pull/1881/files
> I’m not sure I understand the second part. What do you mean your recent messages coming from inbox? filter.nostr.wine is the aggregator/broadcaster, not inbox.
I assumed since I had access to filter I would have access to inbox and it would aggregate DMs? But only old messages are being returned from inbox. That seems potentially correct, I just wasn't sure.
Filter does return kind 1s. I assume you mean inbox in which case I’ll take another look at that response.
Inbox does not communicate with the aggregator in any way so it will only have messages from when you previously used it (I think I gave you access back in 2023).
I added multi user auth exclusively as a result of that PR. I don’t understand what is wrong though. The client always chooses which key to auth from, no?
Inbox doesn’t explicitly prohibit REQs for kind 1, but they have to supply a relevant tag. It blocks them on write though so they will always return empty.
I will fix this so those return blocked instead.
Yes, I meant inbox, I confused myself. Your explanation makes sense too. On multi-user auth, I guess returning auth-required could makes sense if the alternative would be restricted. I'm just not sure what action the client would take in that case without being very coupled to an interpretation of the relay's policy.
I added a new message now for when you try to REQ a kind we do not store on inbox. It should used the “blocked” prefix. Thank you for pointing this out to me.
And yes - I think that is a challenge for sure. I think the main proposal is based on Vitor wanting to have 1 socket connection for multiple logged in accounts on Amethyst. He can AUTH with all of the logged in accounts when they prompt so that he can access privileged events for all those pubkeys. It’s a bit messy on the client side but it was easy to implement on our end so we went ahead and did it. I assume the proposal will change 10 more times in the next year and our implementation will break soon.
I think this stuff is pretty stable. It's the reply stuff that's a disaster area
Earlier today, filter was not connecting either.
I am trying out nostr.land for a bit. Maybe that sheds some light on all this? I'll report back.
nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcpr9mhxue69uhkscnj9e3k7unpvdkx2tnnda3kjctv9uqzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezyx6uqg given I *only* have wss://nostr.land (and just checked my 10002 on purplepag.es) why is Coracle broadcasting my latest post to 5 relays (nostr.land, nostr.wine, inbox.nostr.wine, creator.nostr.wine, etc)?
Appreciate the level of information you put in Details!
However, more puzzling results:
Coracle will write replies to the inbox relays of those you have tagged in the reply. nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn is using relay.damus.io, nos.lol, and hbr.coracle.social as inbox relays. nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz is using creatr.nostr.wine, among others.
Yes, this is what is redundant with filter.nostr.wine, as it also does that. It is its own mailbox implementation.
Interesting. I knew about its blastr relays, but did not know it also uses NIP-65 for replies to post to the inbox relays of those mentioned.
Is this something we should be expecting relays to handle for us, rather than clients?
I think our collective paranoia is negatively affecting UX.
As long as these all-in-one relays do not censor it's a superior solution with less waste.
Censorship incentives are low, they can be swapped immediately for a different provider and affect their brand reputation.
Check your "max relays per request" setting. If you are sending/requesting from fewer than than number of relays, coracle will fall back to that number. Coracle wasn't really designed for relay selection tuning, but to "just work" no matter how bad people's configurations were. That could be changed, but it's unclear to me how much it would only work for power users.