shafemtol

Apart from the shared secret issue, one thing not addressed here is sender authentication.
Assuming the encryption key is `S' = w * Q2`, since the sender signs with the ephemeral key `w`, unless the recipient can somehow verify that `w` belongs to the intended counterparty, the recipient has no way of authenticating the sender.
Anyone who correctly guesses one of the participants of the silent inbox (e.g. a relay operator would be able to trivially figure this out in many cases) can send a DM to that participant with an ephemeral private key of their own, pretending to be the other participant.

2023-06-04 23:49:17

- reply

What you could do is hash the shared secret curve point `S` (preferably using a tagged hash function) into a shared private key `r`, then use the corresponding public key `R = r * G` for the `p` tag. This would not leak the actual shared secret.

2023-06-04 23:38:41

- reply

Maybe something's missing in the pictures. Note that I'm not talking about decrypting *silent inbox* DMs. Here's an example of it going wrong as I understand it:
First, Alice (keypair p1, Q1) sends Bob (keypair p2, Q2) a *regular* NIP-04 DM (no silent inbox).
NIP-04 uses shared secret `S = p1 * Q2 = p2 * Q1` to encrypt the message. In NIP-04, this is given in the example code as:
`let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey)`
Eve also picks up this DM. She sees that Alice sent Bob a DM of a certain length at a certain point in time. She can't decrypt it yet, but stores it in her collection for later.
Next, they Bob decides to try using a silent inbox. This time, Bob sends a message to Alice.
Silent inbox uses shared secret `S = p1 * Q2 = p2 * Q1` (from the picture titled "Shared Secrets").
Bob constructs the event using an ephemeral key `w`, encrypting to `Q1` (I presume using `w * Q1` as the NIP-04 encryption key, but this is not relevant to the attack). She puts `S` in the `p` tag of the event and signs it (from the picture titled "Send and receive flow").
Eve also picks up this DM. She doesn't yet know its sender or recipient, but she reads the `p` tag and starts trying to decrypt the DMs she's got in her collection one by one, using the contents of the `p` tag as the shared secret.
One of the DMs does decrypt to a valid message, namely the first, regular, DM from Alice to Bob. Eve can now decrypt every past and future regular (not silent inbox) DM between Alice and Bob. Furthermore, while Eve can not decrypt silent inbox messages due to the use of different encryption keys here, she learns that the silent inbox in question belongs to Alice and Bob and can see the length and timing of each message going to it.

2023-06-04 19:32:09

- reply

