man, refactoring the #realy subscription system so it's modular and can have each api separately disabled instead of only both on is proving complicated
the HTTP api is simple, there is literally just a channel that sends a context from the http request, the authed pubkey (if any), *one* filter, and a channel to receive new events on
in contrast, the websocket has three functions, one to add a new subscription, one to close a specific subscription of one socket, and to remove all of the subscriptions of one socket
i feel like the right way to do this is to make them uniform, so instead of having this complicated scheme, each subscription itself is distinct, but then i have the problem of supporting the closing of all the subscriptions of a socket, this is the main difference between the two interfaces
reconciling these two separate things into a uniform and simplified interface is really what i want to do here, and then each individual subscription has one filter and one close context, but i need a means to have all of them cancel at once...
i'm still a bit lost how to do this, but i'm gonna try and figure out a means to solve the problem
it's a juicy problem and i'm quite addicted to trying to solve it at the moment
i feel it is going to need something different, so where currently the sockets are not maintaining the state of their individual subscriptions, but using the websocket as a grouping for a set of subscriptions tied to one socket... >_< gonna figure this out soon
this is the hardest part of splitting the two apis apart, it's the place where they are connected to the relay's subscription management scheme, once i can have one uniform mechanism for distributing new events out and closing them as one or as a group i'll have it done and then i can put the implementations of the interface into each api package and then if the api is disabled it just isn't being checked, currently they are spaghetti
i hate websockets, did i mention that? they are such a messy construct for what should be a simple request/response
mleku
npub1fj…mleku
2025-04-12 18:37:44
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2025-04-12 18:37:44Event JSON
{
"id": "99fe1785429f8ecee1adb7ec0b504b3d796689884fc74a5d1d83c8c05071c76a",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1744483064,
"kind": 1,
"tags": [
[
"t",
"realy"
],
[
"client",
"jumble"
]
],
"content": "man, refactoring the #realy subscription system so it's modular and can have each api separately disabled instead of only both on is proving complicated\n\nthe HTTP api is simple, there is literally just a channel that sends a context from the http request, the authed pubkey (if any), *one* filter, and a channel to receive new events on\n\nin contrast, the websocket has three functions, one to add a new subscription, one to close a specific subscription of one socket, and to remove all of the subscriptions of one socket\n\ni feel like the right way to do this is to make them uniform, so instead of having this complicated scheme, each subscription itself is distinct, but then i have the problem of supporting the closing of all the subscriptions of a socket, this is the main difference between the two interfaces\n\nreconciling these two separate things into a uniform and simplified interface is really what i want to do here, and then each individual subscription has one filter and one close context, but i need a means to have all of them cancel at once... \n\ni'm still a bit lost how to do this, but i'm gonna try and figure out a means to solve the problem\n\nit's a juicy problem and i'm quite addicted to trying to solve it at the moment\n\ni feel it is going to need something different, so where currently the sockets are not maintaining the state of their individual subscriptions, but using the websocket as a grouping for a set of subscriptions tied to one socket... \u003e_\u003c gonna figure this out soon\n\nthis is the hardest part of splitting the two apis apart, it's the place where they are connected to the relay's subscription management scheme, once i can have one uniform mechanism for distributing new events out and closing them as one or as a group i'll have it done and then i can put the implementations of the interface into each api package and then if the api is disabled it just isn't being checked, currently they are spaghetti\n\ni hate websockets, did i mention that? they are such a messy construct for what should be a simple request/response",
"sig": "dad970a25a0d7093d92e050f876fe9e0b182b301ad0c66bb76884010403ca98049fd8791e019f79f5a344051520e45d1038be6849523d99ddca03dc4c2487ce1"
}