> Because doesn’t the protocol assume that messages propagat...

codonaft

npub1alptdev5srcw2hxg03567p4k6xs3lgj7f6545suc0rzp0xw98svse7rg94

hex

501d4b6b1bdb13369dbc60de89a56c82b3408cd2fd5d668d69db54f91417a42a

nevent

nevent1qqs9q82tdvdakyeknk7xph5f54kg9v6q3nf06htx345ak48ezst6g2sprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgswls4kuk2gpu89tny8c6d0q6mdrggl5f0ya226gwv833qhn8zncxglq072m

Kind-1 (TextNote)

2026-03-23T06:07:57Z

↳ 回复 事件不存在

b7ff33598e0b6276afae04d20833f3d24e544f30a06761e8edcc4ddd80f988ce...

Because doesn’t the protocol assume that messages propagate to other relays as well?

There's at least a mention of NIP-70 (protected events) in the MIP-00. Perhaps NIP-70 could be a requirement for all Marmot events?

I also find it scary that Marmot allows usage of relays that don't require NIP-42 auth.

Almost all events should be private IMO; the auth should be required whenever possible.

or controlling the whole stack (incl relays).

How does running my own relay solve that problem exactly? How would I then ensure that my messages are not being stored by any other relay?

If you're using NIP-42 auth whenever possible, control your client and relay (you're sure the relay and your client won't propagate events to unexpected relays, and the client will actually remove the events)—only your DM buddy with their unexpected relay list or broken client would be able to propagate the events to unexpected relays.

The broken client is not something controllable in the FOSS world. An immutable list of relays that all sides of communication explicitly chose to use for the conversation still could be possible. But at some point these relays will be outdated for example, so a new conversation would need to be created. Feels like a wrong complication. Any better ideas?

原始 JSON

{
  "kind": 1,
  "id": "501d4b6b1bdb13369dbc60de89a56c82b3408cd2fd5d668d69db54f91417a42a",
  "pubkey": "efc2b6e59480f0e55cc87c69af06b6d1a11fa25e4ea95a439878c41799c53c19",
  "created_at": 1774246077,
  "tags": [
    [
      "e",
      "91d13fed7e25eeba8534b7a01e149a73912d89eaa8088bfb3650acd66d0383a8",
      "wss://nos.lol",
      "root",
      "577de06dce160a0379163a4bb7b680be3e0a0e1c68de6e6ba8c01134b44064dd"
    ],
    [
      "e",
      "b7ff33598e0b6276afae04d20833f3d24e544f30a06761e8edcc4ddd80f988ce",
      "wss://nos.lol",
      "reply",
      "577de06dce160a0379163a4bb7b680be3e0a0e1c68de6e6ba8c01134b44064dd"
    ],
    [
      "p",
      "577de06dce160a0379163a4bb7b680be3e0a0e1c68de6e6ba8c01134b44064dd",
      "wss://purplepag.es"
    ],
    [
      "client",
      "nosotros",
      "31990:c6603b0f1ccfec625d9c08b753e4f774eaf7d1cf2769223125b5fd4da728019e:1728437063755"
    ]
  ],
  "content": "\u003e Because doesn’t the protocol assume that messages propagate to other relays as well?\n\nThere's at least a mention of NIP-70 (protected events) in the MIP-00. Perhaps NIP-70 could be a requirement for all Marmot events?\n\nI also find it scary that Marmot allows usage of relays that don't require NIP-42 auth.\n\nAlmost all events should be private IMO; the auth should be required whenever possible.\n\n\u003e or controlling the whole stack (incl relays).\n\n\u003e How does running my own relay solve that problem exactly? How would I then ensure that my messages are not being stored by any other relay?\n\nIf you're using NIP-42 auth whenever possible, control your client and relay (you're sure the relay and your client won't propagate events to unexpected relays, and the client will actually remove the events)—only your DM buddy with their unexpected relay list or broken client would be able to propagate the events to unexpected relays.\n\nThe broken client is not something controllable in the FOSS world. An immutable list of relays that all sides of communication explicitly chose to use for the conversation still could be possible. But at some point these relays will be outdated for example, so a new conversation would need to be created. Feels like a wrong complication. Any better ideas?",
  "sig": "1574a70a8a32b014db03f1ba3c9f6ba11cc448ce4b24804a27bbb9b1ea024c45e7f757256ed48db2f948003f0071cabad068f6270d22aa71ecbcccd44fb5e1b9"
}