NIP-92: Rendezvous Beacons (draft; https://github.com/nostr-protocol/nips/pull/333 ) enables anonymous establishment of communication between two parties, addressing the issue of receiving messages from unknown contacts.
A shared secret is derived using ECDH like in NIP-04, but this shared secret is only used through *tagged hashes*, with a different tag (not to be confused with nostr tags) for each purpose.
From the shared secret, a *rendezvous keypair* is established, where the sender knows the private key and the recipient knows the public key. This is done by tweaking the sender's key (an ephemeral key in the case of NIP-92) using a tweak value derived from the shared secret.

2023-06-04 19:02:31

- reply

I'd be uneasy about a supposed "shared secret" being put in a public `p` tag.
Indeed, AIUI, using a silent inbox as presented here completely breaks the security of any past and future regular NIP-04 DMs between the same parties, because the same "shared secret" used for encryption in regular NIP-04 DMs is being used publicly in the silent inbox. An attacker doing trial and error decryption of NIP-04 DMs would be able to decrypt all regular DMs between the two, as well as deanonymize the silent inbox.

2023-05-09 06:35:29

Seems like Binance has currently queued up at least 5 blocks worth of panic consolidation transactions in the mempool at 201 sat/vB for a total of at least 10 BTC in transaction fees. https://mempool.space/address/bc1qm34lsc65zpw79lxes69zkqmk6ee3ewf0j77s3h

2023-05-09 04:04:53

- reply

Twitter didn't have retweets originally, they introduced a retweet feature in 2009. The "RT @twitterhandle" form started as a convention among users a year or two earlier. Twitter may have implemented their APIs in a backwards-compatible way by presenting their later implementation of retweet as such to older clients, though I'm pretty sure their internal representation of a retweet would be different.

2023-05-09 03:18:33

- reply

Some of the inputs don't even cover the cost of including them!

2023-03-23 07:11:24

- reply

Since nostr uses Schnorr signatures, it already supports n-of-n multisig. Though in this case I guess you're thinking of something where not all users need to sign?

2023-03-23 03:33:17

- reply

Maybe not (see: Deniable authentication)

2023-03-22 16:06:37

I don't like the concept of duplicating the original event and putting its json in the content. There's a lot of duplication and it's not trivial for a relay to deduplicate as the original event can be serialized in countless different ways.
Rather have the relay optionally send the original event alongside the (first) repost event.

2023-03-21 13:55:53

- reply

Not gonna compromise my on-chain privacy for the sake of keeping some pocket money secure. Sorry not sorry.

2023-03-19 20:35:32

- reply

Relays shouldn't have to be trusted.
It's not really true that you need a full node to verify OTS timestamps, you can use an SPV-like trust model where you just have the Bitcoin block headers and check their POW. The headers are just 80 bytes per block.

2023-03-19 19:27:36

- reply

NIP-03: OpenTimestamps Attestations for Events

2023-03-15 16:12:15

- reply

With confidential amounts you'd have better anonymity guarantees. With public denominations, each denomination effectively has its own anonymity set, which might especially affect user anonymity when different denominations are combined, and the issuer knows a per-denomination lower bound on a user's funds and upper bound on amounts being transferred between users.
I'm still trying to wrap my head around the cryptography needed for confidential amounts. I think each token has to be bigger by some constant factor, but each user only needs to store a single token. And someone might have a single token worth 4.2 BTC and remain in the same anonymity set as someone with a balance of 69 sat.
UX-wise there should be no difference, but it could be made insanely private, with the issuer not even knowing whether a particular user is sending, receiving or just renewing a token.

2023-03-15 12:21:15

When the client adds `"nip05valid":true` to the public profile 🎖️
https://nostr.build/i/nostr.build_a6962c7495538ac66b36e2aaea9944915997c2bb87d985977d4415e0d729165d.jpg

2023-03-15 11:51:22

- reply

Cashu tokens are still power-of-2 denominations, right?
Wen confidential amounts?

2023-03-12 21:49:56

Idea: Relay that only serves events that are slightly corrupted in different ways, if your client accepts any of them, it's broken
#[0]

2023-03-12 21:37:54

- reply

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'.

2023-03-12 21:34:48

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

2023-03-12 21:29:57

- reply

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

2023-03-12 20:47:42

- reply

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.

2023-03-12 20:30:43

- reply

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]

2023-03-12 20:04:10

- reply

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.

2023-03-12 19:16:37

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

2023-03-10 08:53:17

- reply

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.

2023-03-09 12:41:26

- reply

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.

2023-03-09 10:44:17

- reply

Excluding Satoshi?
https://nostr.build/i/nostr.build_a3951d7df0053fab5a38ee956872ca617693dc2ef50466e08e978016b49b1f8d.png

2023-03-09 10:10:41

- reply

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.

2023-03-08 07:26:34

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

2023-03-07 06:51:55

- reply

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.

2023-03-07 05:00:44

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]

2023-03-07 01:23:46

- reply

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

2023-03-06 07:54:20

- reply

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.

2023-03-06 07:45:13

- reply

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.

2023-03-06 06:20:08

- reply

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.

2023-03-06 05:42:50

- reply

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.

2023-03-06 04:40:59

- reply

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]

2023-03-06 02:41:37

- reply

Ok, by 'clients' I mean snort.social, and by 'removing' I mean default disabled in settings. I'd be fine with DM functionality treated similarly.

2023-03-06 02:18:33

I see clients are removing likes/reactions. How about removing something actually harmful like NIP-04 DMs? That would be something.

2023-03-06 02:16:12

Some of the relays I had in my profile are unusable over Tor. I removed them, hopefully my posts are still reaching most of the network.

2023-03-03 04:56:53

