I'm tired of hating the state.
I love the state now. Not only is there nothing wrong with how the fiat-centric state is run, it is quite simply not powerful and oppressive **enough**. We need more.
Also if it accumulates all the Bitcoin by stealing it from Coinbase, that's for the best. It means it's in good hands. And if it scrapes all our Nostr notes to put them on AWS servers to track and trace every nym, that makes the internet safer.
I ♥️ big state.
Jay
_@wisehodl.dev
npub10mta...27hf
Vedic Seeker | Martial Human | Bitcoin Maximalist ⭕
———
Software Engineer #python #golang #typescript #react #rust #elixir #neo4j #bitcoin #nostr
———
"We hold ourselves aloof from the dust of polemical strife." —John Gall, Systemantics
———
Listen to #SOFTWAR 🇺🇲: https://fountain.fm/show/dqYmpfWuMQ10OXOsNvyv
———
Read #SOFTWAR 🇺🇲: https://mega.nz/file/D0hzgCpb#qo07-vUqP-0YkjUKt92ioPNzo08ayEu3RwvWfsXRH8w
If you're interested in FIPS and see it being the future of p2p mesh networking, I encourage you to push for a high standard of code quality in projects you hope to survive in the long run. FIPS has a lot of potential, and well-structured, maintainable code can help it succeed. View article →
FIPS looks like a fantastical dream right now.
They say that a general law of systems is that a complex system that works just evolve from a simple system that works. And a complex system that doesn't work can never be made to work.
The success of FIPS will depend on how disciplined its developers are in keeping it as simple as possible. But with so much of the code being written by AI, I am not very enthusiastic about it. Pair that with the fact that it has to be private and secure puts even more pressure on it to remain simple.
Software bloat will be its biggest enemy, in my opinion. Only the developers and Claude will understand how it works and how to fix it if it breaks. For a base-layer sovereign networking technology, it would be nice if it was independently maintainable rather than centralizing that risk on a monolith repository.
Looking at the code, the node orchestration module is the most complex and the most intertwined. If there are problems down the line, breaking that down into smaller, more maintainable chunks would be prudent. Better yet, separate repositories for each target runtime with a shared core, and a separate e2e testing repo.
@FIPS
No one has ever made a decision based on pure logic or reason. But it's comfortable to think so.