I would love to hear where the complications are that hodlbod (npub1jlr…ynqn) mentioned.
The way I see it, there are three different things happening here.
1. Delivery confirmation - This can be something the client just displays to the sender. I am assuming, of course, the client will know whether the recipient's DM inbox relay responds to the write request. So long as the inbox relay accepts the message, it should be considered "delivered."
2. Mark Read/Unread - This is something only the receiver needs to be informed about, for the sake of not having 99+ "unread" messages every time they log into a new client, or use a new device. As I imagine it in my mind, it would just be a note that is saved to their DM inbox relay that references the message in question with a tag that can be either "true" or "false" depending on whether the message has been read. If they don't have a DM inbox relay to save this note to, the client would prompt them to set one up.
3. Read Receipts - This would be a note sent (gift wrapped) from the recipient's client to the sender's DM inbox relay when the recipient reads the message. In this case, I don't think there would even be a need for a true/false flag. Just the note with a reference to the message's event ID that was read. Also, the recipient should have the ability to opt out from read receipts being sent at all.
Dikaios1517
npub1ku…v3lhe
2025-04-15 04:11:32
in reply to nevent1q…pqwa
Author Public Key
npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhePublished at
2025-04-15 04:11:32Event JSON
{
"id": "e862f5dbf3d146cc43b65751d69bd8e350180cc10f6a26d9fabbd7acad7791b8",
"pubkey": "b7274d28e3e983bf720db4b4a12a31f5c7ef262320d05c25ec90489ac99628cb",
"created_at": 1744690292,
"kind": 1,
"tags": [
[
"e",
"f56503a26e2322767a14d9c27d48a5039cc741ae493630525725d2df68fd21f9",
"wss://relay.damus.io/",
"root",
"17538dc2a62769d09443f18c37cbe358fab5bbf981173542aa7c5ff171ed77c4"
],
[
"p",
"97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"
],
[
"p",
"17538dc2a62769d09443f18c37cbe358fab5bbf981173542aa7c5ff171ed77c4"
]
],
"content": "I would love to hear where the complications are that nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn mentioned.\n\nThe way I see it, there are three different things happening here.\n\n1. Delivery confirmation - This can be something the client just displays to the sender. I am assuming, of course, the client will know whether the recipient's DM inbox relay responds to the write request. So long as the inbox relay accepts the message, it should be considered \"delivered.\"\n\n2. Mark Read/Unread - This is something only the receiver needs to be informed about, for the sake of not having 99+ \"unread\" messages every time they log into a new client, or use a new device. As I imagine it in my mind, it would just be a note that is saved to their DM inbox relay that references the message in question with a tag that can be either \"true\" or \"false\" depending on whether the message has been read. If they don't have a DM inbox relay to save this note to, the client would prompt them to set one up.\n\n3. Read Receipts - This would be a note sent (gift wrapped) from the recipient's client to the sender's DM inbox relay when the recipient reads the message. In this case, I don't think there would even be a need for a true/false flag. Just the note with a reference to the message's event ID that was read. Also, the recipient should have the ability to opt out from read receipts being sent at all.",
"sig": "dbed1a157e00b193f3970e9326ea7005ca46fed47613be3d008a4756d4d5c17777b53d1337798ab866347921ca0cfb785d49fc3e227d0ab21bfd486726f2f65d"
}