processone / processone/fluux-messenger

Support ack / read in 1-to-1 conversations

Open
#5 0 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement planned
Dominant language
TypeScript
Stars
429
Forks
30
Avg merge
6h 12m
Merged PRs (30d)
126

Description

Show whether a one-to-one message was received and read, and let trusted contacts see when their messages have been read.

Goal

In a one-to-one conversation, the sender can see that a message was delivered and then read. This gives the same feedback users expect from other messengers, while keeping the read state private from contacts who are not trusted.

Protocols

  • XEP-0333: Chat Markers, sending displayed when the reader actually sees a message and handling markable on outgoing messages. Markers are cumulative: one displayed marker covers every earlier message in the conversation.
  • XEP-0184: Message Delivery Receipts, optional, for a "delivered" state distinct from "read". Decide whether to support it, or only chat markers.
  • XEP-0490: Message Displayed Synchronization, already implemented for syncing our own read position across devices. Outgoing markers must be derived from the same canonical read pointer, never from a second notion of "read".

Scope

  • Sending read markers is limited to trusted contacts. Proposed definition: a contact with a mutual presence subscription. Never send to strangers, and never send from a conversation that is not actually being viewed.
  • A user setting controls sending: on for trusted contacts (default to decide), or off. When sending is off, displaying the markers other people send is still possible, and the reciprocity rule is a product decision to record.
  • Display: a compact per-message state (sent, delivered if XEP-0184 is supported, read) on outgoing messages. Because markers are cumulative, show "read" once on the latest read message rather than on every row.
  • Multiple devices: reading on another device (known through XEP-0490) must not send duplicate markers, and a marker already sent is never retracted.
  • Encrypted conversations: define whether markers are sent in the clear, as they are metadata only, and document it.

Out of scope

  • Group chats and rooms, tracked in a separate issue.
  • Typing notifications (XEP-0085).

Dependencies

Build on the consolidated read-state model (#1081) and after the current read-pointer fixes have landed: clearing room unread badges at the live edge, and releasing stale XEP-0490 pending markers. Outgoing markers must follow the forward-only read pointer and never move backwards (#1076). Anchors use MessageRowRef (docs/MESSAGE_IDENTIFIERS.md).

Acceptance

  • A marker is sent only when a trusted contact's message is actually displayed with the window focused, and never for a history load or a background catch-up.
  • Received markers update the outgoing message state, including when they arrive through MAM after reconnecting.
  • The setting is respected immediately and persisted.
  • Tests cover: trusted versus untrusted contacts, cumulative markers, markers received out of order, multi-device read with no duplicates, and the setting off.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the consolidated read-state model in #1081 and the current read-pointer fixes, then read docs/MESSAGE_IDENTIFIERS.md for the MessageRowRef anchors. Trace the existing XEP-0490 synchronization and message-state handling before deciding how the listed protocol and trust rules fit. Done means the acceptance tests pass for trusted contacts, cumulative and out-of-order markers, multi-device reads, and the setting off.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
distributed-systems, frontend, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.