Replies should be sent to all mentioned users’ read relays, but in reality, not every client does that.

Jumble isn’t optimized for long sessions, so if you keep it open for a long time, there’s no guarantee you won’t miss some events. It could also be a network issue, maybe one of the relays timed out when returning results.

Because his client sent the reactions to your read relays? Haha.

My guess is that his client didn't send the reply to any of your read relays.

Do you mind sharing which browser and signer you're using?

Glad to hear that! 😊

Yes, absolutely.

The best Nostr browser 👍

Thanks! The best part is that clients don’t need to store the api_key locally, which keeps it secure. I’ve already integrated this service into jumble.social using this approach, it works seamlessly!

The translation API supports both api_key and NIP-98 authentication. For a smoother experience, you can use NIP-98 auth once to obtain the api_key, then use the api_key for subsequent requests.

🫡

🚀 Just launched #Jumble Translate — an AI-powered translation service!

- High-quality translations powered by #AI

- Pay with #Lightning

- LibreTranslate-compatible API (works with clients like #Damus)

- NIP-98 HTTP Auth

Already integrated into https://jumble.social/

👉 https://translate.jumble.social/

Received

Did this happen on mobile or desktop?

Sure 🫡

Maybe next month

I can. Looks like they’ve fixed the issue?

I'm not sure how Amethyst handles it, but I think if it waits to fetch the embedded note before rendering the note, it’s definitely going to be slower than just rendering the note first and then loading the embedded note afterward.

Which signer are you using? If it has some kind of expiration mechanism, then the only way to log in again

Yeah, the first time using it can be a bit slow since it needs to load a lot of data, like the profiles of people you follow and their relay lists. Also, if too many websocket connections are opened at once, it might prevent new ones from being successfully established...

I think if someone wants to be recognized on a social network, they probably won't drastically change their profile often. And if they don’t want to be recognized, well… let them have it, haha.

The NIP-05 identifier usually doesn't change much, so Jumble should probably display it more prominently in various places. That might help with this issue.

I replied to you on GitHub.

I've written a simple reverse proxy service and integrated it into the nostr-relay-tray. It can be easily enabled.

https://github.com/CodyTseng/pigeon

If you are a #relay operator and wish to attract more users to your relay, it would be beneficial to enhance your relay's information. This will facilitate users in discovering your relay.

https://github.com/nostr-protocol/nips/blob/cc3d7c63f59631810032c14d1f56ff034084583e/11.md

You can also use this template to quickly run a relay on Railway: https://railway.app/template/ooFSnW?referralCode=WYIfFr

First of all, I'm glad you chose to run nostr-relay-nestjs!

Since you've confirmed that the /metrics endpoint is accessible, I believe you've successfully got it up and running, and you're able to access it in some way. Therefore, your relay address would be ws(s)://:

Nostr relay is a WebSocket-based service, so the protocol used is ws(s):// rather than http(s)://

If you're unable to establish a WebSocket connection but can make HTTP requests, I suspect your NGINX configuration might be incorrect. Here's a simple NGINX configuration for a WebSocket service:

```

server {

server_name xxxxx;

location / {

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header Host $host;

proxy_pass http://127.0.0.1:port;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection "upgrade";

proxy_set_header X-Real-IP $remote_addr;

}

}

```

If you want to make your relay more easily accessible to others, you can purchase a domain and register DNS through a service like Cloudflare to forward requests to your AWS server.

nostr-relay-tray can manage which events to accept or reject with precision.