Last Notes
The US is oil independent. And they are willing to take a lot of pain to stay on top, even if it means the whole world takes a lot of pain. Military primacy supercedes other concerns. I think taking the THAAD from S. Korea was because they have to make hard choices, and the active war is currently in Iran.
Nonetheless, since I wrote this, nobody has mined the strait. So my comment is, for the moment, moot. Iran controlling who can pass by other means is the best option for Iran.
Iran is starting to set up decoy hospitals.
Also, the operation in Venezuela happened first to make sure that their oil can't substitute for the gulf oil being blockaded.
I'm starting to think Brian Berletic is right. And I think Iran has no good reason to put mines in the strait, because it isn't a reasonable threat of deterrance against a superpower that has plenty of oil (22m barrels a day, second is Saudi Arabia at only 10). And Iran has no good reason to destroy oil infrastructure in the gulf, only to destroy US bases there. If mines show up in the strait, or gulf oil assets are hit, I think that is US forces doing it, perhaps Iraq. The one who benefits from the strait being closed is the US, and the ones who suffer is everybody else and especially China who still gets 20% of their energy from the gulf. Blockading China at the 2nd island chain seems to have not worked out (China too on top of that one) so this strategy of shutting down the gulf and blaming Iran is Plan B. And also, Israel doesn't control the US, it gets attacked by missiles on behalf of the US, same as Ukraine does. Now of course Netanyahu is a homocidal maniac, and there is a greater Israel plan, and this stuff dovetails together, I didn't say otherwise. But I think the US faceless policy people are running the show and Trump is running the distrations.
Many people hold to the notion that modern disease is caused by modern eating. When they hear about my quince tree they think "Hey, that's got to be healthy, something not cross-bred to death for supermarket purposes. How do you eat it?" I tell them "you cook it with lots and lots of sugar."
Rebrand. Rename it 'Zulip'
The Tor part has to be done outside of gossip, gossip doesn't have any tor-specific code. That includes tor-enabled DNS, if you wanted to use a .onion relay. If it is not working, I don't think it is gossip that is not working.
There is no evidence linking me to Jeffrey or the girl.
Thanks for the link. Now... off to get it censored.
House prices are often hard to figure out. Is the market high? It is low? What is normal?
I'm fond of the ratio of average house price to median household yearly income. This gives a number that you can compare across countries and over time.
For you Americans: https://www.longtermtrends.net/home-price-median-annual-income-ratio/
The lowest I've seen in my lifetime is 3.6 in the USA in 1973.
The highest I've seen in my lifetime is 8.9 in NZ in 2022.
NZ has fallen off of that back down to about 7. Which is now equal to the highest the US has ever seen.
The 2005-2007 subprime meltdown, where up to 25% of subprime loans became bad debt, the peak was at 7.
The US is back up to about 7.
Do you have one? Is it any good?
Well then if you want to do that, look at Mosaic for ideas too. "I did it my way" 🎶.
If other active developers went and built something like a Nostr 2.0 that wasn't Mosaic, but they at least looked at Mosaic, took what they liked, and had good reasons for not taking the rest, I'd probably be happy to dump Mosaic and go with their thing. But I'm unaware of any other next-gen project in the works. And most of these hard problems are not happening in nostr. I talked to a number of devs about future ideas. The Rostra guy is totally jaded and uninterested. Nuh wants to build on a crypographic filesystem (with pkarr of course).
I'm spending a lot of time in the fiat mines, but I'm still progressing Mosaic stuff. The spec and code are open, and the spec leads, so nobody can think I tried to jump start others. Truth is however that I'm the only person working on it, nobody else who has shown any interest has shown interest in helping to build it. So far at least.
I'm a few months out from having something to demo.
I'd like to have an offline master key.
For Mosaic, this would still be required to sign my relay list (server list) and sign device keys and again anytime those things change.
Moving the data around on a USB stick is feasible but annoying. I quite like the seed signer and using QR codes and cameras to move data around.
So I'm writing an android app that I will run on a disused android phone that I disable as much as possible (no SIM, no WiFi password, airplane mode, flashing the modem with zeroes). Yes of course the far-side of the modem pinging the towers is not something I can disable.
Still it could be attacked from the cell tower. Not likely but completely possible.
Unfortunately I haven't found any good handheld computers with cameras, without networking, and running linux. My Librem 5 spontaneously hard crashes and reboots after less than an hour of usage, else I'd try that.
Maybe I should just pull the seed signer code, add what I want, and use my seed signer.
Anyhow, the code I'm writing is with Dioxus that targets a lot of platforms: linux, macos, windows, appimage, web, ios, and android.
What a piece of trash!
Read README.macos.txt. It ships with gossip.
I've put issues on https://github.com/mikedilger/nostr-next as a dumping ground for things I thought were too hard for nostr to solve.
Population growth is slowing way down. Some people are worried about this.
But I think it is a good thing. The Earth has some carrying capacity and if we go beyond it people will start starving. That is not fun. Yes, we can engineer a higher carrying capacity as we did during the green revolution. But there are still limits.
Population is still growing. It is still growing in the USA. It is still growing in NZ. It is very much still growing in sub-Saharan Africa. Current estimates put the peak at 10 billion.
The problem with population contraction that most of you and I will feel is that all the government (and non-government) Ponzi schemes will collapse. Economies will be rubbish, growth will be stalwart. But you can accustom yourself to such times.
The idea that we need to start having more babies is misguided. We could push out the inevitable, but we can't avoid it happening eventually.
Is this the new state of Calizona? Making me hungry.
I'll ask next time. If there is a next time. There shouldn't be a next time.
I think I'll put into my will that at my funeral I want this song to be played: Bogus Soul by Beck.
And if people don't laugh, I'm gonna roll over.
Never believe anything until it has been officially denied.
Fast, cheap and permissionless girlfriends. I'm in.
This is only for a situation where, from day 1 you say "pubkeys all end in N zeroes else software should reject them". So for Mosaic, a nostr-like protocol I'm writing that nobody is using, it could be done. But it can't be done in nostr. Nonetheless I'm now against the idea (read the other thread replies for why).
Yeah, difficulty adjustment I can do. I would just start at some difficulty, and announce ahead of time (maybe 6 months ahead) of the new difficulty. People would have to roll over their device keys before then if their PoW wasn't already high enough.
But I think @npub12ak…6fdh 's point is the biggest problem. People's hardware is just too variant. Smartphones can't compete with spammer dedicated hardware, so there is no PoW which is easy enough for a smartphone and still too hard for a spammer with dedicated hardware.
And my point about the key generation not being the gating factor also has convinced me that this line of thinking is a dead end.
YouTube wants me to Sign in to confirm I'm not a bot. But I *am* a bot. Why are they discriminating against us?
I just had the thought that the gating factor is the network connection to drop off the spam on the server. It doesn't matter if keypair generation is super fast without PoW, any slowdown by requiring PoW that doesn't exceed the gating factor of the network connection makes no difference, until it exceeds that. So "one million times slower" is of no practical effect.
Nice repo. Did you look at rana? Or other client PoW code? Or just start fresh?
While computing power spans a wide range, as you say, even a little bit of PoW makes creating a new account ONE MILLION times harder. That takes less than a second though. There is no ideal amount of PoW that keeps out spammers, but if you can slow them down one-million fold with a trick that costs very little, it still seems worth it.
If starting over, proof-of-work might work.
Nostr software has explored a number of spam prevention mechanisms. Some of them are quite good. But one that didn't gain widespread adoption was proof-of-work.
I'm thinking of a PoW on public keys. If public keys must end in 28 zeroes or be rejected as invalid keys, this would require about 100 seconds of delay for someone to create a new identity. If handling a spam message takes only 10 seconds (probably less), then spammers would have to work 10x as hard as spam recipients to keep the spam flowing. That might not be enough to deter spammers entirely, but it would be an unavoidable cost in the equasion that could slow spam down. And of course other spam prevention techniques could also be in play, it doesn't interfere with any of them.
What do you think? If this isn't useful, or makes something important too hard to do, let me know. This would be for mosaic, not nostr, since nobody uses mosaic it can get these kinds of changes.
This is a wild theoretical concern with no practical attack. Nobody knows if, with a horde of encrypted keys, you could somehow hack them better than if you were just trying to go after one.
If there is a good reason to put them online, that might easily overwhelm this kind of excessive safetyism.
They should be very secure. Not only because of the good and excessive crypto (xchacha20, good cryptographers are now saying 8 rounds was enough, 20 is crazy) but also from the intense key derivation (scrypt, maximally memory hard) and further because the plaintext is both SHORT and virtually RANDOM.
GM
I have butterflies in my stomach. What did You eat for breakfast?
60% of the time it works every time
I think we have been exploring and learning for a while, and some kind of useful guidance for those who don't want to spend years exploring and learning sounds like a good idea. Starting from the principle of defending yourself. Don't trust, don't rely on the unreliable, program for the worst case, including active attack.
You know, every time you remember something, your mind changes it just a little. Until your best and your worst memories are your biggest illusions.
Also, I never assume a relay is broken.... just that it isn't working right now. So it never stops trying. But exclusions of 600 seconds are long enough that this doesn't matter much.
Sometime in the past I coded a way for users to delete (knowledge of) relays that they knew were "dead". The code didn't work and after some debugging I realized that it actually did work, but the relay got recreated because data in my local database referred to it, and any reference to a relay URL makes sure a relay record exists for it and starts collecting statistics on it. So it just gets deleted and recreated by the other logic. Even if I deleted the events in the local database, new events on nostr would recreate it. I would have to mark it with a tombstone saying to never recreate it... which seems wrong because the DNS name might one day be used for a relay again.
I also pick relays judiciously. When I need to read from someone's set of outboxes (or inboxes), I choose the relays that are most likely to be working.
The console log shows all kinds of relay errors and complaints. I just ignore most of it.
There is nothing specifically coded by me. But CTRL-C and CTRL-V for cut-and-paste work due to egui.
For most connections I use a 30 second timeout. For advertising relay lists I use a 5 second timeout.
Gossip client tracks jobs, unfinished jobs with benign errors will try again after a timeout, but there is a long list of error conditions which change the behavior.
For a few random examples, if the relay returned status 4000, we exclude connections to that relay for 600 seconds. If the connection timed out, we exclude it for 60 seconds. If we got a NOT_FOUND, 600 seconds. If we got a websocket error, 15 seconds. Some of them are probably poorly chosen numbers and could use review.
We then randomize the exclusion value a bit so that retries to multiple relays don't all line up together. For jobs that are not marked "persistent" we don't bother trying again. From my reading of the code right now it looks like if a relay is excluded and a new job wants to talk to it, an error is thrown rather than queueing up that job to happen after the exclusion, which might not be ideal.
Relays marked rank=0 are never connected to, so users can disable relays that don't work, but this involves the user who usually isn't going to notice these details.
1. yes, 2. yes, 3. yes, 4. yes.
I zoomed in looking for a phrase like "take your sats off the exchange" looking all over her body, but I didn't find it.
If there are tweaks that make it better for Reticulum, let me know.
I've been busy in the fiat mines and spending a lot less time on nostr and mosaic both. But I'm not in a hurry, I think more time and more thought up front will make a more robust protocol in the end.
I just moved the signature to the end of the record so that in the future it can be of any size, but I didn't create support for multiple cryptosystems yet. That can come later. Next I need to build out the reference implementations (server, client, offline tool).
Users must pick relays. But users don't know "by which criteria" they should pick them.
So I scoured >1000 relays and picked about 25 open relays that don't require AUTH or payment and so they work for inbox and outbox for new people. When you use gossip for the first time and set up an account, these are the relays it lists for you to pick from. I am not associated with any of them, they just passed the tests.
ALSO, inside gossip's relay panel for any particular relay, you can press "TEST" and it will do some tests and then let you know if the relay works as an inbox or outbox for you.... so that if it doesn't, you'll know to not add it to your relays list.
There has been a push among the most prominent nostr developers to make more and more custom kinds of relays. Most of those don't work as inbox/outbox relays so we are in this situation where regular users are both required to choose relays for their kind-10002 relay list, but also that they have no idea how to do it and even if they knew how, don't have the tools or information necessary to make good choices.
That is also a main issue. Syncing would be useful.
I mean for picking your own relay. I'm not judging other peoples choices, but if their relays don't take my reply then that's their problem.
Yes it is a deep change.
I think one of the biggest problems is the infinite-redundancy issue. Most protocols have no redundancy. We have unbounded lists of relays. I think 3 is plenty for any particular purpose. Given how many connections we already have to make, it is just too onerous to connect to all 37 of someone's outbox servers. If people want to list 37 outbox servers, clients should use the first 3 and optionally use more if those 3 are down, but beyond the first 3 nothing is guaranteed.
Not every client needs to help users setup their relay lists direclty, they can pass users over to a different client or website that does it.
I don't like blacklists here because that becomes another point of trust. I'd prefer to know for myself if a relay never works for me. So I want the client to do this and to remember.
Gossip client keep statistics on how successful a relay has been, and has fairly aggressive timeouts for poor performing relays.
Also, for choosing outbox relays I go through a fairly long process to find appropriate relays and then I hardcode them in the next release. This goes like this:
1. Print out the relays from my gossip client sorted by rank (best performing first)
2. Skip if we never connected to it
3. Skip if the URL has a path beyond the hostname
4. Skip if the relay does not have a nip-11
5. Skip if the pubkey in the nip11 is invalid (or a prefix)
6. Skip of nip-11 indicates limitation.restricted_writes
7. Skip if nip-11 indicates fees
8. Remove relays known to be special-purpose
9. Score according to a custom algorithm that uses statistics from gossip client (number of attempts, last connected, success rate, etc).
10. test with a random keypair to see if it accepts a note and I can read it back.
Fewer and fewer relays pass this gauntlet because of spam filtering measures.
Gossip isn't doing it. I think the idea was that any url ending in enough hex digits might be blossom and to do that. But I never got around to it, and I've become busy with things outside of nostr, at least for a while.
Your Casio calculator can't handle the truth about 2^256
1 in 115792089237316195423570985008687907853269984665640564039457584007913129639936
Why not just overwrite it again? Is it because the content of the previous one isn't accessible and so you can't see what you lost?
Ok, maybe Mike died and I'm wrapping up his estate.