Considering adding native Tor into Amethyst just to go around relay per-connection limitations.
Then we could keep all accounts connected and downloading their events at all times, while using a separate exit IP for each nostr filter.
There wouldn't need to be a global account switcher. Users could have 100s of accounts working together.
Plus, huge privacy gains.
I would enjoy that
wow Nice
That sounds like a plan
Is the idea one step forward, two steps back.
Maybe instead of fighting relays that try to limit abuse with limited tools that they have, we should discuss the issue?
What's your ideal relay? Has no limits on number of concurrent connections, subs, requests per second and bytes/events served?
I have 100s of what should have been separate subs packed into 10 subs right now.
Max number of filters, max number of kinds in each filter, max number of follows (usually 2k), max number of etags, etc. I am hitting several limits at the same time now.
I also need AUTH for separate accounts in the same connection, which doesn't seem feasible without a massive change on how Nostr filters work.
So basically:
- higher limit on number of active subs - then other filter/etag/pubkey limits could be handled by splitting into several subs
- higher limit on number of connections
?
The hard part is convincing every relay to do a 10x on their sub limits.
Many are still forcing Max 10-12 subs.
Still doesn't solve the auth problem. So, it might not be worth doing it and going straight into Tor.
It's not about convincing, but about improving the rate limiting system. The actual load is roughly equivalent whether you send 1 sub with many filters or 10 subs with less filters in 1 conn or 10 conns etc - you need that data, you will request it one way or another. Rate limiting at sub/conn level is just a dumb way to evaluate and limit the load that client is creating. Better rate limiting would take into account the actual number of indexes touched or table scans performed or filter conditions matched for incoming events and events retrieved and served on per-IP basis, then number of filters/subs/conns wouldn't matter.
Could you please publish an example list of subs that you'd like to have persistently active, so that we could have some rough idea of the potential load it could create? Also for pre-sync state and after-sync state - the sync load probably differs greatly from the "watch-for-updates" state?
It's been painful to build the current (pretty dumb) event sync for npub.pro, so I agree things need to be improved in this area.
Also, batching filters might result in unintended expansion of result set - instead of 2 filters {npub1,kind1} and {npub2,kind2} sending one {[npub1,npub2],[kind1,kind2]} may return much more than was needed. So it seems like relays should allow more of precise (smaller?) filters.
Yep, batching like I do creates much more complicated queries for their indexes to deal with. It doesnt make any sense.
It would be possible to streamline payment verification in this way, permitting a proportion of mining onto mobile phone devices, Layer 1 being the most advantageous of course. Although, I am having a look around some of these Layer 2 adaptations.
Eventually we won't need exit nodes. Relays will be hidden services.
Yes, please do it! It will make a lot of sense also for normies using start9 to have a nostr onion relay installed and use it.
will took a lot of work
Do it, but just for the privacy gains, cheating the relays doesn't seem like a good long-term plan.
There is no other plan though. I don't think I have an option at this point. Relay software is still in the dark ages.
Plus, they would never know anyway.
If they are applying limits to avoid collapsing, they will still collapse and stop Nostr. Is this a way to force them to review software performance or invest in infrastructure?
If the limits we see today are real (I doubt... operators are just using the defaults), they will collapse regardless.
I am just anticipating the issue.
Did you ever find a good tor library?
No, but I am testing them all again. Let's hope stability has improved.
Also, before I was looking mostly at the privacy gains. For this, we could just run Tor in parallel with the regular connection. If it works, it goes there, if not, just uses the regular stuff.
Also, I need to be able to control several sessions with different exit nodes without much latency. Let's see how that goes.
The guys behind Phoenix wallet seem to have written one, but it is not published on Maven, and you need to read the code to know how to use it: https://github.com/ACINQ/tor-mobile-kmp
Oh, I was wrong. It *is published* on Maven. It's now figuring out how to use it.
Need Kotlin libs for it. Right now all they have is in JavaScript
Hi, bare-kit is now available on Android and iOS. It lets you use the holepunch stack on mobile platforms.
I have a working example of both in Objective C / Java, but "Kotlin can call into C using JNI, the same as Java. That's how Bare Kit works on Android."
If you need more info, we can talk on Discord or Nostr DMs, or even here.
Could another aspect be battery usage related? I have noted that orbot use the majority of my battery when connected. Hopefully the libraries available can help with that. The Zeus wallet have a very decent implementation of this from an end user perspective.
The main enemies of relay administrators are spammers, bots, and Vitor Pamplona.
the relay problem is going to continually haunt nostr which is why you need to embrace p2p pears.com
I love the idea of standard Tor, but it slows everything on my machine down to a crawl.
get a better machine
This guy BUILDS
Is this possible? Please do! 🤩
Yes, yes please!
Checkout Arti, the new rust Tor implementation, it's designed for such integration!
As long as TLS doesn't start to bite you :)
It bugs me that you mention these present tor limitations .. years ago I had a look into it to build an implementation in Java, and I got started on it, but eventually dropped it because at the time everyone was insanely paranoid of the subtle issues that can arise and I did not expect such a java implementation to be accepted back then. (I was probably right for that time.) And now I see this and I'm thinking, it would've been a great starting point if not a sufficient solution.
