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)
finally got around to finishing more of the HTTP nostr protocol implementation
i've already tested one method, which is for submitting events... and had used it, but then i was looking at it and realised that http methods should return http error status codes
so i went through and replaced all the ok,false etc envelopes with standard http messages, mainly "NotAcceptable" for cases like trying to delete other users events (need to make an exception for users authed as admins, or maybe just put it inside the main admin interface, just haven't got to that yet) and "InternalServerError" ie 500, which is what it returns if the database fetch fails for whatever reason, errors that likely don't happen very often
i forgot how laboriously complicated the delete event processing was, also, omg... and yeah, that's another reason why i'm probably not going to do anything about enabling admin delete outside of the admin endpoints, it's just for normal users this code, it's basically the same as the EVENT envelope flow but translated into HTTP
i still have to write the actual simple fetch events by id `/events` in the database, i've sketched it out on the http handler but the database side isn't done yet, but i'm feeling a bit wired this evening and i'm gonna just get me some sleep, it's my bedtime, sun goes down, my brain turns off
tomorrow morning it's fiat mining again for another 5 hours first, and then i can return to the nostr http and implement the simple fetch protocol and probably i may actually have the `/filter` endpoint, which is the same as a nip-01 filter except without the "ids" field or "search" field
the actual "search" field i'm just gonna put a "NotImplemented" stub in there for now because it requires a separate index to be created, though i can probably make a special case of filter processing but where it requires at least a pubkey, a tag, and since/until boundaries that don't exceed - let's say, a month, because it can then pull those in a standard filter and then include everything that matches one of the keywords on the content field, and basta, full text search without full text index... nah, seriously, i'm not going to do that, too fuzzy to define sufficiently tight requirements for doing an exhausting scan of content fields, so it will stay that way until i do implement a fulltext search
and i will, just not now, it's important for a document repository use case and that's a key target for the #realy in the long term, in association with the #alexandria project
the tricky thing is that i have to implement that index manually, and that requires an index entry for every full word found, and then a second indexing pass to find mashed together words, and then parsing for whether it's case sensitive or not (probably can just have it not, but then check the content match if i want it to be case sensitive) hah... yeah, actually, it's a complicated task, probably a couple weeks work for me to build a full text index
anyway, getting off track, with fetch by id `/events` and `/event` for submitting events and `/filter` for searching events, you have your basic CRUD (when you include delete event processing, which i have) and that will be MVP
second target after that is to add a socket-using `/subscribe` endpoint that does filter matches on only newly arived events, and a `/relay` method which ignores the nip-01 idea of kinds indicating an event is ephemeral so the user can dictate that the relay is not to store the event even if it is storable, why? you ask - i'm glad you asked, because i intend to later on revise the event encoding and request encoding scheme to plain text with line separations and other common conventions, and event kinds as path matching like `note` and `note/html` and `note/markdown` and `note/asciidoc` just as an example of this, so you could search for any kind of `note` or you can search for specific formatted ones instead, and in this future scheme, there will not be a notion of "ephemeral" or "replaceable" or "parameterized replaceable" events, instead there will just be `/relay` `/replace` and parameterized replaceables are just a client side semantics, instead of some nebulous vague nonsense like what plagues the whole nostr protocol specification from top to bottom
anyway, that's my debrief for my day's work today, it was a good day, i've mostly got a matching matrix table implemented for that now, and will be actually building a mock and having it populate the matrix table and then perform a bunch of queries... which then leads to making a specific query API for the recommender which must also store history of recommendations so it doesn't repeat itself
#gn
oh dear, i gave my skitty #mochi the new drontal internal antiparasitic and some other drug for the external stuff, and i see his eyes are all watery and he's behaving rather differently, like, playful and bold, sitting up on the shelf threatening to tamper with my nicknacks
he is definitely in skitty mode right now
this weather at the moment is crazy, rain and wind and rain and wind and i don't know what way is up at the moment
time to go to bed, but first i must dispose of the skitty's deposits in the clay repository in the bathroom, and sweep the clay bits he has scattered around the floor, and then to welcome him to his favourite sleeping place next to me on the bed upstairs
too much friction and probably i can't even catch a photo of him perched on the shelf with his visible slight wobble that is obviously probably induced by some cholinergic effect of the drugs i gave him to clear his parasites
well
inshalah that this actually kills the ear mites and eye mites he has had that the previous treatment did not affect
and i'm off to clean toilets and chew bubblegum, and go to sleep to the whooshy sound of the wind and the periodic random patter of rain
#GN
#realy #devstr #progressreport #gn
not a big major thing, just signing off with what i have got dose so far...
there is now a little registry that stores a mutex protected map of capabilities, the scaffold of the HTTP handlers, and for each handler a a registration init function that currently is empty but will be populated to convey the necessary information about how a simplified nostr API call can be used and what it requires or other optional things
i will have to write some new API for the database to implement these, as, for many queries it will not be necessary to decode the event immediately if it doesn't require a second level match in addition to the base index match generated by the filter, as the filter/fulltext query types only return lists of event IDs instead of directly returning the IDs
the purpose of this is to enable pagination without the relay needing to be made more complex with a query state cache because dynamic data has to be either updated to match new events that come in, or the results of a request have to be cached for a period of time to enable clients to selectively request segments of a result set
this way it just throws that back to the client, and they can then formulate events requests that contain the segments of the result they received in order to load the data for display. in fact it enables the client to literally preload ahead of the scrolling of the user one by one as a new item is revealed, it can fetch the next one ahead well before the user gets to it, in accordance with the scrolling motion even
not stuff that pagination even helps you do, though it doesn't really apply to desktop/web aps so much as they don't have the concept of "flick" scrolling
anyhow, back to the fiat mine tomorrow, building a different other database and index scheme and API, but for sure i will be fleshing out these methods as i go
it will be possible, once i implement these, to add the ability to make these queries using the `curdl` curl-tool that does nip-98 HTTP auth, to send it queries with the relevant Accept header data, RESTful path and POST string containing the JSON of the request
yes, this will be a bit like what `nak` does, except without the websockets
well, the subscribe could probably do it *with* the websockets as well, but that would require me to extend curdl to be able to print the received event ID hashes as JSONL, which could of course be part of some shell script or fed into some other program
in fact it does kinda make nak redundant as far as programmability for shell scripting since the APIs are on the relay simply paths and json in http request body, for most of the things anyway, not all, like, i'm not gonna implement bunkers lol
anyway i'm kinda betting on the idea that once there is a mostly HTTP way to access nostr events that this design will proliferate due to its simplicity
#GN it is time for my repose, after a productive day, 3 hours on the paid gig, and the rest of the day pottering around and making BBQ and finally finishing my nip-98 auth for HTTP on #realy
tomorrow, moar paid gig labors, i have pretty much got a parameterizable user data comparison scheme together for a simple fuzzy matching scheme to back a recommendation engine for gamers to talk to and maybe play with other gamers
and then i will start building out the JSON version of the HTTP only protocol i designed for a simpler text format... and probably also make it so it will be easily changed to other encoding formats such as the one i designed at https://protocol.realy.lol - which is more or less looks like a thing like email... which is what inspired it, but also because i know from experience that this kind of structure is superior to shitty garbage like JSON
it will just be a custom HTTP header to select the encoder
there is some NIP proposals around for this kind of encoder selection right in the HTTP header, i will be coordinating with nostr:nprofile1qyv8wumn8ghj7mnxv33zumn0wdmksetjv5hxxmmd9uqsuamnwvaz7tmwdaejumr0dshszythwden5te0dehhxarj9ekxzmny9uq3jamnwvaz7tmjv4kxz7fwdehhxamgv4ex2tnrdakj7qgswaehxw309asjumn0wvhxcmmv9uqzq5455pmtewaacws6a73hxkqkea6fjwcm3keq9vqu3q7930nl4k9a4xdllk as he's the main mover on this, but i think he will like what i have already designed as my event and API message encoding scheme for as far as text formatted goes, i just will first implement something that talks JSON with this`nostr+json` or similar parameter in some HTTP header field, Encoding? idk what it is
anyway, amanha, amanha
#GN
i have a kitty in the cupboard, with a runny nose, and he is gonna stay there until he makes a racket trying to get outside for poopies, and then i will wake up
hopefully not before my usual wakeup time of about 3am
i am in the midst of revising #realy against mike dilger's relay tester
already discovnered that for some reason or other i didn't and should have been signalling auth, count and ... outbox!
got lots more things to do but i'm gonna plug on through the requirements and get green on all of them that i consider to be correct, and soon there will be #realy v1.6.0 which will be the "yes this does actually work" version
i need to go pet my little new sickie friend in the cupboard and then i shall go horizontal for the meantime
i love my little mochi
i'm definitely doing the ship mission
fuck it, why not
i want to feel like it is sane for me to take this animal to the vet and make him healthy, which will probably require some antibiotics, several antiparasitics, maybe some dental surgery, and a sexual disassignment operation, and dash it all if my landlord complains i will continue my portugesh lessons and swear at him some kind of 'merde' and similar for being a cunt and not letting me live like my neighbours, who all have kittah
hah, no i doubt that is even remotely likely, but i also doubt he will care that my water collection got contaminated by his roundup spray
how that shit is even still legal is amazing
anyway
i need cuddles... and mister mochi shall avail me
been diving deep into some gioui.org/example code for a rather pretty material design UI - decided that i needed to just try and figure out how to use the latest version of this library because the bastards changed it so much in the last 5 years since i was first using it, that none of my code can be easily updated
in any case, the new stuff has shiny things like modal sidebars and animations and other groovy things and there is a decent markdown display widget as well so this is basically everything i need, i may get cranky trying to get the damn X11 middle button paste working exactly as i want it to (in my previous code for whatever reason, i discovered that the app was wiping the buffer on exit, not a big problem if you keep it open but if you make an app that opens briefly and you want to paste something from it you have to not close it... which is lame
anyway, adding this feature won't be that hard, there's a few widgets that will need some modification and that will not be difficult... the other thing was the old XGB library it used is quite out of date, and there is a new one, and possibly there will be some other way for me to get it working
anyhow, i made the code much shinier, nothing makes me more crazy than stupidly noisy code with rubbish that has to be there but is interfering with me reading it, the more i have to ignore in code, the less i will understand it, because that's just how it is, and that's why i like Go, because it is one of the most readable and concise languages
stupid git host that they use is also very lame, there is no source code view to just casually look at code so i won't bother trying to show the side by side, suffice it to say that the way that elias naur and co design their APIs is retarded, and you wind up with massive, long lines and ugly layout and hard to read and no real care has been taken to minimise the amount of crap you have to type to use this shit
but it is really the best, even still, for Go, even though they are shit at making it easy to use... so i want to use it, just got that obstacle of getting a decent framework for using it easily, the example i was working on today is great, it covers almost everything except for the more complex text editing that i will need, but that's ok...
the gio code as it is can be cleaned up a lot by using a lot of aliases and rethinking how to structure the files so there is more local scope and less stupid unnecessary package names to further clutter it up
but even still, it is pretty compared to rust. rust is pig ugly, absolutely ugly as sin, and the level of complexity of the syntax is too damn high
only young people could love shit like this, because people who have been working for a while will remember when you stop using something, the ease with which you can pick it up again is directly proportional to how fucking complex it is
it has taken me about 3 days to get back in the groove with gio programming
shiny new nostr relay chat app will be coming in the next months
anyhow
it is bedtime at the mleku citadel by the sea in the town of good luck
#GN
Showing page 1 of
11 pages
