Subnostr

I am trying to get Amethyst to only load the past x days of NIP-17 DMs just enough to fill the Messages screen with the last people the user talked to. From there, it is page loading all the way to the bottom of chats.

The only issue is that you never know how many people will be available in the next batch from the DM relay. You would have to dynamically figure out when to stop the page.

fiatjaf 1y ago

If we manage to decouple encryption keys from identity keys and use that for NIP-17 (not a per-device key, but a standalone key that is shared among all devices that your friends encrypt to with with ECDH like we already have) then I think it would be interesting for people to optionally share these keys with trusted relays and then the servers could do all the filtering and organizing of DMs on their behalf.

This way the trusted relays can know who is messaging you (and not the contents of the messages), but that makes it possible to have a good DM client.

Does it make sense?

Reply to this note

Please Login to reply.

Discussion

jb55 1y ago

why do you need a relay to "organize DMs" ?

fiatjaf 1y ago

So you don't have to download a bazillion giftwraps from a spammer before learning it was all spam, for example, or to do what Vitor said above.

jb55 1y ago

so would the outer receiverPubkey be the key you share with the trusted relay and friends, while the inner receiverPubkey is your root pubkey?

for the dm management thing to work you would have to give this wrap-decoding nsec to your relay that you run yourself?

fiatjaf 1y ago

Hmm, yeah, that sounds right, my point above was wrong because I actually do not want to involve the user's main nsec in any encryption operation whatsoever, so I guess we would need two independent nsecs for this to work, one for the giftwrap and the other for the encrypted content.

But my bigger point is that I believe we could make it work easily with existing NIP-17 clients by just making them use these alternate nsecs when encrypting instead of the target's main nsec. And then people could opt to just use their main nsec by default or to signal that they are now accepting DMs to these other nsecs.

(I didn't think this too much so I'm probably missing something again.)

jb55 1y ago

seems fine but I think it leads to device keys because I doubt users will want to manually manage another nsec

fiatjaf 1y ago

Yes, I'm talking in the context of having device keys and then these secrets are shared seamlessly across devices.

Mike Dilger ☑️ 1y ago

If we move to a separate encryption key (good idea) then I presume the messages are not NIP-17 giftwrap(seal(DM)) (since that specifies otherwise). And in such a case we can avoid spam by doing what Will says in the OP, which is to first require an endpoint-exchange and key-exchange through giftwraps (not 1059, something new), and if you get a giftwrap DM that is not from somebody that is already setup, you discard it. Sure it could be spam, but spammers won't have much incentive to send something that the user never sees.

fiatjaf 1y ago

But then people can't send you messages at all unless you first manually approve them?

fiatjaf 1y ago

I guess this is also the case in MLS.

Mike Dilger ☑️ 1y ago

I think it has to be one way or the other. Either people can send you messages out of the blue and spam you too, or neither. Am I wrong? Is there a middle ground?

fiatjaf 1y ago

A relay that knows who is messaging you can filter out trash on your behalf, impose soft limits on the number of messages a "stranger" can send, require PoW etc.