i may need to make a separate repo for my reverse proxy now
i'm about to add into it the capability to listen on a non-internet address... so yeah i might make it refuse to use anything but 192.168 and 10. actually, why not, so it should be
making the reverse proxy able to not only bounce traffic around to arbitrary network addresses connected to the server is cool, it lets me do nip-05 and #golang vanity import redirects, but now also to act as a full blown VPN, is kinda cool, i mean, it's not really a VPN, you have to configure your wireguard tunnel independently, and then set it to listen the socks5 port on it, this makes it something more than just a side project i'm doing, and i should pop it out and make it more prominent
what will make it different is that it already has LetsEncrypt and custom SSL certificates (i added this because letsencrypt started jerking me around with making subdomains and wildcards) is that it will use that SSL/TLS capability to present an SSL capable address, as though it was something like, for example:
https://realy.realy.lol which would be on port 443 and needs to have an SSL certificate with either that literal address baked into it or a *.realy.lol (which i have) and then decrypt those messages and send them over http to the relay, which only sees http without encryption, over localhost, in this case, as it only listens on localhost or wireguard VPN addresses
HAHAHAHA ok shit
i just figured out that i already had the relay listening on http on the public IP address on some given port... i hadn't seen any traffic that way, because web clients dun like http and i didn't advertise it, but ok, now it's closed up, reverse proxy is now only forwarding to a localhost to the relay... nice catch! as they say
nah it was really no big deal because the relay requires auth and stupid to be them trying to use it without security over the internet these days, relay doesn't send out any traffic that isn't already going out over to public relays anyway
but it's fixed, anyway
anyway, so, now, i'm going to migrate this repo to its own, probably https://proxy.realy.lol with a go vanity redirect and add to it the ability to act as a socks5 proxy and thus let me add address rewriters to it that forward fake imaginary IP addresses to configured paths using the neat mapping syntax that it already has, just gotta think of a way to signify that it's a socks redirect
this is fun... anyway, the end result of this is going to be that it will let me mod nostrudel to use a non-localhost , but private IP address as a fake address that will forward to my actual relays (either my test, which runs on my pc here, or to my production relay, which runs on the VPS alongside the reverse proxy)
what it will do is enable me to make a "fake" DNS name for my relay, and set that as the address in a fork of #nostrudel and this will make my personal relay on my VPS into a full blown cache relay for nostrudel
it's a small step, but with the proxy it actually enables someone to do this back to their own home PC with a relay running on it, that appears to be a HTTPS capable relay but because of the fake DNS nobody else has to be able to see it, because i can rewrite the address ...
damn, i don't have this straight in my mind yet exactly
ooof
so, anyhow, long story short, because dev.coracle.social ate my last attempt at posting because i accidentally pressed something that changed context
the javascript runtime for #WASM on #golang does not have support for writing to files, or filesystem path mapping or anything
there is polyfills to enable this with wasm code but to make it transparently work with Go code that is using the os library filesystem access code is probably a non starter at this point unless i'm building it from scratch and can abstract all of that stuff, anything that uses os library direct, nope, would require a fork of the go stdlib to achieve that
so, for now, making my #realy run inside a browser would mean heavily modifying badger to be able to work with the hobbled js/wasm runtime filesystem access correctly
nobody has done it yet, but on the other hand, badger now has fragments of code involving supporting the js platform which means they probably are going to eventually do this, maybe next year, maybe the Go project has work in progress to enable filesystem access in the WASM builds
for now, only with WASI (eg wasmzero) and only under nodejs, not in a browser
so in practise what this means is that i could run #realy in a browser, if i created a network enabled event store and was able to tunnel access to it through a public routeable address
that's a lot of rigmerole
i'm going to stop this madness now, nice idea, but basically not gonna happen without me writing a whole frickin database that is hip to this silly platform
i just finally achieved something that i had been trying to figure out how to do with configurations since forever
enabled them to be composed together
right now, i am finishing up a rewrite of #replicatr and i didn't want to make maintaining the distinctive, likely to change parts, painful
so i can now drop in the #realy config into the replicatr config struct, and inside realy there is now config features that transparently compose the two data structures as a flat list, the same way as #golang compositing works (the embedded struct's fields are shadowed by the struct they are embedded into) for the derivation of the key=value list that is in standard env format (can be used with the env command i suppose, or loaded into the Environment field of a systemd unit
this allowed me to override the default app name and profile directory that exist in realy's config, with the replicatr version, that uses the name derived from the overridden app name (default replicatr)
within my code now, i can transparently refer to the composit structure already, that was the easy part, but now i can input and output it from a file, or the environment, as well, with a minimal amount of code to maintain for it
plus, for bonus points, it automatically sorts the environment variable list alphabetically
conveniently the `go-simpler/env` library seems to already know how to deal with a composed config struct so it works utterly flawlessly
this is turning into the best configuration system i have ever used for Go apps, at all
about the only thing that i don't think i've fully got perfect now is being able to one-shot override config values by assigning them in the command line invocation prefix... you have to either use the file, or use an env command to pull them in independently and read out of the launch environment, both don't work at the same time
there is reasons for this, that being that it interferes with default values, when you haven't got empty fields you have to ascertain if they are modified from default and that can even be made empty, and then deciding if the outer layer has been made empty, do you wipe out the inner layer, etc etc
i don't think there is a simple way to resolve the problem, so, either you set the environment first, and then launch, or you use the inbuilt env file reader, that sets the environment
i think there is probably some detail in the 12 step app design or whatever that thing is ... 12 factor blah blah lol
anyway, i have had extensive intimate experience with how easily this shit is fucked up and i want it simple so it doesn't interfere with the actual juicy parts of the work!
especially because probably even still today btcd and lnd both have godawful messy configuration systems that don't even work properly from the files, and probably the reason is exactly what i say... how do you composit it when you need to account for environment, flags, AND configuration file, what a mess...
no, one or the other, i say, and forget the flags, you can make simple positional parameter subcommands with very little code
flags suck, subcommands rock, env > positional > parameterised
so i use env, and for subcommands positional
covers 99.999% of bases with far less code and things to go wrong
i know that your training in the greatest programming language #golang gave you an instinct for making use of implicit things instead of forcing constantly to use explicit statements... it is the same with websockets... you can just trust that it was received if it was not timed out, the whole point of TCP, in fact, is all about eliminating this double checking from having to be done at the application layer
and also the way you designed the main protocol envelopes, making use of the ordered, non-set property of json arrays, this bamboozled me at first with the # prefix for the tags but why add a [], when you don't need to, or set up complicated logic about when you wrap it or not wrap it - it's just like the terminal variadic in Go function parameter tuble syntax (and ironically, a smart contract language called Move, based on Rust, literally rips off Go parameter/return and assignment tuple syntax, and rips off numerous other great features of Go that i don't feel utterly raped by Mozilla to use it
i also have this problem though i choose #golang
blockchain tends to help and go isn't abominably unknown, and whenever someone needs middleware or such it's the go-to
for systems programming its all rust, rust, rust, and yes, you guessed it, rust... since 2021 this is the new thing
i think you need to have a second string, and for me that is "blockchain" which is a proxy for my knowledge of distributed systems in general... i understand your love of your C but it's really hard to get serious C work out there these days and Go is a really natural move to expand a bit, you'll feel confident enough in a few days to pretend you are good at writing middlewares and they won't know the difference and the truth be told they almost never find experience, and you have quite some so actually don't be put off by the bullshit
just don't waste your time learning javascript if you are a systems programmer
worst case, you do some Rust tutorials and wing it
Move is actually quite an interesting language... for a database scripting system...
i think that its semantics could definitely be more concisely expressed in a syntax more like #golang but there is a lot of things in it that it deliberately makes explicit whereas in Go they are implied... like, the `interface{}` implicitly can be nil, and that is a different nil to the nil of a specific type...
in static typed languages in fact all variables are two-fold values, there is the type indentifier, and the value... and the value can be a type of pointer, as you see with slices and maps
dynamic typed languages also maintain this but they basically hide the type handling part in the syntax, which is why it is a Bad Thing ™️ - and very often reflection is left out or hard to use and ugly in dynamically typed languages, and at the best of times reflection is nasty, this is why a language tends to select a set of essential aspects of types being exposed to built in functions
i'm probably going to have a low key small bit of fun figuring out how to do useful things in this language, there are two tasks that are on the table for me, one is maintaining a port that uses a different framework, and i've now got a basic run over both but i won't be able to really fully absorb it until i see it in action and get to understand the differences in how to do the same thing in each framework
the other task will be building a middleware that acts like a cache/protocol translator enabling users to transparently use identities from different database systems (*cough* blockchains) and access data that may be on other databases, seamlessly to the user
well, i am getting paid to learn, in a big part of it at the beginning, that's fine, i appreciate what the designers of this language have set out to achieve and it's very interesting, definitely one of the better systems for managing a collection of users and attached data (aka "assets") and our project is for a game collaboration system, ie, chat and matchmaking, but it seems to me like this language would be also quite well suited in general to creating full blown simulations, like my favourite game Kingdom Two Crowns, and the old Settlers and Populous games also would be fitting use cases for this kind of hard ownership protection based language constructs
for sure it is going to feed into my growing and improving understanding of how to design programming languages, and contrasting it with the design of Go is quite interesting... like, i can kinda see some sense in certain aspects of it, especially the notion of scope of ownership of a piece of memory, this is really intensively micromanaged in Rust and they have loosened it a little in Move by dramatically simplifying what you can actually store (which is, not that many things actually) but the idea of capabilities, as it is in Move there is "key", "copy", "drop" and "store"... this extra attribute of a type has quite some interesting possibilities for ensuring that memory does not get stuck in a limbo where it's allocated but no threads are anymore owning it, which means the GC can then delete it and reuse the memory
but on the other hand, why it's a bit complicated is that if data is on the stack, it is implicitly in scope when being used, and dropped when you return, all that is required is to pop the stack to the point where the return address is stored... but if it has to get allocated on the heap... this breaks the model because the heap is a kind of background process (garbage collector/memory allocator) owned part and this is where you then would need to automatically track its scoping and thus the garbage collection mark/sweep process
anyway... time to play some games for a bit and probably actually start to try and apply what i've learned
as an aside, while i got some issues with stuff about this work, it's work, first of all, and secondly, Move, the language of Sui and Aptos are basically languages with a lot of syntactical and project structure similarities to Go (packages, mains)
they have a far reduced set of basic data types (basically unsigned integers and strings) and
use tuples in almost exactly the same way, with a bit more braces than Go
they don't have objects \o/ fucking hate objects and
the only thing that i still hate about it is all the generic syntax, because if they'd used compositional structuring it would be a lot less verbose (the number of times you have to repeat <TopLevel<Instance>> throughout the code to make a thing generic is sad
still, my point here is that i'd rather code in Move than Rust, C++, Javascript, any day without question, if I can't work with #golang
the good news is, aside from actually learning how to work with the blockchain crap of Sui and Aptos, i should be moving on from working with Move at the level of managing and completing a port from Sui to Aptos, and then building a middleware, or, basically, "gateway" server, which essentially acts as a cache and shim between the front end interface parts of the system and offloads the replication from the front end so that one front end can interact with multiple back ends (ie, smart contract blockchains)
which means after a month or two of working with Move i'll be able to move back to what i prefer, which is Go, and get paid good for it... and hopefully as the bull proceeds i may even get a pay rise next year
almost all of the "popular" mainstream languages share a common feature...
every one of them, nodejs with node_modules, rust with target, move with build, and there's probably others i am forgetting, literally copy almost the same big giant set of standard library code into that directory
if the disk had deduplication capability, i guess that might not be so bad, i think that ZFS has that, but i'm not even going to talk about this Unix :TM: bullshit because they deigned to force a whole different CLI API on us to just access them and since i don't need to learn this to use ext4 or btrfs, in the basic use case, fuck them, what the fuck were they thinking not binding it into mount and fucking fsck???
so, if i've been working for a while on a hundred projects or more, my disk has to have this many copies of the standard libraries, plus all the other dependencies that each one pulls in, and very often, in most languages there is dozens of more libraries that are basically de facto standard libraries, and pretty much will be stuffed in that directory for you every last one
of course, Go doesn't do this shit... in $GOROOT/pkg/mod there is a folder with version namespaces on each version of everything that everything you have ever used lives, and you can remove all of it with "go clean -modcache" or some command like this
every time you start a new project in these other systems, first step includes DOWNLOADING AND WRITING this shit to your disk. AGAIN.
if you think #golang is not a good language or toolchain, maybe that's because you have more money than brains
Showing page 1 of
12 pages
