mleku on Nostr: documentation and comments both tend to get radically out of sync with ...
documentation and comments both tend to get radically out of sync with implementations
the only solution to this is compliance tests, and for relays that is pretty easy but for clients a bit more complicated because the clients need to follow a protocol that they provide a mechanism to call it and generate the required request data
with nostr, the client side is where the main stuff lives, in fact, part of the issue with the nips is that a few of them, mostly only event/filter nip-01 and auth nip-42 and relay info nip-11 are relay side/relevant, while almost everything else is client side
separating these two would help a lot
looking at my own current codebase i am going to create a second level hierarchy out of my packages to isolate parts so they don't smoosh into each other and make incorrect ontology
Published at
2024-07-21 13:21:20Event JSON
{
"id": "acbdf94652f339414a94fa184a10b1659c8aeb9dff59edbf60f6618dc29ea3a6",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1721560880,
"kind": 1,
"tags": [
[
"e",
"45aa2c732ffe83f8e5fa2b2a7966bbda42683db178189cdb1cfa6068b8bfb517",
"wss://theforest.nostr1.com/",
"root"
],
[
"e",
"e7d3799c250d075e7cfebe36f296df7650d4027e3f9ef965f14321c0e7ce5010",
"",
"reply"
],
[
"p",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319",
"",
"mention"
]
],
"content": "documentation and comments both tend to get radically out of sync with implementations\n\nthe only solution to this is compliance tests, and for relays that is pretty easy but for clients a bit more complicated because the clients need to follow a protocol that they provide a mechanism to call it and generate the required request data\n\nwith nostr, the client side is where the main stuff lives, in fact, part of the issue with the nips is that a few of them, mostly only event/filter nip-01 and auth nip-42 and relay info nip-11 are relay side/relevant, while almost everything else is client side\n\nseparating these two would help a lot\n\nlooking at my own current codebase i am going to create a second level hierarchy out of my packages to isolate parts so they don't smoosh into each other and make incorrect ontology",
"sig": "bb2472051ac0db5cc890a6a99b64d03592cb347604a9bf001d2dfe1a1833c449bb08ffa45edce8632d58e91862b4806355daac8cfb6cb1e55026e71778b2c46a"
}