More precious than bitcoin dispite being proved by math.
I started listening to black sabbath and other metal as a teen. My mother was shocked and seeking professional help for me. 50 years later I can tell you it's a lot less about the music, and more about the people children associate with.
My kids at that age were listening to some rank rap. 20 years later I can tell you the bad associations they had were their teachers more than their friends.
I am here to embrace the chaos and I love it
# Nostr 2?
## Breaking Changes in Nostr
Nostr was a huge leap forward. But it isn't perfect.
When developers notice a problem with nostr, they confer with each other to work out a solution to the problem. This is usually in the form of a NIP PR on the nips repo.
Some problems are easy. Just add something new and optional. No biggie. Zaps, git stuff, bunkers... just dream it up and add it.
Other problems can only be fixed by breaking changes. With a breaking change, the overall path forward is like this: Add the new way of doing it while preserving the old way. Push the major software to switch to the new way. Then deprecate the old way. This is a simplification, but it is the basic idea. It is how we solved markers/quotes/root and how we are upgrading encryption, among other things.
This process of pushing through a breaking change becomes more difficult as we have more and more existing nostr software out there that will break. Most of the time what happens is that the major software is driven to make the change (usually by nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6), and the smaller software is left to fend for itself. A while back I introduced the BREAKING.md file to help people developing smaller lesser-known software keep up with these changes.
## Big Ideas
But some ideas just can't be applied to nostr. The idea is too big. The change is too breaking. It changes something fundamental. And nobody has come up with a smooth path to move from the old way to the new way.
And so we debate a bunch of things, and never settle on anything, and eventually nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 makes a post saying that we don't really want it anyways 😉.
As we encounter good ideas that are hard to apply to nostr, I've been filing them away in a repository I call "nostr-next", so we don't forget about them, in case we ever wanted to start over.
It seems to me that starting over every time we encountered such a thing would be unwise. However, once we collect enough changes that we couldn't reasonably phase into nostr, then a tipping point is crossed where it becomes worthwhile to start over. In terms of the "bang for the buck" metaphor, the bang becomes bigger and bigger but the buck (the pain and cost of starting over) doesn't grow as rapidly.
## WHAT? Start over?
IMHO starting over could be very bad if done in a cavalier way. The community could fracture. The new protocol could fail to take off due to lacking the network effect. The odds that a new protocol catches on are low, irrespective of how technically superior it could be.
So the big question is: can we preserve the nostr community and it's network effect while making a major step-change to the protocol and software?
I don't know the answer to that one, but I have an idea about it.
I think the new-protocol clients can be dual-stack, creating events in both systems and linking those events together via tags. The nostr key identity would still be used, and the new system identity too. This is better than things like the mostr bridge because each user would remain in custody of their own keys.
## The nitty gritty
Here are some of the things I think would make nostr better, but which nostr can't easily fix. A lot of these ideas have been mentioned before by multiple people and I didn't give credit to all of you (sorry) because my brain can't track it all. But I've been collecting these over time at https://github.com/mikedilger/nostr-next
* Events as CBOR or BEVE or MsgPack or a fixed-schema binary layout... anything but JSON text with its parsing, it's encoding ambiguity, it's requirement to copy fields before hashing them, its unlimited size constraints. (me, nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s)
* EdDSA ed25519 keys instead of secp256k1, to enable interoperability with a bunch of other stuff like ssh, pgp, TLS, Mainline DHT, and many more, plus just being better cryptography (me, Nuh, Orlovsky, except Orlovsky wanted Ristretto25519 for speed)
* Bootstrapping relay lists (and relay endpoints) from Mainline DHT (nostr:npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqz)
* Master keys and revocable subkeys / device keys (including having your nostr key as a subkey)
* Encryption to use different encryption-specific subkeys and ephemeral ones from the sender.
* Relay keypairs, TLS without certificates, relays known by keypair instead of URL
* Layered protocol (separate core from applications)
* Software remembering when they first saw an event, for 2 reasons, the main one being revocation (don't trust the date in the event, trust when you first saw it), the second being more precise time range queries.
* Upgrade/feature negotiation (HTTP headers prior to starting websockets)
* IDs starting with a timestamp so they are temporally adjacent (significantly better database performance) (Vitor's idea)
* Filters that allow boolean expressions on tag values, and also ID exclusions. Removing IDs from filters and moving to a GET command.
* Changing the transport (I'm against this but I know others want to)
## What would it look like?
Someone (Steve Farroll) has taken my nostr-next repo and turned it into a proposed protocol he calls [Mosaic](https://github.com/SteveFarroll/mosaic-spec). I think it is quite representative of that repo,
as it already includes most of those suggestions, so I've been contributing to it. Mosaic spec is rendered [here](https://stevefarroll.github.io/mosaic-spec/).
Of course, where Mosaic stands right now it is mostly my ideas (and Steve's), it doesn't have feedback or input from other nostr developers yet. That is what this blog post is about. I think it is time for other nostr devs to be made aware of this thing.
It is currently in the massive breaking changes phase. It might not look that way because of the detail and refinement of the documentation, but indeed everything is changing rapidly. It probably has some bad ideas and is probably missing some great ideas that you have.
Which is why this is a good time for other devs to start taking a look at it.
It is also the time to debate meta issues like "are you crazy Mike?" or "no we have to just break nostr but keep it nostr, we can't dual-stack" or whatever.
Personally I think mosaic-spec should develop and grow for quite a while before the "tipping point" happens. That is, I'm not sure we should jump in feet first yet, but rather we build up and refine this new protocol and spend a lot of time thinking about how to migrate smoothly, and break it a lot while nobody is using it.
So you can just reply to this, or DM me, or open issues or PRs at [Mosaic](https://github.com/SteveFarroll/mosaic-spec), or just whisper to each other while giving me the evil eye.
Suggest, tread lightly devs, or Mike might just drop a prototype that blows minds.
“The underlying and already highly successful strategy is to prevent Bitcoin from becoming a widely used P2P payments protocol that could threaten the fiat banksters MoE hegemony...and most Bitcoiners are blissfully unaware, bedazzled and diverted from revolutionary zeal, by speculative gains.”
https://stacker.news/items/807801/r/halalmoney?commentId=808309
Whales buying it up while minnows stack kyc. Rug, rince repeat.
Never measure quality by percent complete.
I like vivaldi. Has been stable. It's based on chrome source (as if that means anything). I use very few extensions but chrome extensions tend to work.
I'm far more about privacy than UX for sure: (ublock origin)
Now we know how easily people are manipulated. I will never forget.
Can anyone tell me what relays support long form content, nip 23 ?
I agree, this is a great read.
It's a question of trust. If you cannot verify, how can you trust? Nostr is small because the pool of people who do not blindly trust is itself pretty small.
In the corporate world the leadership still insist that it's ok to trust apple and microsoft. I used to carry the belief that trust should be extended until broken but over time have found that to be naive and foolish. Yet we continue to slave for fiat and contribute to opaque problems.
People who appreciate nostr are a different breed and are not likley to gulp down the algorithm with the coolaid.
We don’t need influencers with giant audiences, we just need good content that keeps people around.
-Karnage
Quick Start Guide to Getting Your US Ham Radio License
1. Use HamStudy.org: HamStudy is a free website that provides practice tests for all ham radio licenses. It can help individuals prepare for their exams and find online or in-person test sessions. www.hamstudy.org
2. Check Out W4EEY on YouTube: W4EEY on YouTube offers excellent ham radio tutorials. He has playlists covering all ham radio license levels and occasionally conducts live classes. This resource can be valuable for learning ham radio concepts. Here are the playlists for the various licenses:
• Tech Playlist: https://youtube.com/playlist?list=PLZ_9BZQ8gpziUWPBT3rOvSV6MCCeCaiK0
• General Playlist: https://youtube.com/playlist?list=PLZ_9BZQ8gpziv2a26B_IoQ1RbXbIqieP2
• Extra Playlist: https://youtube.com/playlist?list=PLZ_9BZQ8gpzhKG9Ha27YL9szWqBTmlYwU
3. Explore ARRL and Local Clubs: The American Radio Relay League (ARRL) website can help individuals find local ham radio clubs. These clubs often have information about local repeaters, club meetings, and ham radio "nets" (radio meetups). It's a good way to connect with other ham radio enthusiasts in your area. (https://www.arrl.org/find-a-club)
4. Phone/Tablet Practice Test App: The hamstudy.org app has recently been updated. They did a really nice job with it. It’s a couple of fiat dollars, I think you will find it is worth it. https://hamstudy.org/appstore
#ham #hamradio #license #arrl #gettingstarted #amateurradio #radio
or discover #freeband
Wouldn't it be interesting if Trump decides to take the gloves off?
Proof of reserves? Now we're getting somewhere.
The only thing this (meme) says to me is, the margin of error on polling is greater than the margin of error on cheating.
A Free as in freedom alternative to DNS is as worthy for development as the relay itself.
My question to the devs is, have you inspected the frameworks and libs you use? I may write a lot of stingy php, but at least I know what it does.