This is why we can't have nice things
https://nostr.build/i/nostr.build_3816dcfc090da03ddc43cd29cff1b2db31a65307e6035711567226093081c43c.png

2023-03-03 00:18:11

- reply

I have created an issue on NIP-08's failure to specify correct behavior here: https://github.com/nostr-protocol/nips/issues/319 #nostr

2023-03-02 21:51:54

- reply

Results on generating notes:
- astral.ninja: 💩 fail #[2]
- coracle.social: 💩 fail #[3]
- iris.to: 💩 fail #[4]
- snort.social: 💩 fail #[5]
They *all* fail to avoid creating false-positive NIP-08 mentions. This is a failure of NIP-08: It does not specify how to actually create a message with the plaintext `#[x]` (where x is a number) in it if the event has tags. #nostr

2023-03-02 21:40:30

- reply

Testing reply from snort.social: #[0] #[1] #[9]

2023-03-02 21:37:59

- reply

Testing reply from iris.to: #[0] #[1] #[9]

2023-03-02 21:37:01

- reply

Testing reply from coracle.social: #[0] #[1] #[9]

2023-03-02 21:33:51

- reply

Testing reply from astral.ninja: #[0] #[1] #[9]

2023-03-02 21:29:32

- reply

Results on viewing:
- astral.ninja: 🤙 pass
- coracle.social: 🤙 pass
- iris.to: 💩 fail, removes part of the text, shows as `0 9`
- snort.social: 💩 fail, highlights text in bold red and appends question marks

2023-03-02 21:18:19

- reply

astral.ninja to the rescue, coracle.social now works after I re-added the relays without trailing slash

2023-03-02 20:19:31

coracle.social seems to fail on relay URLs with a trailing slash. My profile there is outdated and shows none of my posts, presumably because it refuses to connect to the relays declared in my profile. And snort.social adds a trailing slash to the URL of every relay I add to my profile 💩

2023-03-02 19:31:14

Testing how clients deal with undefined parts of NIP-08: #[0] #[9]

2023-03-02 18:31:29

- reply

Clients could improve their cut-off functionality by having some extra tolerance. If length is greater than cut-off + tolerance, then it's shortened to the cut-off length.

2023-03-02 04:08:13

Trying to understand the cryptography behind WabiSabi for like the fifth time

2023-03-01 04:30:09

- reply

This broke my internet connection

2023-03-01 03:56:19

- reply

Assuming the best option initially would be not trying to host git repos themselves on nostr, but repository metadata (description, repository URL, branch hashes) and an issue tracking system to begin with.

2023-03-01 03:45:48

- reply

Or rather, I'd like the whole event shown in human-readable format, falling back to the json values for things it doesn't know how to parse.

2023-03-01 03:39:05

- reply

Using Flamingo right now. Its signing dialog is very limited, it only shows the `content` part of the event, with newlines replaced with spaces for some reason. For events without content it just shows a blank dialog. I would want it to show the whole event to be signed in json format. Otherwise it seems to be working well.

2023-02-28 18:28:56

- reply

Any reasonably sane email client will not load remote content by default. Nostr DM clients need to behave similarly. Some email clients might load external content through a dedicated proxy. That is also problematic as it lets the sender know exactly when the email is opened.

2023-02-28 17:56:12

- reply

Results: iris.to and coracle.social display the image, snort.social fails (doesn't strip off the fragment before sending the URL to its image proxy, guessing the proxy itself doesn't remove it either).

2023-02-28 17:45:58

- reply

Testing .png URL with fragment
https://i.stack.imgur.com/Iil7a.png#1

2023-02-28 17:10:48

- reply

Regarding referrer, browsers send the `Origin` header on WebSocket connections, revealing the domain name of the client app. Other resources can be loaded without referrer/origin through `Referrer-Policy`. This does not affect the WebSocket `Origin` header.
I did some testing and found a trick: Put the WebSocket client in a sandboxed iframe.
Demo here: https://sha.femtol.net/dev-tests/ws-origin/iframe-sandbox.html (use the browser's network console).
Tested and works on both Firefox and Chromium. It might not work on older Firefox browsers, though.

2023-02-28 14:03:23

- reply

