#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
just sayin, they also left out the koblitz version of P256, which is our known and loved secp256k1
the propaganda campaign against the koblitz curve was incredible, yet somehow they have given ed25519 a pass... which smells pretty fishy to me, almost like, they KNOW that the koblitz curve is even more secure than the edwards twisted curve
the only solution, as i see it, is a noise protocol implementation that uses sha256 and secp256k1 for HMAC, and i started on building one for #golang
i already spotted this egregiously obvious manipulation in the "academic" scene years ago, and i'm pretty sure that nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 picked bip-340 secp256k1 X-only schnorr signatures for #nostr
you know why i don't trust edwards?
because all the shitcoins used it
because your precious fucking rust favorizes it
funny how still there is no viable shortcut to bruteforcing bitcoin's koblitz curve group now isn't it?
nice to see that you are thinking about this though, welcome to the NIST cryptography skeptics club
#golang #devstr this is the best #openapi tooling i have found
https://github.com/danielgtaylor/huma
my vietnamese colleague who does smart contracts and backend servers in javascript uses some whizz-bang thing that lets him define the openapi spec in native code
this is not what you expect when you first are looking at this swagger/openapi stuff, you see "needs a spec written"
the dude literally didn't even know this was a thing, how bout dat
i had to figure all of this stuff out for myself and i spent since friday trying to make one of the toolkits for it work, i tried swagger 2.0 i tried openapi 3, i tried like 4 different generators, all of them shit, except go-swagger, which locks you into an extremely limited framework that is hard to poke normal fucking things into without making it painful
huma just does the job... literally just declare the function as a closure with a struct defined in situ and voila, wham, bam, thankyou ma'am, here's your json formatted spec and web GUI available at /docs to boot
everything else has been a nightmare, i hope that i can move forward quickly with this because the people at my fiat mine think i'm incompetent even though i have literally written the almost entire underpinning of the server that i was assigned to and none of them can even understand how a recommendation engine works, and it's like, uh
:cry:
it's just a thing that mines user data and compares profiles to find similar profiles and then uses that to make evaluations or suggestions based on it
well, anyway... it's a job, and it gets a bit frustrating at times being a back end dev, i have successfully won the bounties on several grant projects last year, despite incredible obstacles (mostly nostr obstacles) so now i'm moving towards more generic stuff, and coinciding with it is that i can now apply this knowledge to finally implement the nostr http api
once they see the heroku endpoints up and running (and omg don't get me started on heroku what a shitshow) they will start to understand
what's even more annoying is that they think i'm going slow and it's taken literally 4 weeks for the front end and back end guys to add like 4 small things and they aren't in production yet so i can't even test my algorithms on live data, so i'm trapped here in disregarded land while i can see what i have done but zero others can, i'm literally the only person in my company who can write an advanced algorithm, and this what i'm doing now isn't even nearly as complex as what i have done before
the json data format shit though, i hope i'm gonna bump into some tricks to speed up how fast i adapt to their shitty lack of typing because the Go native json parser turns everything into generic interfaces and slices of interface and this means i have to write manual code to identify and unpack all of that to put it into strictly typed data structures
and they think it's slow doing 400 million comparisons, created by the (n-1)n pattern of a recommendation matrix
anyway, just venting but now time to hit this huma and regain some of my humor
today i am learning how to actually write a full, proper #http server using the #golang standard library for handlers and multiplexer (router)
looking at all these silly things, gorillamux, go-ch, and i just wasn't even considering gin and all the rest idgaf i want to learn the base of this, i already have code that does this shit but i need to integrate this generated openapi 3 API i've designed correctly
i'm doing it for #realy first, but next week i literally have to do this exact same thing for my #fiatmine job, so i'm killing two birds with one stone today, once i figure out how to plug in this generated code, then clients can be built from the same spec via code generators, which massively reduces adoption friction - i mean, this is why REST dominates the industry now, and it's really needed to eliminate adoption friction for #nostr because the way it stands right now, the SDKs that exist are awful, inconsistent, inefficient, and usually buggy NDK i a bastard piece of shit, so i'm told, and my colleagues have forked it and are superseding it with WASM based C++ generated code
what i'm building here will be a huge icebreaker for nostr apps to integrate with web 2.0
i'm not so much concerned about the lefts running their own relays, idgaf about what those drones are doing, but what i am concerned about is leveraging the eventbus/pubsub architecture of nostr to facilitate real world deployments and have people paying nostr devs to build this stuff, instead of begging from bitcoin whales
i just spent much of today and yesterday afternoon learning to write openapi specs, and i have built out a whole thing now, got it generated, not sure if it's exactly what i want, gorrilla/mux, but i am always hearing this name so ok trying that first
found a nice tool to serve up an embedded swagger UI through it, i was horrified to see that it was 11mb for the standalone distribution (that doesn't depend on NPM's servers) but ok, this is not unbearable, a little slow updating but i don't think i particularly care about it being more current than 5 months ago:
https://github.com/swaggest/swgui
so i will now have a generated, easy to make clients with it API interface for this new nostr HTTP interface i'm building, and people will be able to poke at the API without having to leave the comfort of their browser
also did i ever mention that i don't care to submit a PR about what i'm building? that's right, because this thing has its own documentation endpoint and every instance of #realy will be serving the docs of the version of the spec it uses
no need to wait forever for a bunch of bikeshedding to go on and someone to decide "oh nah, we don't like this" even though i've got another relay dev colleague using it and three client devs deploying it in their app
flinging cats into nests of strutting pigeons perched on chess boards they think they have had victory on is my idea of fun
#devstr #swagger #golang
#devstr #progressreport i made some fixes to #realy today
instead of blocking clients asking for DMs when it's not authed, it sends auth and just doesn't return them until it gets auth
in many cases, clients do that after i post a new note because the nip-11 says "restricted writes" and that makes them actually auth and once that socket be authed, i can read my messages, not that i use them, becos they don't work, nostr DMs are a joke because nostr sockets are a dumb idea and no client hardly barely implements auth properly still and the specification is as transparent as the lower atmosphere of jupiter.
anyway, so, there seems to be some improvement, jumble is now happily posting and fetching notes properly again after it was broked for a bit of today
i'm feeling quite exhaustage also
on other fronts, i am close to finishing the JWT token verification, i am just gonna say that the #golang #JWT library is horribly documented and i basically had to poke at several things before i even could read a clear statement that i needed some function to return a goddamn key
yes, that will be the one that fetches the 13004 event if it finds it, and decodes the pubkey and then uses that
just writing the test at this point, using the key directly from the generation step
compared to the btcec/decred bip-340 library, the API of the conventional "blessed" cryptographic signature algorithms are a pile of dogshit covered in shredded car tires that has been set on fire
you think there could be anything more stinky than a tire fire? yes, a dogshit-and-tire-fire... that is the state of "official" cryptography, compared to bitcoiner cryptography, which is sleek and svelte and sane
no, i'm just kidding, bitcoiner cryptography except the C library is abominable, because roasbeef is a jerk who has repeatedly stopped me contributing to either btcd or lnd because he is a smartarse jerk and you know he's a jerk because he isn't here to ask me for an apology
fuckin assclown
idk how he came to have anything to do with the invention of the lightning protocol but i'm sure as fuck certain it was only that he built LND and nothing more, because his code is awful, beyond awful, and i hate him also because he doesn't seem to care that his repos don't have working configuration systems
anyhow
probably i will finish making the JWT auth scheme validation code tomorrow and then wrap it into the http library and voila, normie clients with a token will be able to access auth-required relays without either websockets or bip-340 signatures, instead, a revocable key token bearer scheme that lets another key stand in for the auth purposes
also, did i mention that roasbeef is a dick?
i would love to have one of his fans rebuff me, that would make me feel like i actually had an interaction with him that wasn't him stopping me doing useful things for bitcoin
Showing page 1 of
14 pages
