Skip to content

Auto-subscribe the current user when someone answers their messages in a thread #5700

@bnjbvr

Description

@bnjbvr

Use case

  • I send an unthreaded message to a room
  • someone (me or somebody else) sends a threaded reply to this message
  • I should get auto-subscribed to this thread (if thread subscriptions are on).

Implementation considerations

Considering the current way automatic subscription works, this is equivalent to subscribing automatically up to the first threaded reply.

Now, we have an issue with the concept of "first" reply, since we get a mix of the sync ordering and the topological ordering for getting the full view over a thread. Let's assume it's not an issue, for the sake of this problem, until we get something like stitched ordering.

Then, this requires being sure that we got the "full" view of the thread start:

  • the root is present and loaded in the thread linked chunk.
    • conceptually, this should be true for the persistent form of the linked chunk. Right now, we're not persisting thread linked chunks yet, so we would just need to look at the in-memory view of the thread to conclude this, but in a persisted future, we may need to look that information up in the database.
  • there's no gap/hole between the root and the first reply
    • this is easy to check in-memory, but would involve a few steps when the thread is persisted to disk.

In addition to that, we must apply this subscription in a reactive manner:

  • when the thread is being formed before our eyes via sync, that is, we get the root and the reply
    • if the root and reply come from the same sync response, the root isn't pushed to the thread linked chunk. This is something we could implement, and that would lead to a perfect view of the thread start.
    • if the root and reply came from different sync responses, there might be gaps between the root and the first reply (if the device was disconnected between the two sync responses, for instance). Lacking sync gaps in threads (but Soon™), we can't represent this clearly, at the moment, and would have to resort to a full back-pagination of the thread, from the end to the start.
  • when the thread is being back-paginated
    • in this case, the root is pushed as soon as the back-pagination's done; in this case, we ought to know that we have the full view of the thread start, because the last pagination didn't have a previous-batch token, and it (likely) contained some events too.

If someone posts the first in-thread reply to one of my messages while I'm away, my client might not see it the next time it syncs. So this would require some form of automatic thread back-pagination, for the in-thread reply to be noticed. This would be useful for other use cases (like implementing a thread activity center as well).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions