-
Notifications
You must be signed in to change notification settings - Fork 18
Description
this is a duplicate on purpose, we do not want to repurpose the current issue in order to satisfy the customer request
Matrix.to links, when posted in Element timeline, should transform from their URL format to a 'pill'
To satisfy the customer request we're scoping the below behaviour to apply to permalinks only. If a user sends a raw MXID it should not pillify. If the user sends a matrix.to permalink, this should be a pill in the timeline.
Matrix.to links to a room/space
- When a room's Matrix.to link is pasted into the composer and sent to the timeline, it should not show as the URL but instead the pill.
- where the user has used markdown send a permalink to the room, the pill overtakes the markdown label
- where the user has used markdown to send a permalink to a room or space, the markdown label should be shown (hyperlink) instead of the default pill if the user doesn't have access to the room/space details
Matrix.to links to an MXID
- When a user enters a "@mxid"/@DisplayName, it should transform into a pill. When clicked on, the pill should show the user details
The user's name and profile picture should render in the pill itself. Like this: | ![]() |
If this is not possible, the pill should show the default user icon and the mxId : |
![]() |
- Verify if this is the case on all 3 platforms today
- where the user has used markdown send a permalink to the user, the pill overtakes the markdown label
- where the user has used markdown to send a permalink to a user, the markdown label should be shown (hyperlink) instead of the default pill if the user doesn't have access to the user details
- If the user pastes an MXID and has not selected the pill, it should show as text (similar to today) see internal discussion
Matrix.to links to a message in the same room
- When a user has shared a Matrix.to link to a message in the same room,
it should show like this: | ![]() |
If we failed to retrieve the event or the sender details, just show "Message" as a pill with the link icon |
![]() |
- Before committing to this we need to better understand the performance implications in this case, if it's a drag on resources for the app then we should implement the below for all message matrix.to links.
- where the user has used markdown send a permalink to the message, the markdown label should be shown, not the pill
Matrix.to links to a message in a different room
- When a user has shared a matrix.to link to a message in another room
it should show like this (with the avatar and room name): | ![]() |
If these are not available, apply the same logic as above (the pill should show the default room icon and "Room") | ![]() |
- where the user has used markdown send a permalink to the message, the markdown label should be shown, not the pill
We're not aiming to change the behaviour of the pills, just polish the feature and extend the functionality to matrix.to links for specific messages. IE: If the composer renders the pill, that should continue to be the case.
We will not do Alias handling or URL 'pillifying' in this round, though we should look to improve those things in the future. We also will not update the share dialog at this time.
Notes
- We need to understand what would happen if the pill wraps over more than one line
- We need to understand what state each platform is currently in, and whether we should create fixes, or start from scratch
- The RTE team have their own issue tracking this version of the work - we will not implement anything in the RTE, instead they will aim to match the behaviour we're implementing. As both composers will likely live alongside each other - this feels like the best approach
Future
- In the future we need to consider how we pill more items (like MXIDs) however, for this round the T&S complications were such that it falls out of scope for our project. We need to be cautious about what and how we reveal to users on other users' profiles - especially in a community setting.
- We chose this approach for the connection with markdown and pillifying due to some technical constraints. We should monitor user feedback and revisit this decision in the future if needed.