I have a special request for more efficiency, if possible. I think it was the computation during spidering, since I jacked that up to every 10 minutes. 😂
Maybe need to spread it out more, or something.
it seems that i'm finally through a patch of staying up too late, and feel the distinct need to crash
#orly #devstr #progressreport
i've got https://next.orly.dev handling events and reqs but haven't done close and auth yet. the lack of close means it's becoming unresponsive after publishing an event and then getting another req because it isn't closing the subscriptions. but that won't take long to add close in.
i'm not implementing the auth stuff until i have a bit of thought about how to make a modular ACL interface so it can be extended to use more than one. the subscriptions processing is already abstracted so i can put back the HTTP if i want to, but i kinda don't want to.
i think a higher priority would be supporting search functionality (aka DVM). but it's almost a bare naked relay again and there is much less code in there and the architecture is simpler.
i think actually i'm gonna finish some stuff tomorrow and be like "ooh, it's done" though i haven't attended to actually making use of the new buffer pool i made for the decoder. there's dozens of places that needs to go in, especially in the database code and relay handlers.
#GN
Discussion
yeah, there's lots of better ways to do it than polling, it could open subscriptions to those relays and just receive and write them as they arrive. that would make it realtime.
gonna work on better stuff once i have the new codebase functioning as a freedumb relay
staying connected 24/7 to relays with long lasting subscriptions, plus anaylisis of those events in a WoT model is exactly what Vertex is doing.