well, the codebase is slated to be used in a NEAR network project coming up, but i'm not actually going to be having much to do with that, because the main task is buliding another event store for a different blockchain
my most immediate near future work is going to be an aggregator/bridge that primarily is about pulling data from nostr, blue esky and fartscape to feed to arweave
i want to make my stuff better and ultimately be able to in the near future drop in a whole new server core and codecs and associated libraries in place of the dodgy khatru based relay code and then rework the client side of it to adapt to the new, faster codecs (it's a huge change that breaks most of the APIs)
what i'm quite certain of is that what is happening is that a gigaton of threads are sitting idle for hours and eventually the residual memory garbage from them makes the garbage collector go insane and burn CPU nonstop, and the only fix is to restart the relay, which is not good architecture by my standards (imo, it should run forever, and be able to reconfigure hot, and ideally even if you must restart with new code, hold all the open sockets and resume their state correctly
that's a bit intense to actually implement but when it works, you have a codebase that everyone will use, forevermore amen
mleku / mleku™️
npub1fjq…leku
2024-07-02 16:34:43
in reply to nevent1q…kd7g
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2024-07-02 16:34:43Event JSON
{
"id": "b681c82e937f74ef54dc0f5bb618bbd229d3d0e0cf96639718a144481e6c1a3c",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1719930883,
"kind": 1,
"tags": [
[
"e",
"846db4293eca6122aa52050766fabd2688385c7626dd94fa23b9c64c72ec2514",
"wss://relay.mostr.pub/",
"root"
],
[
"e",
"175d1899c745f2f89bed129e0e8633f48b5c568a209b6f7ed07c125c79bdc85f",
"",
"reply"
],
[
"p",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319",
"",
"mention"
],
[
"p",
"f683e87035f7ad4f44e0b98cfbd9537e16455a92cd38cefc4cb31db7557f5ef2",
"",
"mention"
],
[
"p",
"52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd",
"",
"mention"
],
[
"p",
"70122128273bdc07af9be7725fa5c4bc0fc146866bec38d44360dc4bc6cc18b9",
"",
"mention"
],
[
"p",
"7cc328a08ddb2afdf9f9be77beff4c83489ff979721827d628a542f32a247c0e",
"",
"mention"
]
],
"content": "well, the codebase is slated to be used in a NEAR network project coming up, but i'm not actually going to be having much to do with that, because the main task is buliding another event store for a different blockchain\n\nmy most immediate near future work is going to be an aggregator/bridge that primarily is about pulling data from nostr, blue esky and fartscape to feed to arweave\n\ni want to make my stuff better and ultimately be able to in the near future drop in a whole new server core and codecs and associated libraries in place of the dodgy khatru based relay code and then rework the client side of it to adapt to the new, faster codecs (it's a huge change that breaks most of the APIs)\n\nwhat i'm quite certain of is that what is happening is that a gigaton of threads are sitting idle for hours and eventually the residual memory garbage from them makes the garbage collector go insane and burn CPU nonstop, and the only fix is to restart the relay, which is not good architecture by my standards (imo, it should run forever, and be able to reconfigure hot, and ideally even if you must restart with new code, hold all the open sockets and resume their state correctly\n\nthat's a bit intense to actually implement but when it works, you have a codebase that everyone will use, forevermore amen",
"sig": "80a9ce272ac01d8405401e9b71dbea4a2daf4ba57cd533adad6b2daad188987e5f0296289c077000ad585bde5b4e61dbacbe8bc074ed09b5f55e10132bfcf1ab"
}