Test without fragment
https://void.cat/d/HUBDjrsgNcc4YH7Htv9HMc.webp

2023-02-28 13:09:40

Test
https://void.cat/d/HUBDjrsgNcc4YH7Htv9HMc.webp#1

2023-02-27 23:56:23

NIP-93: Secret Events (draft)
https://github.com/nostr-protocol/nips/pull/306
Nothing too exciting in this particular NIP, just intended a small building block. #nostr

2023-02-27 13:06:08

- reply

The proxy could pass the challenge and response to and from the client through some protocol extension (client/user would still have to trust proxy not to abuse the authenticated session).
I'd rather like to see an anonymous solution, though, like some kind of usage tokens based on blind signatures.

2023-02-26 22:05:14

- reply

The NIPs don't seem to be fully consistent in its use:
| kind | description | NIP | content | note |
|-------|-----------------|-----|---------|------|
| 0 | Metadata | 1 | Yes | - |
| 1 | Text Note | 1 | Yes | Yes |
| 2 | Recommend Relay | 1 | Yes | - |
| 3 | Contacts | 2 | ignored | - |
| 4 | Encrypted DMs | 4 | Yes | - |
| 5 | Event Deletion | 9 | MAY | - |
| 7 | Reaction | 25 | Yes | Yes |
| 8 | Badge Award | 58 | - | - |
| 40-42 | Chat | 28 | Yes | - |
| 43-44 | Chat | 28 | may | - |
| 1984 | Reporting | 56 | MAY | Yes |
| 9734 | Zap Request | 57 | MAY | Yes |
| 9735 | Zap | 57 | No | Yes |
| 10002 | Relay List Meta | 65 | No | - |
| 22242 | Client Auth | 42 | - | - |
| 24133 | Nostr Connect | 46 | Yes | - |
| 30008 | Profile Badges | 58 | - | - |
| 30009 | Badge Def | 58 | - | - |
| 30023 | Long-form | 23 | Yes | - |

2023-02-26 17:50:21

Ideas on anonymous delivery of secret events
https://github.com/shafemtol/nostr-secure-messaging/blob/main/anonymous-delivery.md #nostr

2023-02-26 16:32:22

- reply

Working on it 🤙

2023-02-26 00:26:00

Having scanned through all of the NIPs, I'm still not sure exactly what is meant by a "note". All notes are events, but I'm guessing not all events are to be called notes? #nostr

2023-02-24 12:44:59

- reply

> Including a recent block hash is a proof of absence, meaning that the note cannot have been created before that block was mined. It proofs the lower bound, that the message is older than that block. The attacker can include a very old blockhash years after it was mined.
I think you're missing the idea here. The point is exactly to prove that a note's id was created after a certain block was mined. But the block is not chosen by the attacker. It must match a set of recent blocks by the filtering client. The client is only interested in recent notes, not historical ones. By using a filter as provided in the example, the client is guaranteed (by the promised behavior of any relay that follows NIP-01 + NIP-12) that any notes returned were created after the list of block hashes chosen by the client.
Proof of freshness does not solve the case where an attacker concentrates PoW on creating notes targeting a very old block hash. For that case, you can combine this NIP with an opentimestamps proof as you mentioned.
https://github.com/nostr-protocol/nips/pull/296#issuecomment-1443568647

2023-02-24 07:21:36

NIP: Proof of Freshness
https://github.com/nostr-protocol/nips/pull/296 #nostr

2023-02-23 22:39:28

Going down the rabbit hole of secure, private DMs. I think a good design will require multiple smaller, composable NIPs. #nostr

2023-02-23 21:25:57

A preventive block was successfully mined at height 2421214. The two blocks that followed had an interval of 31 minutes between them.
If those blocks had been mined at the same rate without the preventive block, there would have been another block storm! #bitcoin #testnet #[0]

2023-02-22 21:41:19

- reply

