I will answer in English just to tag @npub1utx00neqgqln72j22kej3ux7803c2k986henvvha4thuwfkper4s7r50e8 here
---
I think there are two main problems then.
The first one is the memory overload/leaking causing it to crash. The relay either becomes slow and freezes, or Linux simply kills the process without an error message. I noticed that sometimes, before crashing, it gives a connection error message on the websockets of the other relays when it tries to do the blast.
The second issue, I think, could be related to the payload size.
Every time you follow someone, the nostr app does something like this:
1) subscribes to the relays to retrieve the kind 3 of your pubkey.
2) receives the entire list of follows (contacts list).
3) adds the new pubkey at the end of the list.
4) creates a new kind 3 message, signs it, and sends it to the relay(s).
That's why the more contacts on the list, the slower it becomes to follow a new contact. Since it downloads the entire list, adds the new one, and publishes everything replacing the previous list, the process gets slower depending on the number of contacts. This could potencially become a vector for DDoS attacks on relays.
That's when I created the script. Instead of adding one pubkey at a time, I started to build a list first and publish the kind 3 all at once. I would increment the list by a few hundred new pubkeys at a time.
That's when I noticed that after 6,000 registered contacts, it starts giving an error when I add more and try to send. It throws an error in the websocket.
A third thing I noticed is that with such a large WoT, it sometimes hits a rate limit from the relays it queries to build the graph.
EddieOz / EddieOz ⚡
npub1at…awyga
2024-09-30 08:11:40
in reply to nevent1q…mgyh
Author Public Key
npub1atrrqav7xyur93xszyaeuyyzy70mpmax488grndfaz3kddyc3dyquawygaPublished at
2024-09-30 08:11:40Event JSON
{
"id": "184e22eafa5a0fd3851eaafe6e8fa15f1166b74f061ffc4dbd6fcaa928cdd00e",
"pubkey": "eac630759e313832c4d0113b9e1082279fb0efa6a9ce81cda9e8a366b4988b48",
"created_at": 1727683900,
"kind": 1,
"tags": [
[
"e",
"d707ab0000952c8142670c674ef50a1fd0a53a28f45af88acc5e738ab901a57a",
"",
"root"
],
[
"e",
"db7dd1e95e7b8a978c6628661819b14ade4a76649acff6460af0e9bca1713f47",
"",
"reply"
],
[
"p",
"eac630759e313832c4d0113b9e1082279fb0efa6a9ce81cda9e8a366b4988b48"
],
[
"p",
"3ffac3a6c859eaaa8cdddb2c7002a6e10b33efeb92d025b14ead6f8a2d656657"
]
],
"content": "I will answer in English just to tag @npub1utx00neqgqln72j22kej3ux7803c2k986henvvha4thuwfkper4s7r50e8 here\n---\n\nI think there are two main problems then.\n\nThe first one is the memory overload/leaking causing it to crash. The relay either becomes slow and freezes, or Linux simply kills the process without an error message. I noticed that sometimes, before crashing, it gives a connection error message on the websockets of the other relays when it tries to do the blast.\n\nThe second issue, I think, could be related to the payload size.\n \nEvery time you follow someone, the nostr app does something like this:\n1) subscribes to the relays to retrieve the kind 3 of your pubkey.\n2) receives the entire list of follows (contacts list).\n3) adds the new pubkey at the end of the list.\n4) creates a new kind 3 message, signs it, and sends it to the relay(s).\n\nThat's why the more contacts on the list, the slower it becomes to follow a new contact. Since it downloads the entire list, adds the new one, and publishes everything replacing the previous list, the process gets slower depending on the number of contacts. This could potencially become a vector for DDoS attacks on relays.\n\nThat's when I created the script. Instead of adding one pubkey at a time, I started to build a list first and publish the kind 3 all at once. I would increment the list by a few hundred new pubkeys at a time.\n\nThat's when I noticed that after 6,000 registered contacts, it starts giving an error when I add more and try to send. It throws an error in the websocket.\n\nA third thing I noticed is that with such a large WoT, it sometimes hits a rate limit from the relays it queries to build the graph.",
"sig": "1b5b4f427008f43386d77ec08b421db1995ec919e0faf5b679cc0298622c394a699f5446ad074491d422632a2fc875bc0509b74f1f4b16c474932f7f493fc3ae"
}