Nostr Web Client

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

Silberengel 9mo ago

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.

Reply to this note

Please Login to reply.

Discussion

Silberengel 9mo ago

Also just privacy-invasive, to publish subscriber lists to relays.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 9mo ago

client problem

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 9mo ago

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 9mo ago

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