for those who saw my messages about the sysop of #gitcitadel yesterday
the problem, as i saw it, was he doesn't understand that NIP-42 specifies that the client has to put the relay address, eg wss://realy.mleku.dev in the auth message, and when the relay is behind a reverse proxy, the reverse proxy has to tell the relay what address the client reached the reverse proxy through
i already have PTSD about how byzantine nostr protocol is in general, and retarded, and MY reverse proxy correctly works as you can see by simply using the one in the address i just named
i don't appreciate being treated like i don't know my subject matter by someone who thinks they are some kind of fancy fucking ops tech who clearly does not understand the nostr protocol and has never deployed a nostr relay that requires auth
and i especially don't appreciate it when i explained it all in detail, repeatedly, for the last month, and the dude doesn't even click the link to the http API docs, and nearest i can tell is because the dude has a phobia against #golang
he doesn't read the code, he doesn't read my instructions, and he doesn't run any of the NECESSARY tools that i stipulated were necessary, in order to do configurations like dynamically changing the logging in order to see what address the relay is receiving from the reverse proxy and why the auth is being rejected
it's not just "working on my side", it's how nostr fucking auth works, ok?
i refuse to work with this guy any further after he has repeatedly shown that he seems to be lacking respect for the person who builds the software he has been asked to deploy
if gitcitadel want to use my relay, they are on their own, at this point, unless they can persuade this guy to fucking pull his head in and actually follow SIMPLE instructions
#realy #devstr #progressreport
yesterday i spent a lot of time writing a novel (i think - it's the reverse of regular variable length integer encodings in that it uses the 8th bit as a terminal marker instead of one on each byte to indicate "there's more") variable integer encoder to write a binary encoding for use in the database that is written using the #golang io.Writer/io.Reader interface (so it can be used to stream the binary data over wire or to disk)
i figure the way the varint encoder works it's just a little faster because it only adds the 8th bit to the last byte so that's potentially as much as 1/7th of this operation, not huge but ok, anyway it was required for the streaming read/decode anyway, to make a new one.
it's not on by default, you have to set BINARY in the environment to make it do this, and there is no handling for this - if binary false, it tries to decode json, and if true, binary, so to change over, you need to export the events, nuke or just delete the database files ( ~/.local/share/realy ) and flip it to true and then import the events back (and if you deleted, you want to re-set your configuration, you really should keep a copy of the configuration json that gets stored in the database for reasons like this).
it's definitely noticably faster, the binary encoder i am quite sure will prove to be the fastest nostr database binary encoder, and it's also extremely simple, and the results are about a 30% reduction in event storage size, and maybe 1 microsecond to perform the encoding.
#realy #devstr #progressreport
today mostly just finishing up polishing the rewrite, but this evening i wrote myself a nice HTTP path/header router and completed the publisher router
i'm aiming to make this thing as lean and modular as possible, so now i can make packages that do http handling (eg like the nostr nip-01 websocket API, or relay information page, or whatever) that lets them self-register themselves and disable registering them, optionally, by using a build tag on the source file containing the implementation
most likely i will roll that all into one base directory with a single file and build tag that pulls in the given type and registers it, and then the main relay will only call the router, which only will see the packages that got included by not being excluded from the build
learning a lot more about how to write http stuff in #golang - man, http routers are unbelievably retardedly simple, i just wrote a router, HBU? lol
no idea how much cruft i'm gonna be able to shred from the main realy codebase just yet, but this router i just made i know it shreds a big chunk of spaghetti and lets me isolate the parts cleanly... APIs will have their own handlers, and their own publisher, all linked to a main publisher, and then if the api is disabled, it just isn't used, and voila, legacy nostr, hybrid legacy/http or new-wave http
i also don't know how long this is going to take but it feels really good just sitting quietly and calmly and building this
or maybe this is #ragecoding
because when you are rage coding, actually you are in such a state of mind that you could cut shit like your eyes are frickin lasers
this is architecture work, makes my brain hurt the most haha
probably is gonna be a little while longer before i finish this task, but the end result is that it will be possible to compose custom relays easier the more spaghetti is untangled
meaning that it will be easier to add new features, also, without breaking anything or making more spaghetti
the relayer base i built from has lots of nice design features for customisation and modularity and i haven't really fully exploited all of it yet
like, extending the event store to have a full text index, for one, this is on my list of things to do because alexandria really needs it, it's part of the event store module and can be set up in each of the apis to make use of the new function
when writing stuff in #golang, it is pretty much the norm for most projects to start as spaghetti and then once you see yourself repeating yourself, you are supposed to go "hmm this looks like an interface" and then after brain-breaking spaghetti detangling, your code gets more and more clean and maintainable
i finally had enough today of trying to get the developers of https://gioui.org to understand that the internal packages they have in their repo obstructs the reuse of their widget code
this is now at last remedied
https://github.com/mleku/gio
aka https://gio.mleku.dev/gio (that's the proper import path)
with this, you can literally copy the `widget` directory into your own repo and fork it to do better and more things
this drove me so crazy for so long and today i just finna had enough
this library is the most competent cross platform UI rendering library, it works pixel perfect on macos, windows, linux, android and ios, and has done so for about 5 years but nobody has built a proper fucking widget library for it, the one they have in there is abominable and shitty
there's no proper tooltips, there's no popup menus, there's barely anything
there is other work people have done to build these things and they are nice but they are similarly retarded, and now i can easily fix this problem, and build a proper fucking GUI for #golang
oh yeah, and did i forget to mention it can be used as a GUI library for web apps?
yeah, all of these things
the people who are building it are insanely good at what they do, and insanely toxic to their fellow Go developers and in general fellow developers
Showing page 1 of
15 pages
