i wrote it this way because it meant i didn't have to write a UI for it
Discussion
You have a UI, now. 😁
that's my point, i adopted the postell's law on this, and used the simplest black/white list interface that existed that was almost universally implemented as the UI for my #realy and it works very nicely
you haven't annoyed me really bad in a while so you are still whitelisted, but even if you do, if i merely unfollow you, but i follow people who follow you, and they publish their follows to my realy, you are still allowed in to post
i'm refining the permissions on the second level though, at some point, i recall i had some thoughts and maybe implemented some code that discriminates
If Realy had a way to port in a list of subscriber hex IDs and status, comma-separated or something, like
1098532, Basic
9531695, Premium
7531897, Premium...
then we could add it to the main server landscape, which only subscribers can use. Would add redundancy and protect us from a strfry-specific attack. Just saying.
I mean, what if we ended up having thousands of users... or millions? Follow lists don't scale. I had to give up using lists in theforest after a couple hundred nostr:npubs because I needed it really exact.
Also just privacy-invasive, to publish subscriber lists to relays.
client problem
it's just a policy feature, so to change it to use these lists, is quite simple, and could be done and substituted, and publish them to only the relay itself, is literally a client problem
i understand the problem you are articulating here, it just mostly starts with the client, and the reason why i designed it that way was because of the retarded clients
also just gotta point out that CRDT follow lists don't scale even worse, because every little follow has to have its signature verified and the result cached into the client's list
if you want a serious scaling solution for that kind of 10k+ size of lists, it's simply not possible without first enabling a local serial ID for each user, that cuts your data size to 1/4, for a start, and nostr protocol is not the right way to present this, it would be more concise as short lists of decimal encoded serials of the users, max data length is then 7 bytes for each entry
i can only provide solutions that fit the matrix that requires them
modularising the policy parts of realy is a fairly big job but it does eventually need to be done, but it also requires cooperation of a client dev who can make that work neatly on the scale you refer to
i think it's a great idea, it's just beyond ambitious to megalomaniacal a bit