Reply events might easily exceed 8 indexable tags since jumble adds all the event IDs from the current thread 🤔
Discussion
Maybe I should just add the root e tag and the reply e tag instead?
Yes, please!, there is no point in adding so many "e" tags.
The limit can still be reached if we get to many "p" tags in a big thread, but that would be more rare. I do think clients should not keep adding "p"s forever, they should add just the last 6 (?) "p"s to have been mentioned or that have actively participated in the thread.
who set this limit of 8 anyway?
it isn't in the spec, bro
do you think that relay devs are incapable of writing efficient database and network service endpoints?
because i sure as fuck am having no problem
have fun trying to break wss://mleku.realy.lol that's my PRODUCTION release from about 2 weeks ago and if something goes wrong with it i figure out something is wrong pretty fast... i don't have a person monitoring it but it's easy enough ot see
see, thats' also why i like nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl's jumble client, because i can check in on my relay's feed
any garbage starts flooding in, defcon 1
i tried to add some rate limiter to it and it just made it misbehave... maybe i need to refactor how i added that thing, but for now, it's functioning ok
if i get even more users, then ok, maybe i start to see more stress points, and that's great but you know what
the biggest stress point of any public facing internet server is this:
spam
i don't have this problem because i don't allow public writing to the relay, you are on my follows, or one of my follows follows, and not in my mutes, and yes you can write
amazingly, and evidence of my discrimination, i don't have a spam problem on my relay
the database is taking up about 200mb of space
it obviously is not failing to limit access
also, this is another point about the problem of websockets
what happens with spammers and rate limiters and sockets is if you slow down on one connection, they open another
i'm pretty sure that is what was happening, and they blew up the relay, exibit 52491 in the case against websockets for request/response APIs
also, yes, changing the threading model probably would fix it in my code, so managing pings and whatnot was done in one thread, but the actual socket management data would still blow up even there, and when you consider that 2kb is the coroutine load per socket, and the socket itself is probably more than that, it was probably actually just holding that socket open that was the problem, while trying to "throttle" their requests
idk what to say, it's just a bad model, if you ask me, i'm pretty sure that there is likely myriads of historical experience relating to request/response protocols being a disaster to manage over bidirectional sockets
I added so many `e` tags because Jumble needs to view replies following a specific one. Without them, it would have to fetch all replies via the root `e` tag and filter them.
But I’ve noticed that more and more clients only include the root `e` tag and the reply `e` tag, which often causes me to miss some replies 😂 If this is becoming the norm in Nostr, I might need to adapt soon.
Filter all replies via root, but why filter them? Just show them all!
Or are you talking about user notifications? Can't you rely on the "p" tag for that?