These are the concerns and edge cases I can think of regarding a soft fork to set a maximum timestamp limit on block 2015:
## Can a maximum timestamp requirement of prev timestamp + 20 min conflict with the minimum timestamp requirement of prev mediantime + 1 sec, making it impossible to mine a new block on top of the latest one?
No, because prev mediantime can not be greater than prev timestamp. The mediantime of a block is the median of the timestamps of that block and the 10 before it. Because that block itself must have a timestamp greater than the median of the 11 blocks before it, it must have a timestamp greater than that of at least 6 of those blocks. It follows that it must have a timestamp greater than at least 5 of the 10 blocks before it. Thus, its timestamp can only be set so low as to also define the block's own mediantime.
## Could non-upgraded miners run off in a chain split?
Yes, if they start a block storm. But they would reorg and join the upgraded chain as soon as the upgraded chain finds block 2015. This is because the non-upgraded chain would all consist of difficulty-1 blocks for the next 2017 blocks (and then increasing by no more than 4x for every difficulty period after that). That is, the blocks do not make a heavy chain. Even if the non-upgraded chain had more hashing power in theory, they would be limited by the rate of new blocks having to be sent across the network.
## Could the chain stop at block 2014 for hours because all ASIC miners left?
This is a possibility. Is it worse than a block storm, though? Not everyone has their own ASIC miner, but renting some ASIC time shouldn't be too hard or expensive (should cost no more than about 40 cents per expected block at the current difficulty and BTC price).

2023-02-22 19:30:06

- reply

So, kind 6 was NIP-18, but it got removed because it wasn't being implemented as specified: https://github.com/nostr-protocol/nips/issues/173
Quoting works by regular text notes with mentions of other notes embedded in the text body. I would have assumed reposts were the same but with no other text in the body.

2023-02-22 19:05:59

- reply

Apparently a boost/repost is kind 6, which I can't find mention of in the NIPs? And snort includes the reposted event in full as stringified JSON in the content field, while iris leaves the content field blank?

2023-02-22 18:47:17

- reply

ChatGPT seems to be excellent at breaking down code and explaining exactly what each part does. I'm curious: would it be able to explain why this command works on a pruned node?

2023-02-22 18:30:40

- reply

Looks like the address it gave in the example there is completely made up, getting "invalid address". Did I transcribe it correctly? 1F5MsWgRyxA6lekVMrhKmUsPJdQaYjP9sm

2023-02-22 18:18:42

- reply

The method I'm exploring is to try to force the mining of the last block in a difficulty adjustment to happen at full difficulty for as long as possible, to maximize the chance that a full-difficulty block is found before difficulty drops to 1.
Last block storm was triggered on Oct 31, it might take a few months to see if this method is effective.
The triggering block, at height 2378879, seems to have been _deliberately_ set 20 minutes ahead of actual time. Its timestamp is exactly 20 min 1 sec after the previous block, and 20 min 3 sec _after_ the _following_ block.
Deliberate attacks might still succeed in triggering block storms.

2023-02-22 17:33:14

- reply

By the way, #[3] , you say that a fix would require a hard fork. Is that a common belief?
A simple soft fork* would be to require that the last block in a difficulty adjustment period has a timestamp no greater than 20 minutes after the previous block.
__
* A soft fork in the sense that it only restricts consensus rules. Miners that don't implement the change might get their block invalidated by this. But such a block would be a difficulty-1 block, so no big deal.

2023-02-22 17:18:47

- reply

Background on Bitcoin testnet block storms by #[2]: https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/

2023-02-22 17:12:36

Exploring a method to reduce the risk of block storms on Bitcoin testnet

2023-02-22 11:04:25

There you have it. #777777
2023-02-22T09:58:27Z UpdateTip: new best=00000000000000000005d35085cbcb510c14917f928aaa45facb0c0d24d471ce height=777777 version=0x2feaa000 log2_work=94.018808 tx=807684568 date='2023-02-22T09:58:09Z' progress=1.000000 cache=139.8MiB(1043516txo)

2023-02-20 21:21:23

- reply

His client mangled the npub in the plaintext as per NIP-08, your client might show the mangled part as "@jimmysong". If you replace that text with the npub, you should be able to verify it.

2023-02-20 20:05:09

- reply

