👀 #SovEng

nostr:nevent1qqs85yw72h69u70l2mfaqju8hzelmfzu68f26ktr9mftvju7nyg284qpzpmhxue69uhkummnw3ezuamfdejsygzxpsj7dqha57pjk5k37gkn6g4nzakewtmqmnwryyhd3jfwlpgxtspsgqqqqqqscvhauk

Reply to this note

Please Login to reply.

Discussion

Glad to see some more people joining the War on IP.

i spent almost a whole year on this subject, based on a source routed model derived from LN's routing scheme and i can tell you that it's not anywhere near a solved problem how to do it, and to do it with reasonable resilience is going to amplify the bandwidth cost massively, and that means it has to be spam protected

What about the idea with integrating #reticulum and #meshtastic?

i don't know anything about reticulum, i use wireguard that's it currently

i just read a heap of the waffle on the reticulum site and my conclusion is that it's some kind of alpha grade version of ... damn... what's it called... was some network protocol with this idea of moons and stuff lol...

it didn't go very well and it was a project with a paid base and central directory problem, though you could use it... what was it called... damn... maybe you will know the one i'm talking about

but honestly, i don't get what reticulum is trying to achieve and i don't understand why it's written in python, this is not a language renowned for being good at handling bulk data or network connections let alone both at once

Nobody knows how to program like a man, anymore, that's why Python.

go is the best language for network handlers

it's also the best language for web services of all kinds, and is becoming one of the predominant languages used for this

unfortunately even though it's a very easy language to learn, using it properly is no less complicated than any other language is to just learn, people screw up concurrency all the time, our fiatjaf has made a mess with khatru, i know because i'm cleaning up that mess in my forked version of it

https://github.com/indra-labs/indra

this is the codebase i refer to btw... i didn't get it closer to production because of various reasons one of them being that my sponsor for doing the work was insisting that i change the path length to be variable instead of the baked in 3 hop protocol i had written

there was another issue that was outstanding too but i don't get paid to build it anymore, it's just there in case you didn't know it existed

one of the key things it implements is a more compact version of TLVs like used in lightning - because some events have rigid structures it can leave out parts of the header data like the L field especially as certain message types were fixed formats

without a scheme to pay for it it's gonna be bogged down with spam, and no, PoW isn't gonna solve the problem forever (tor project has kicked the can with their use for rendezvous routing) because eventually someone will find it valuable enough to overwhelm average user hashpower to push spam without any recourse for users or on the network

i've worked on a huge codebase, over 20k lines of code for doing this and it's not a simple task to implement, and we still haven't got clients supporting NIP-42 yet

also, aside from everything else, this is outside the domain of relaying in an architectural sense, you are essentially proposing to turn relays into a network transport