nostr:nprofile1qyfhwumn8ghj7mmxve3ksctfdch8qatz9uqsuamnwvaz7tmwdaejumr0dshszxthwden5te0dphkgmrzdajzumn0wd68yvfwvdhk6tcqyztuwzjyxe4x2dwpgken87tna2rdlhpd02va5cvvgrrywpddnr3jyhdw0my i can't add #devstr to my feed filter, it shows it, i click it, it disappears

i got an aquarium heater today, at last, which i had planned to use to keep my yogurt brews at a perfect temperature

it tops out at 34'C but i think that works out fine actually, just funny, because of the acoustics of the pair of plastic tubs i got for keeping this thing contained, when the heater is heating the sound of it heating the water makes a distinct quiet rumble

yogurt brewer goes "MUMBLE"

hah, i had been in a habit of not drinking beer and had some stout for lunch instead of wine

now my toes are cramping again

direct effect, clearly blood sugar and this cramping problem are related

going to make 3 cups of yohimbe tea for today to counteract this error but clearly best if i avoid high sugar foods altogether

salad was fine, tomatoes, onions, carrots, etc... maybe i'll tone down the carb element in this recipe because i did not expect the cramps to come on like this

i remember reading years ago about people who had cramping disorders like this, and the cannabis legalisation thing, and about how they got really severe cramps that if they got a joint as soon as it started it was done

well, now i wonder if that's because cannabis influences blood sugar levels and stops the agglomeration of amylose around the nerves that creates an effect that is similar to when you get a burn, and the pain signal keeps emitting even though the actual sensor is dead

like the amylose chokes the nerve, and makes it like it is dead

sure would explain a lot about alzheimers too

it's literally monetizing garbage, instead of paying for ethical disposal

biggest red flag you have you are living in a totalitarian system is that efficiency takes second place to policy

i hope that in the near future there is a crisis with lithium battery supply and people realise that you don't need wireless connections if your power provides a network

there is at least 100mbit bandwidth in a typical domestic house electric wiring system, it's got some VERY thick conductors to carry wattage and that dramatically reduces signal loss, and if every device that you plug into the wall was also talking through it, the available capacity for wireless connections would be dramatically increased for when devices are untethered

why do i need my phone to be not sitting on the charger while i sit at my desk exactly?

what is the logic of me having a laptop with a fat battery in it when i only use it at my desk?

there has been a lot of deliberate promotion of both wireless and lithium battery technology for no reason, and a deprecation of wired networking solutions

even AC/DC adapters could be interfacing with a 100mbit ethernet on your house wiring

probably the speed of this network is even better now with all the fancy signal processing techniques that exist

imagine you plug your computer in and instantly it's online

you plug your TV in and the android or whatever OS in it is instantly online

you plug your phone in and it turns off the radio because it can do calls over the wire, and if you unplug it to pace back and forth, it switches back to mobile wireless or your house wireless, whichever is the least RF energy

efficiency is not in the agenda, people, or that's how it would be now

i personally think that if you go look at my version of go-nostr

https://github.com/Hubmakerlabs/replicatr/tree/main/pkg/nostr

you will see that i am in the process of ordering the protocol by human readable concepts and far more clear than the existing shomozzle based on this stupid RFC derived number specification shit

i'm not against the numbering of the specifications, per se, so much as not having a cohesive map of the architecture of the system that keeps things related to each other

you will see as you dig through the code how i have reorganised go-nostr that the majority of the protocol fits into a set of simple concepts and some have branches on them, like envelopes, which are the nostr equivalent of API messages

i think that the protocol will advance a lot faster once people start to tie together the specification better and have an easy reference to work on

hell, after i'm finished my current assignment, i'd be very happy to write the documentation that ties everything together with lots of obsessive hyperlinks to the NIPs and even their historical state to help devs really wrap their heads around it because it really is a lot to learn and the structure is contrary to easy learning

if you can point me to someone who lets me buy leite de cabra in batches of 60x1L and goat meat that has been properly hung and dried (not immediately frozen and full of blood) i'd be very interested to engage with this person and do some business

might even prompt me to start running a LN node

it's a concurrency problem btw, that's why monorepos

every time you dissociate two things that are running in parallel and interacting you have to deal with synchronisation between the two processes, and if you don't you have a mess