NIP-04 is absolutely nowhere near what Bitmessage did. A major goal of Bitmessage is to provide anonymity and hide almost all metadata. NIP-04 does absolutely nothing to hide the metadata, the metadata is completely public to everyone (unlike almost every other communications protocol/platform where this is usually only visible to some centralized third party).
In Bitmessage, messages do not have any address label. Apart from a timestamp, every message is an opaque blob to everyone except the sender and recipient. All messages are broadcast through the peer-to-peer network to every participant, who each simply tries to decrypt every single message they receive with their private key. This means the recipient of a message has the full anonymity set of all Bitmessage users.
In comparison, NIP-04 DMs is Babbys First Crypto Project (and was AFAICT not meant to be much more):
- Metadata like sender and recipient is provided in the clear in each message. The messages are public. Everyone can see who DMs whom when and how long the messages are.
- Sender sends the DM directly to one or more relays, recipient receives DM by asking relays for messages matching their pubkey. Relays may be able to learn some extra information about the sender and recipient, such as IP address, browser, operating system, and usage patterns.
- The encryption itself has issues like non-uniform AES key.

2023-02-20 11:16:00

- reply

To address the last point, in order to retain previously received zaps, maybe one could define a new event type for explicitly authorizing old zaps via `e` tags and/or old `nostrPubkey`s via `p` tags, in the 10000-19999 (replaceable) or 30000-39999 (parameterized replaceable) range. #nostr

2023-02-20 10:53:49

Issues with #nostr NIP-57 Lightning Zaps:
- Can be faked, as noted in the NIP itself
- Includes payment info that may aid LN surveillance entities, for no good reason (see above)
- If you later change your LNURL server or your LNURL server changes the `nostrPubkey` key for whatever reason, you lose all previously received zaps as the old zap notes can no longer be validated

2023-02-19 17:45:16

- reply

Indeed, you'd need to reconstruct some of the data, though. I have the bolt11 invoice, which is needed for the zap note, but not the description, which also goes into the zap note and must hash to the bolt11 description hash. The description is supposed to be the zap request, which is signed by the sender's nostr key (I'm not sure if such a thing was even created in this instance), while the zap note is signed by the recipient.

2023-02-19 17:25:30

- reply

My biggest gripe with NIP-04 is that all DM metadata is public, including sender and recipient: #[5]

2023-02-19 16:30:41

- reply

So I checked your lnurl-pay endpoint, and it doesn't include the NIP-57 fields `allowsNostr` and `nostrPubkey`. So no zap support, just regular lnurl-pay. But apparently that doesn't stop #snort from calling it a zap and then doing absolutely nothing on payment 🤪

2023-02-19 16:12:56

- reply

I zapped 1000 sats, the LN payment went through, but no feedback on my nostr client, did it do anything?

2023-02-19 15:30:05

- reply

Zaps are defined by NIP-57, apparently it records the bolt11 invoice and preimage in a public nostr event. So not as private.

2023-02-19 12:41:49

- reply

IMHO, the current NIP-04 DM stuff should be killed with fire. The less integrated it is with other functionality, the better.

2023-02-19 06:43:58

- reply

I think "aspects" is a good term for this feature.

2023-02-19 06:31:04

- reply

Apparently snort defined only a single hashtag for this message, according to the json output. Does it only ever add one tag per message, or was there some other issue with the second hashtag? #Nostr #hashtag #test

2023-02-19 06:19:55

- reply

I do like the idea of "personas" (I would maybe call them something else, maybe "personal topics"?)
This could be implemented per NIP-12 in combination with a new tag type for this feature. Or, if we make it a convention, just plain #hashtags.

2023-02-19 04:06:33

- reply

I learned about silent.link from CD77. Very exciting project. Looks like (for low usage) the data price can be quite decent as well in certain areas.
One issue I have with it is that you'd ideally have to use this on a phone whose IMEIs are not tied to your identity (so no KYC SIMs ever used on it).
They said on CD77 that the physical-SIM and eSIM IMEIs are different and thus the network operator cannot easily link these, but from what I've seen, the two IMEIs seem to be adjacent (apart from the final Luhn checksum digit), e.g:
- 004101846898885
- 004101846898893
So it seems they would be trivially linkable.
Are there devices where these IMEIs are at least somewhat unrelated?