Oddbean new post about | logout
▲ ▼
Magister Michael Dilger M.Sc. | 4 months ago (raw) | root | parent | reply | flag 
 Yes I think leaking the conversation key would expose the binding between the seal and rumor, not provably, but it would be highly unlikely to find a different conversation key that decrypted into a sensible rumor so effectively.  And the conversation key is post-HKDF so it doesn't expose your nsec.  This would have been great feedback for NIP-44 development.
▲ ▼
keychat | 4 months ago (raw) | root | parent | reply | flag 
 Thank you for your response. What do you think about our concerns regarding NIP-17? 👇

nostr:note1fy2yam6h0cm628rjlyzra06t5azxuru0q88hegjxtpz5uwstztnqmy0csl
▲ ▼
Magister Michael Dilger M.Sc. | 4 months ago (raw) | root | parent | reply | flag 
 As for the timestamp argument, asking for all of them from the last 2 weeks each time you spin up a client isn't going to be signifcant even though you are getting repeats.  And if new backdated ones flow in while the client is up, they will come through that same subscription after the initial EOSE without having to ask again. So repeats only happen when you start up a client.

I should correct my earlier post, it was NIP-59, the giftwrap NIP, that would have benefitted from the insight that you could dox your DM counterparty without exposing your nsec.

Kind 14 is essentially Kind 1 used in this context, except maybe the different kind number helps something. We could have a couple dozen new kind numbers that didn't mean anything different from kind-1 and it wouldn't hurt.

I don't personally like seed phrases. They are ok for recovery, but not for login.  For login a user wants to remember a passphrase that they get to make up from whole cloth.  There are algorithms to map that into a seed phrase.  NIP-49 goes from a passphrase to an nsec.  nsecs being 256 bits probably can be mapped to a seed phrase too.  Everything with sufficient entropy could be mapped into anything else.  Just saying there are a lot of possibilities here.
▲ ▼
keychat | 4 months ago (raw) | root | parent | reply | flag +1 
 I'm afraid the current Nostr relays don't handle the pushing of events with random timestamps correctly. For example, Alice and Bob are chatting using NIP-17, and both of their chat apps are active. Alice sends Bob a message with a random timestamp from 48 hours ago. The relay not only pushes this message to Bob but also re-pushes all the messages that Alice sent to Bob within the past 48 hours. Alice then sends Bob another message with a random timestamp from 24 hours ago. The relay not only pushes this message to Bob but also re-pushes all the messages that Alice sent to Bob within the past 24 hours.
▲ ▼
Magister Michael Dilger M.Sc. | 4 months ago (raw) | root | parent | reply | flag 
 I don't know what relay you are using but that is wrong.  I'm curious what relays are doing this horrible thing and I'll add a test to my relay test suite. I wrote a relay https://github.com/mikedilger/chorus and I assure you it does not behave that way.

You connect and subscribe to a 1-week period for DMs.  You get all the DMs over that week, then an EOSE.  Then when the next DM comes in, dated 7 days ago for example, it shows up by itself under that subscription without any repeats of data that came before the EOSE.

This behavior could happen if your client disconnects when it gets an EOSE, because when it reconnects and submits the REQ it will get the entire week again.