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
mleku
npub1fj…mleku
2025-03-31 12:06:31
in reply to nevent1q…qrds
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2025-03-31 12:06:31Event JSON
{
"id": "1ed38963c39e6dcd661d25b333b11be21445e2cd2a70fa0fba94d1c5ee27ce80",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1743422791,
"kind": 1,
"tags": [
[
"e",
"4aee0377b414ea9afe4e0856e68850f158e2253009aeb50610299c37ae0069ea",
"",
"root",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319"
],
[
"e",
"da9910177ab0a331a1a7608fa39edebf0361cd83a3353b9a0aaad373c1d07ae0",
"wss://theforest.nostr1.com/",
"reply",
"fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1"
],
[
"p",
"21b419102da8fc0ba90484aec934bf55b7abcf75eedb39124e8d75e491f41a5e"
],
[
"p",
"fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1"
],
[
"client",
"jumble"
]
],
"content": "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\n\nif 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\n\ni can only provide solutions that fit the matrix that requires them\n\nmodularising 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\n\ni think it's a great idea, it's just beyond ambitious to megalomaniacal a bit",
"sig": "96446963cd9f4b26dc00f16330cc4376524aa563d383e89d72de0f513713f3b3c428e79e2da9f856c9c635c8c692b7053b35cbf719cccbdfb49880530e2e8aa6"
}