DMs aren't used all that much right now, and maybe clients c...

Dikaios1517

npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhe

hex

0000340adc47542073acb29edcd9e7613358d18c44e0d26c5fe6d2d35a3c2f98

nevent

nevent1qqsqqqp5ptwyw4pqwwkt98kum8nkzv6c6xxyfcxjd307d5kntg7zlxqprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgstwf6d9r37nqalwgxmfd9p9gclt3l0yc3jp5zuyhkfqjy6extz3jczg8wa5

Kind-1 (TextNote)

2026-06-27T00:02:36Z

↳ 回复 事件不存在

00006b01dc8621231ec31fc1619f2fcf6e897cc6ca0df92299fc4c460c8b2b48...

DMs aren't used all that much right now, and maybe clients could only request all DMs within the last X amount of time by default to reduce the amount of bandwidth, only requesting older DMs if the user scrolls up and requests to "load previous" or "search for previous." That would help with the bandwidth considerations.

The benefits for spam mitigation is what I am more interested in. Maybe not a terrible tradeoff.

Are we basically admitting that NIP-17 DMs are the best we're going to get for the time being, and we should just make them as good as they can be. I know there have been some struggles getting MLS to play nice with Nostr, especially for group chats.

I think I more or less understand how your proposal would work, as nostr:nprofile1qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qyg8wumn8ghj7mn0wd68ytnddakj7qg3waehxw309ahx7um5wgh8w6twv5hsqgzxpsj7dqha57pjk5k37gkn6g4nzakewtmqmnwryyhd3jfwlpgxtsnyw5n2 explained it. I assume that since you still don't see the pubkey of the sender, each side of a given conversation would have its own public conversation code?

原始 JSON

{
  "kind": 1,
  "id": "0000340adc47542073acb29edcd9e7613358d18c44e0d26c5fe6d2d35a3c2f98",
  "pubkey": "b7274d28e3e983bf720db4b4a12a31f5c7ef262320d05c25ec90489ac99628cb",
  "created_at": 1782518556,
  "tags": [
    [
      "p",
      "460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c",
      "wss://vitor.nostr1.com/"
    ],
    [
      "p",
      "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322",
      "wss://hodlbod.coracle.social/",
      "hodlbod"
    ],
    [
      "e",
      "bd19d893f5167db354de8148e0014bef9f0f0001cd0030c98a15a95b5a1e23a8",
      "wss://vitor.nostr1.com/",
      "root",
      "460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"
    ],
    [
      "e",
      "00006b01dc8621231ec31fc1619f2fcf6e897cc6ca0df92299fc4c460c8b2b48",
      "wss://hbr.coracle.social/",
      "reply",
      "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"
    ],
    [
      "client",
      "Coracle",
      "31990:97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322:1685968093690"
    ],
    [
      "nonce",
      "41917",
      "17"
    ]
  ],
  "content": "DMs aren't used all that much right now, and maybe clients could only request all DMs within the last X amount of time by default to reduce the amount of bandwidth, only requesting older DMs if the user scrolls up and requests to \"load previous\" or \"search for previous.\" That would help with the bandwidth considerations.\n\nThe benefits for spam mitigation is what I am more interested in. Maybe not a terrible tradeoff.\n\nAre we basically admitting that NIP-17 DMs are the best we're going to get for the time being, and we should just make them as good as they can be. I know there have been some struggles getting MLS to play nice with Nostr, especially for group chats.\n\nI think I more or less understand how your proposal would work, as nostr:nprofile1qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qyg8wumn8ghj7mn0wd68ytnddakj7qg3waehxw309ahx7um5wgh8w6twv5hsqgzxpsj7dqha57pjk5k37gkn6g4nzakewtmqmnwryyhd3jfwlpgxtsnyw5n2 explained it. I assume that since you still don't see the pubkey of the sender, each side of a given conversation would have its own public conversation code?",
  "sig": "f5618e60af840a5e56aaa24f30d6b1421e6f166cdfb4e8cbdd1357a120dd908f9d283ec68c6522cac70b66145bea242b877f8efecd6d907d078aed213eccba8f"
}