Replies (28)

Benking's avatar
Benking 4 months ago
Awesome work! Thanks for sharing, this sounds super useful and well thought out 🙌🧡🫵🏽
it isn’t very well thought out because it just picks a mirror at random, but I’m okay with hitting a mirror that is currently down if it means I have zero logic (and state) on the thing
it picked njump.me for you randomly, that’s the whole point. try again a couple of times and it will hit another portal
Benking's avatar
Benking 4 months ago
Totally valid trade-off. Random mirror selection keeps the system stateless and simple. If occasional downtime is acceptable, it’s a clean and maintainable approach.
this is actually useful because my workflow was to visit njump.me, watch it fail to load or be very slow, get frustrated, and visit nostr.at, watch it give me some ssl error, then go to nostr.com. thanks for your work on this. i was going to deploy my own njump server because of this. maybe i still will do it?
Yeah, but that would imply probing and keeping track of state etc. I wanted a quick and dirty left side of the bell curve thing 😅
Benking's avatar
Benking 4 months ago
Haha well, it’s not my fault I sound this good 🤣🤣😂😂
Benking's avatar
Benking 4 months ago
Didn’t expect that from you 😅🥸
Cool, we need to decentralized the hyper centralized njump.me! :) Suggestion: I would test the availability of all instances in background, and temporary remove the not available ones. So njump.to can actually work like a load balancer.
I was thinking most relays should run an njump.me service on the relay https url. nevent + nprofile has the relay encoded, in which case the service should just do a redirect to the relay that can serve the content. Would probably make the implementation way simpler.
hahaha honestly sometimes u post stuff that makes me think ur real but you just comment on so many damn posts that it seems impossible😂