Skip to content

Conversation

@jimcullenaus
Copy link

This relates to messages by @jtrees in element-hq/element-meta#2829. It's unknown how long the bug will remain, but at present users face a situation where settings do not do what they expect, with nothing explaining the problem. This PR doesn't fix the underlying issue, but does tell users that there is a bug.

@andybalaam said in that thread "we may get around to actually providing the feature before we get around to removing the option", but with a simple text fix, that doesn't need to be the case.

Feedback on the exact wording of the message, and translations to other languages, would be greatly appreciated.

@mxandreas
Copy link
Contributor

Note: these settings currently do not work in encrypted rooms.

I am afraid that this note will add as much confusion as it removes, leaving an impression like nothing works in encrypted rooms, which is not true.

Sharing history in encrypted rooms will start to work very soon (with the small caveat that it only works when a person is invited and not when they join via a space), so believe it is the best to proceed with the approach and copy outlined in element-hq/element-meta#3029 (comment) which also foresees a Learn more link that explains the nuances and edge cases.

@t3chguy
Copy link
Member

t3chguy commented Dec 1, 2025

This note also being shown in unencrypted rooms is unhelpful.

@jimcullenaus
Copy link
Author

@mxandreas "leaving an impression like nothing works in encrypted rooms, which is not true", isn't it? The impression I got from reading elsewhere is that encrypted rooms basically don't allow viewing history. But as I said in the initial PR, I am very much not tied to any particular wording.

@t3chguy if this were intended as a permanent fixture, I'd agree. But the intent is to add in some text right now to save the exact confusion that sent me down a troubleshooting rabbithole for an hour, before searching online and stumbling accidentally across the fact that this is a known issue.

I've seen it said that this will be fixed "very soon". But unless that "very soon" is sooner than pushing out a very basic addition to the text, I think it's worth doing. I don't know what Element's release process is like, but I have deliberately proposed a solution small enough that it makes minimal impact on other aspects of the application, and contains no real logic requiring testing, so it could (subject to release processes) be pushed out literally today. And can be removed with minimal effort once the meaningful fix is in.

@jtrees
Copy link

jtrees commented Dec 6, 2025

Just wanted to say thanks for moving this issue forward.

@richvdh
Copy link
Member

richvdh commented Dec 11, 2025

Hi @jimcullenaus, thanks very much for working on this. We discussed it within the weekly team meeting today, and our thoughts were:

  • The wording you propose is likely to add as much confusion as it saves. We probably could come up with some helpful wording, but writing good copy is harder than many people think. I'm sympathetic to the view that we shouldn't let perfect be the enemy of good, but we do have to balance that with the fact that Element Web has suffered in the past from too many developers and not enough design, leading to some pretty bad UX.
  • Due to annoying reasons, changes to strings have to be done via the localazy UI, so we couldn't land this as-is in any case.
  • We're hoping to land Production-ready encrypted room history on invite element-meta#2829 very early next year (I was hoping for this year, but that looks unlikely now). We're worried that if we make this change now, we'll forget to back it out again when it is no longer true (and in any case, keeping track of it and then doing so is extra work for someone 👋 )
  • One solution that was suggested was to gate the changed text behind the feature_share_history_on_invite labs flag, so that we return to the designed text once the labs flag is enabled (or the feature comes out of labs). That would help solve the problem of remembering to back out the change, at the expense of adding more complexity to the logic (and thus making it harder to maintain and eventually back out).
  • Even if we did land this today, it wouldn't make it into an Element Web release until 13th January, so would probably only last a few weeks before it needed removing again. Given this has been broken for... 10 years? ... it doesn't feel like a great return on investment.

In summary: we'd prefer not to land this. But thank you, again, for trying to make the product better.

@richvdh richvdh closed this Dec 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Z-Community-PR Issue is solved by a community member's PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants