Working on massively simplifying my relay code of NNostr https://github.com/kukks/nnostr. Recently, @lontivero asked me why my relay logic was so different to the rest, so here is my story:
Back in 2021, we had to do assumptions on how clients would utilize subscriptions and filters. There were only
A handful UI clients back then doing mostly the same thing and realistically 0 users as all the notes were just tests. Would everyone generally just create identical subscriptions? Would they have massive filters sets per subscription? Would filters be a template that everyone mix and matched into subscriptions? Was anyone even going to use any of this?
As usual I went nuts and started building it super optimized from the get go. Every filter from every subscription was hashed and used as an identifier so that no duplicate sql call would be needed when users requested the same filters.
Realistically though, nip01 still needed to mature and the filter spec gradually changed to introduce more convenience, such as paging and date ranges. This made writing clients way more efficient, but unfortunately made my optimizations just a bunch of crazy useless magic as filters were always different due to more precise query capabilities.
I'm still happy with my relay code though, it comes with unique features such as a builtin balance system, fee charge on new keys and on per event basis, dynamic event fee based on event size, a chat bot for administration, and other fun stuff.
Soon I'll be changing the filtering code to a more simplistic style, and I'm hopeful to eventually also find some more crazy stuff to build for it! I do have some interesting client side nostr bitcoin stuff being prototyped on the other end 😉
Always looking for feedback and ideas, feel free to reach out!
kukks /
npub1y24…z2ad
2023-06-15 21:18:16
Author Public Key
npub1y24gz5gwucl79vtv4ctwpysl0r5m4xyzu2rgulnr44ks3t5mt92q4nz2adPublished at
2023-06-15 21:18:16Event JSON
{
"id": "947b6226137f7a50761b79fae7bc821c31f39ee8eb94ece895947f361e2351eb",
"pubkey": "22aa81510ee63fe2b16cae16e0921f78e9ba9882e2868e7e63ad6d08ae9b5954",
"created_at": 1686856696,
"kind": 1,
"tags": [],
"content": "Working on massively simplifying my relay code of NNostr https://github.com/kukks/nnostr. Recently, @lontivero asked me why my relay logic was so different to the rest, so here is my story:\n\nBack in 2021, we had to do assumptions on how clients would utilize subscriptions and filters. There were only \nA handful UI clients back then doing mostly the same thing and realistically 0 users as all the notes were just tests. Would everyone generally just create identical subscriptions? Would they have massive filters sets per subscription? Would filters be a template that everyone mix and matched into subscriptions? Was anyone even going to use any of this? \n\nAs usual I went nuts and started building it super optimized from the get go. Every filter from every subscription was hashed and used as an identifier so that no duplicate sql call would be needed when users requested the same filters. \n\nRealistically though, nip01 still needed to mature and the filter spec gradually changed to introduce more convenience, such as paging and date ranges. This made writing clients way more efficient, but unfortunately made my optimizations just a bunch of crazy useless magic as filters were always different due to more precise query capabilities. \n\nI'm still happy with my relay code though, it comes with unique features such as a builtin balance system, fee charge on new keys and on per event basis, dynamic event fee based on event size, a chat bot for administration, and other fun stuff. \n\nSoon I'll be changing the filtering code to a more simplistic style, and I'm hopeful to eventually also find some more crazy stuff to build for it! I do have some interesting client side nostr bitcoin stuff being prototyped on the other end 😉\n\nAlways looking for feedback and ideas, feel free to reach out!",
"sig": "7bc660282a31884794af1caef7a2afa8a1d882ea14c0b0fa852952b8b43e9f6c83745a54ea53e3b9f26897296ee6d2185068bc5de1f27cf28ab544e6abc19838"
}