Element Installed via Flatpak Won't Search Encrypted Rooms

[NoraCodes]

Duplicate of element-hq/element-web#23437 because @t3chguy didn't want this issue on that repo.

Steps to reproduce

1. I open Element, installed via Flatpak, on Fedora.
2. I open an encrypted room.
3. I click the circled-magnifying-glass icon in the top right hand corner.

Outcome

What did you expect?

I expected to see a search bar and get messages as results when searching.

What happened instead?

Instead I see a search bar which doesn't give me results and the message "Use the Desktop app to search encrypted messages".

Operating system

Fedora Linux

Application version

"Element im.riot.Riot 1.11.8"

How did you install the app?

Flatpak im.riot.Riot

Homeserver

nora.codes. Synapse 1.66.0 Python3 on Ubuntu

Will you send logs?

No

[SISheogorath]

I've seen this problem as an "on & off" situation in the recent two years. #123

Usually it's an issue with the "Secret Service" and Element not coming together because one of them got corrupted or is unavailable.

Hope this provides some helpful insights. I wasn't able to fully pin it down yet.

[mjg]

With the current flatpak installed as a user flatpak on Fedora 39, I had the same problem. The solution was to allow im.riot.Riot to "talk to" org.freedesktop.secrets on the session bus (using flatseal). I tested with two different profiles, and it seems to work without the two profiles overwriting each other's index key, but I haven't confirmed whether they are separate. (Note: You have to reset the index after doing this.)

[SISheogorath]

Yeah, this is one of these things that are incredibly hard to debug. Why? Because often it just works. The org.freedesktop.secrets bus has a portal. And that should just work, like it does for many people (including me on Fedora Silberblue 39), but then it doesn't. And sometimes it just stops working mid way.

I haven't really figured out a reproducer. So when someone comes across this and faces the same problem with the bus allows, try to turn it off. It's an interesting mess.

[mjg]

Oh, good point. Portals. Which one is it that should handle this?
xdg-portals (upstream) changed recently: They used to apply a default where now they require a config. Some desktop environments or packages have adjusted to that, some not. I'm using i3, and I had to set some portal config so that opening links from a flatpak app would work again (i.e. be directed to a running browser).

[SISheogorath]

I don't know which binary it is. https://docs.flatpak.org/en/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.Secret

[mjg]

Cool! This works. So, in .config/xdg-desktop-portal/portals.conf, I now have

[preferred]
default=gtk;
org.freedesktop.impl.portal.Secret=gnome-keyring;

and reset permssions with flatseal (and restarted xdg-desktop-portal.service). Works!
More specifically, I had to recreate the search index again. As far or little as I understand, access via the portal gives an app specific secret (which is a good thing) rather than access to the main keyring (or to its contens).
My environment is gdm+i3, and one probably wants to me make the config above i3-specific, but that is the easy part.

[SISheogorath]

Exactly, the beauty of the portal is, that everything is namespaced and therefore should prevent access to other apps' secrets.