Ok, apparently this is just some weird font thing I'm seeing on some clients as well as in the Flamingo extension, it is actually an 'x'.

Why is there no client that lets me put a plain old 'x' in between two digits? Like, 0x1 what? #nostr

(that is 22 in hexadecimal, or 34 in base 10, of course)

The current specs could be much better even if sticking to "human language". E.g., nowhere does NIP-01 say that created_at must be an integer, yet to #[2] that is apparently obvious. All NIP-01 says is that it's a unix timestamp in seconds. Go to the Wikipedia page for Unix time, and you'll see several non-integer examples.

Test vectors that cover all kinds of corner cases would definitely help.

It's not so fun when you just want to type plaintext but random clients absolutely want to imagine it's markdown and completely butcher your note. I'd be mostly fine with it if they'd stick to only modifying the style and not the text itself. Cf. #[2]

JCS, although more complicated than binary, is a well-specified JSON serialization form. Luckily, for hashing, nostr only relies on a few types (list, integer, string), which are not the most complicated parts of JCS, and it seems that most client implementations happen to be compatible with JCS for these types, at least for most notes. The most complicated part here is that there are 22 characters that require specific escape sequences when encoding strings.

Unfortunately it appears that some devs really really really REALLY want to use a generic JSON library to generate things that look like JSON even when they know that this results in critical bugs.

In some cases, the spec really needs to be more clear. https://github.com/nostr-protocol/nips/issues/354 #nostr

#[0]

If you want public broadcast that's resistant to jamming from someone with the same transmission capability as the broadcaster, I think it gets difficult. I don't have too much knowledge about radio stuff, but something I can imagine working to some extent in theory is very short bursts at changing frequencies across a wide spectrum. A jammer would have to hit the right frequencies at the right time to be efficient, but unless close to the broadcaster, their timing would differ depending on receiver location. It gets more difficult to avoid interference between multiple legitimate broadcasters at different locations, though.

A hardware-based solution might be receivers with multiple antennas, where the signals from the different antennas are continuously automatically tuned and combined in such a way that the signal from the identified broadcaster is amplified compared to any source of noise. I don't know the specifics, but I believe certain satellite receivers work like this, consisting of a large array of small antennas. Again, there would have to be a difference in location between the broadcaster and the jammer.

I see value in doing secure messaging over nostr rather than a separate network. With a network dedicated to secure messaging, you lose the effect of blending in with other types of use and thus leak more information to your network provider about your types of activity.

I do in fact see the public nature of relays as a potentially good thing for the core design of secure message delivery, as you're forced to minimize the trust in put in relays. The issue of trusting relays with traffic information (who sends and receives what) can be solved with separate solutions, used by users/clients that want better anonymity without affecting messaging compatibility with other users/clients.

I wouldn't see the issue of relays wanting to know the identity of its users specifically as a hindrance to secure messaging on nostr, but rather a problem that should be solved in and of itself. And as I mentioned in https://github.com/nostr-protocol/nips/pull/306 I think it can be solved with anonymous tokens based on blind signatures.

Excluding Satoshi?

I think public broadcast standards mostly rely on most people being unwilling to go to the trouble of setting up high-power transmission equipment in order to interfere with public broadcasts in a way that's probably not too hard for some government agency to track down.

NIP-92: Rendezvous Beacons (draft) https://github.com/nostr-protocol/nips/pull/333 #nostr

See also my NIP PR: #[2]

I proposed using a single-letter tag for the hash to cover a particular use case. Unfortunately the PR discussion derailed a bit IMO.

Successfully mined another preventive #testnet block at height 2423230. Next block came 32 min later, would have been 12 min after a "normal" block 2423230. If so, no block storm would occur even without a preventive block. But would have been a close call. #[0]

I proposed a NIP for just that kind of tag: #[2]

The Flamingo signing extension shows you the follow list before you sign it. Unfortunately it's just a list of npubs, but at least you'd notice if the list is considerably shorter than expected.

I was thinking about the quality impact on a global feed. In any case, a more refined filter on the client side is also an option.

Was just thinking about this.

#[2]

Some users follow a _lot_ of others, though, and might have a higher risk of following spam/impersonation accounts. As a refinement, maybe you could score each follow by dividing by the paid user's total follow count, and only include users with a follow score above a certain level, e.g. 1/200. And/or disregard the follows of users who follow identified spammers/impersonators.

I had to look up the claim about the difference in difficulty scale, because that was new to me, and I've been using the same code for testnet bits/target/difficulty calculations as those for mainnet.

The statement was added here, in January 2011: https://en.bitcoin.it/w/index.php?title=Testnet&diff=2244&oldid=2212

Testnet3 genesis was in February 2011: https://mempool.space/testnet/block/0

Within the current difficulty period on testnet3, I can find no regular-difficulty block that has a hash outside the supposed target using mainnet bits/target/difficulty calculations. The difficulty scale must have been different on testnet versions 1 and 2, but changed to the mainnet scale in version 3.

It's not a block storm, just someone modifying the timestamps of their blocks into the future to get to mine at difficulty 1. mempool.space shows future-timestamp blocks as mined "just now".

They're limited by the 2-hour rule, no big deal. But we're approaching a difficulty adjustment, and if they happen to be doing this on the last block in this difficulty period, they will trigger a block storm.

Better fire up my storm-blocking miner again... #[4]