yeah, big flat open fields of land worthless for anything else will do that

the romanians have a huge stretch of this kind of flatland too but it's full of oil

i hate monorepos but for Go the trial of constantly updating the go.mod if you have two repos that are interdependent or one dependent on the other it's a lot of rigmerole

compared to just keeping it together

once one part becomes stable you can push it out and any further patches later on will be small usually, and not so onerous as every time you are changing each one in parallel

having to make sure everyone who is working on one side knows what is happening on the other side

until a cluster of libraries are tested, stable, and the client is using them adequately, monorepo is the way TM

actually, i think they are also sending tractors to make sure the grain price in europe is dumping to squeeze the farmers more

every time i see shit like this in my relay log:

1707988939.657543829 trc sending event to subscriber 206.83.102.98 '{"id":"39037342810a100b9268a17039854b63102b9f2cf8d0d1ed12cbc755ace677a3","pubkey":"4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f","created_at":1707988939,"kind":30078,"tags":[["d","nostr-engine/Nip24/last_checked/v1"]],"content"

it reminds me how much you (except @hodlbod and the #nostrudel guy) all client devs aren't implementing NIP-42 and how that data should be private and i can't force my client to ask for auth without breaking DMs completely

that's my goddamn application specific data being sent to some rando on the internet by my relay because i can't force NIP-42 without breaking most clients

come to think of it, maybe i can bring the NIP-42 back, since i now have succeeded in running coracle i think screw all the other clients, get with the program, my relay is not gonna give out DMs to you until you get it right

just not a first step, always, make it work, then make it secure, and never forget to do step 2

#devstr

a little tip for those of you here in #madeira especially if you plan to stay a while:

chip7.pt seems to dispatch your orders directly from china or something, i'm at now almost 2 weeks waiting for an order

worten.pt will usually fulfill the order within a week

chip7's site has slightly better organisation for filtering to find what you want but i'm not sure it's worth the wait when usually everything i want can be found for 1 week delivery time (uma semana)

for all the C, C++ and Rust programmers:

this is why we #golang

#devstr #meme

i see the problem in your seeing the problem: you aren't actually addressing the issue at all, thanks for your help

we are imperative programmers over here, we don't comprehend your unnecessary abstractions

you have bad taste in programming languages but this is a fundamental also to bitcoin as well, indeed lightning hasn't broken old stuff very often either

in many codebases you will find things with the term "quirks" and even in bitcoin there is quirks in its handling of JSONRPC2 that have to be accounted for in case you are interfacing with an old version that does different stuff

the escaping of strings is a good example

*uncompressed keys

btw, don't depend on replicatr's pkg/nostr folder yet, it's not stablised, for example just now i refactored the inconsistently ordered compute shared secret function in nip4, as in my library and in most ways of discussing ECDH you say My Secret Key, Your Public Key and the nip4 fiatjaf fiasco has it backwards, there's a lot of other little subtle things i change like in my ec library you can use the more logical and easier to shorten "secret key" instead of "private key" versus "public key" that pattern doesn't leave you an option for shortening it, sk/pk is more logical which derives from secret/public

i have yet to clean up that nip44 encryption/message formatting scheme yet, it's horribly written, as the audit points out it does no bounds checking on the keys derived out of the hex, not even checking the hex is the right length (which would be sufficient and make more sense to check before doing the work of decoding the hex)

i just am directing you to look at it because it will show you how to do the BIP340 nostr style signatures correctly

my work is not finished yet but it has been a while since i've made more than two small changes in that pkg/nostr folder in a week, so i think once i hit my current milestone target for an MVP relay i'll be pushing it out into its own package on my git hosting

another thing you need to know as a go programmer, if you are writing an app, and developing a general purpose library or ten at the same time, don't separate them until the libraries are unchanging for a substantial amount of time because it's a huge pain to keep the go modules synced up

also, no, an uncompressed ECDSA key is 64 bytes, a compressed key has only the sign of the second coordinate, only two are really needed, which is 33 bytes

65 bytes is not the length, that is a typical signature, i could be wrong, maybe there is a type byte for uncompressed ones, i never deal in uncompressed signatures as they aren't used in bitcoin, lightning or nostr

anyhow, point is if it's uncompressed pubkey then it's redundant to include any more than the 257th bit, the sign bit from the second coordinate