Fallback for incomplete threads

[daniellekirkwood]

When a user is invited to a restricted room that already has threads and messages, what should their experience be?

Discussion:

• Users should be able to see messages that they have permission to see.
• Users may not be able to see Threads from the Thread Summary on the Timeline (because they do not have access to the Root Message)
• Users should have access to the Thread from the Thread List view
• Users should only see a Thread in the Thread List view if they have permissions to see at least one response (if all messages in a Thread are restricted to them due to permissions, it should not appear in the Thread List view)

Needs:

The user has access to the Thread messages (they have access to) from the Thread list view;

• 1. How does the Thread Summary in the Thread List view look
• 2. What message do we share with the user when they don't have access to the root message

When the user has clicked to view a thread that they only have rights to see part of;

• 3. How does the Thread look like (if the user cannot see the Root message, or the messages following...)
• 4. What message do we share with the user when they are viewing the Thread but have access to view only a few of the most recent messages

---

Design

Figma: Restricted History Threads.

[daniellekirkwood]

@janogarcia Assigning you and tagging X-Needs-Design as you will need to provide designs to help with this use case.

Please add any details that I might have missed following our conversation this afternoon :)

[daniellekirkwood]

@clokep & @gsouquet

Please let us know how much granularity we may be able to show in the error message (items 2 & 4). Depending on what the server/client knows will impact how we communicate with the user!

Thanks!

[clokep]

When a user is invited to a restricted room that already has threads and messages, what should their experience be?

This was discussed a bit in chat, but this doesn't have to do with restricted rooms (which manage who can join a room), but with who has access to the history of a room. Technically this concept is referred to as "history visibility" in the spec and has three options:

1. World readable: anyone can read the events (so this issue doesn't apply).
2. Shared: any member can read the events (so this issue doesn't apply).
3. Invited: events are accessible since a member was invited.
4. Joined: events are accessible once a member joins the room.

For the specific questions above:

What message do we share with the user when they don't have access to the root message

I would recommend re-using language from a quote reply from a message which you do not have access to. It is a similar concept.

What message do we share with the user when they are viewing the Thread but have access to view only a few of the most recent messages

I wonder if it makes sense for it to show up in the thread pane or if they should just be in the timeline? This isn't ideal, but might simplify some of this. It would give different users different views of the room though, which isn't great.

Please let us know how much granularity we may be able to show in the error message (items 2 & 4). Depending on what the server/client knows will impact how we communicate with the user!

When trying to access an event that does not exist or is not visible the server returns a 404 with no information as to why it is not visible. (There's no way to tell if it is a "real" event without permission to be seen or if it is a bogus event ID.) This is done on purpose to prevent privacy leaks. In practice the only time this should happen is if the user doesn't have permission to see the event, so I think a generic error message about an event being inaccessible is probably fine.

Note that the server will currently not respond to requests for the full thread in this case either, as the root message is not visible. I'm not sure if this is good or bad, but it fits the currently specced behavior of how relations work.

[daniellekirkwood]

The content in this error message in other parts of the app is :

Unable to load event that was replied to, it either does not exist or you do not have permission to view it.

[daniellekirkwood]

James' document regarding all Federation concerns: https://docs.google.com/document/d/12LDwoQ2xQDpZBW52bHMw6U7MLg4jcjw5By480QXxpzU/edit?usp=sharing

[novocaine]

Although federation might cause similar symptoms, this ticket isn't related to federation, its related to history visibility. We should probably keep it that way, and have a separate ticket for dealing with federation issues.

[janogarcia]

@daniellekirkwood @novocaine @gsouquet I put together some mockups for dealing with this specific issue. You can find my notes on the relevant section on Figma:

→ Restricted History Threads.

I'm copying below a snapshot of those notes for convenience.

As for other particular issues introduced by federation, I agree with James that those should be discussed in a separate issue.

Note: Today's a national holiday in Spain, and then I'll be on vacation the next two days. I won't be able to follow up on this until next week.

---

Copied from Figma:

Restricted History Threads

Edge case: The user can’t view messages in a thread prior to her join or invite date, due to room permissions.

In the thread list, we’ll show a notice for restricted history threads, telling the user about that limitation. As we can’t fetch the actual content for the thread’s root message, we’ll append the message event ID, as a way to differentiate between restricted history threads. It’s far from optimal, but there’s no other useful data we can rely on.

Any thread that is getting new replies since the user joined or was invited (depending on room’s permissions) should appear in the user’s thread list.

Threads in which the latest reply happened before that point in time shouldn’t be visible to the user, as there wouldn’t be any viewable content for them.

We should also consider — post P0 milestone and if technically doable, and performant — replacing the original root message with the first reply viewable by the user, and somehow communicating that condition properly to the user.

In the thread view, we’ll show a notice before the first message that is viewable to the user.

https://www.figma.com/file/T309ztx0sNyOOK6NKVLHsK/Threads?node-id=2761%3A308969