ahaha, so, nearly #gn again but i'm trying to get a bit actually done
i got the simple events endpoint done, though i haven't tested it, i figured easiest way was to actually implement a simplified filter, which will return precisely the parameters needed for a simple events query (just list of Ids) - so once i make teh simple filter, i can make a filter query, and then use the result to make an events query, and both are then tested...
the filter itself is done, it was just copypasta from the full filter, with ids, since, until and search removed, i had created a filter sort (so identical filters are the same if they contain the same elements) and so i could make a filter index, i forget why i made that exactly, maybe it was to speed up subscriptions, since subscriptions are based on filters and if an identical subscription comes in and it's sorted, marshaled and hashes the same fingerprint as an existing one, it only adds a new subscriber to that filter instead of another filter to pass through when events arrive (well, it's there, i think it also is mostly implemented so it can equally apply to simple filters later)
first is i need a new policy filter function, AcceptFilter, to match the AcceptReq, which does the same thing except it only listens to one filter, because that's how this thing works.
yes, obviously i already created a new simplified filter type, it's a simple object/struct with authors, tags and kinds
further, we put "since" and "until" into the URL parameters, because we can, and why not. I think this also leaves open the possibility of later adding things like sort order, instead of the default reverse chronological (newest first)
processing the parameters is simple enough, split the Path by ? and then the second field contains parameters as key=value separated by &
this will be tomorrow afternoon's labors
it is dark, and when it gets dark, it is time to sleep, even if by the fiat clock it says 8pm that's only 6:40pm by sun clock but it's dead dark already... i think the moon is not up yet, last night later on it was very bright outside, and i was disappointed that they fixed the lights around the caminho and it was once again bright without lights on inside (two days it was dark, was so nice)
mleku
npub1fj…mleku
2025-03-11 19:46:31
in reply to nevent1q…tqq6
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2025-03-11 19:46:31Event JSON
{
"id": "2f0c1fff0aed63603e1dbd5c4f78eaa143c0b5a72340207b9a10d5724c240fab",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1741722391,
"kind": 1,
"tags": [
[
"t",
"gn"
],
[
"e",
"fcdc81651532c14a6fe72973711443458fed1aced89d4e3e4463b9912d89bd30",
"wss://relay.nostr.band/",
"root"
],
[
"client",
"jumble"
]
],
"content": "ahaha, so, nearly #gn again but i'm trying to get a bit actually done\n\ni got the simple events endpoint done, though i haven't tested it, i figured easiest way was to actually implement a simplified filter, which will return precisely the parameters needed for a simple events query (just list of Ids) - so once i make teh simple filter, i can make a filter query, and then use the result to make an events query, and both are then tested...\n\nthe filter itself is done, it was just copypasta from the full filter, with ids, since, until and search removed, i had created a filter sort (so identical filters are the same if they contain the same elements) and so i could make a filter index, i forget why i made that exactly, maybe it was to speed up subscriptions, since subscriptions are based on filters and if an identical subscription comes in and it's sorted, marshaled and hashes the same fingerprint as an existing one, it only adds a new subscriber to that filter instead of another filter to pass through when events arrive (well, it's there, i think it also is mostly implemented so it can equally apply to simple filters later)\n\nfirst is i need a new policy filter function, AcceptFilter, to match the AcceptReq, which does the same thing except it only listens to one filter, because that's how this thing works. \n\nyes, obviously i already created a new simplified filter type, it's a simple object/struct with authors, tags and kinds\n\nfurther, we put \"since\" and \"until\" into the URL parameters, because we can, and why not. I think this also leaves open the possibility of later adding things like sort order, instead of the default reverse chronological (newest first)\n\nprocessing the parameters is simple enough, split the Path by ? and then the second field contains parameters as key=value separated by \u0026\n\nthis will be tomorrow afternoon's labors\n\nit is dark, and when it gets dark, it is time to sleep, even if by the fiat clock it says 8pm that's only 6:40pm by sun clock but it's dead dark already... i think the moon is not up yet, last night later on it was very bright outside, and i was disappointed that they fixed the lights around the caminho and it was once again bright without lights on inside (two days it was dark, was so nice)",
"sig": "334e6dd8f85110d88dba733072a4430199cf02375135c546de93d5339885c2c975718e11becda703aabc5a96112057ceab6939f8e3ba17ce957d931fe1bcd2f7"
}