E2E rooms still have a search button but search doesn't work in E2E rooms.

[lampholder]

Ideally I think we would grey out the search button and clicking on it would either hover-over or pop up a message saying search doesn't work in E2E rooms.

[uhoreg]

Related: #2548

[t3chguy]

@lampholder how about:

[t3chguy]

though obviously won't be as clear if you use gray as your room tint, I'm using the css greyscale filter

[t3chguy]

Also I'm now thinking this won't be the right approach as search can still find unencrypted things in the room, plus Search has the All Rooms option, so @lampholder how about a notice within Search if the current room is E2E that encrypted events cannot be searched?

[lampholder]

Yeah, that could work - even a notice stuck at the top of every search results pane saying something like 'Searching #whatever:matrix.org for unencrypted messages (encrypted message search is not supported)' would be better than just search-search-searching and taking ages finding nothing at all :)

[Nostradamos]

Why not search through local chat history? Also for unencrypted messages, this could be, depending on server and local machine, be faster than using the servers ressources. But just disabling search doesn't really solve the problem in my opinion.

[t3chguy]

@Nostradamos because that is a lot more work and there's typically only tens of events in memory. Plus that is #2548 so please track that instead, this issue is a quickfix until then

[lampholder]

This just bit me AGAIN, sat stupidly watching the pulsing magnifying glass in an E2E room.

[adrianog]

Question: is this meant to be fixed at one point (if yes, what's the issue #); or is it intended functionality that should always work like this (and why?)?

[t3chguy]

It'll be eventually possible for users that opt to run their own matrix-search daemon locally.
github.com/matrix-org/matrix-search is the thing to follow.

[MountainX]

It'll be eventually possible for users that opt to run their own matrix-search daemon locally.
github.com/matrix-org/matrix-search is the thing to follow.

That project is dead. What should we follow now for the latest on E2E search in Riot?

[t3chguy]

https://github.com/matrix-org/seshat

[jakem72360]

If I trust the code running on my homeserver, and my connection to it, I'd like for there to be an option where my homeserver can access my key backup (temporarily), and perform the search itself. I realise this would require changed to the Matrix spec, but is it something that we could feasibly look at in future?

If E2E rooms are to be the default, then giving up search functionality altogether is too much of a dealbreaker IMO. I personally trust my homeserver enough for something like this, and I think most self-hosting users do. As long as it's disabled by default and the client issues a warning for enabling it.

[aaronraimist]

@jakem72360 I don’t think that’s a good idea. The room might as well not be encrypted if you are willing to do that.

[aaronraimist]

The plan is to do local client side search of encrypted messages as per #2548

(Is this issue worth keeping around?)

[jakem72360]

@aaronraimist I don't believe it's the same. My server is a physical device that I trust. It's no different from me literally installing Riot on the server and performing the search myself.

Searching client-side would be useless unless the client caches every message (out of possible thousands), as the time to retrieve and decrypt is just too high. This is something that should be done server-side, only provided the user is aware of their actions.

[jryans]

Hmm, but a key goal for E2E messaging is that you do not need to trust the homeserver. Maybe some do (if they run it themselves, for example), but that's a small subset of people, and everyone should be able to benefit from E2E even without that.

As @aaronraimist mentions, we'll be solving this with client side search, so I don't see a need to keep this issue open with that work in flight.

The implementation does indeed cache every message (in E2E rooms only) locally.

[jakem72360]

@jryans Riot/Synapse already takes ~20s to load and decrypt the most recent messages of a room, and that's on a Core i7-3820 sharing a LAN with the homeserver. Locally caching every message in a room just for search functionality is technically unfeasible. Some rooms have thousands of messages going back years. I'd rather not waste storage duplicating that information over a laptop, desktop, phone, etc again, just for search. Furthermore, on mobile devices where CPU consumption, battery life and network usage are a priority, I'd rather Riot didn't continually download messages from my homeserver over an extended period of time.

As for your point on "trusting" the homeserver; Matrix is just a spec. Nothing about E2E encryption, can actually guarantee that the homeserver doesn't decrypt messages server-side if given keys. Nothing would stop a user patching Synapse or writing their own implementation. I think it would be more productive to look into safe methods of performing server-side search, and incorporating them into the spec. First thing you could do, is make encrypted search a server-side config, disabled by default. Meaning, large sites like matrix.org won't have the responsibility of handling user keys/decrypted messages if they don't want the burden (afterall, this should really be for homeservers). If the sender truly objects to this behaviour, perhaps a tag could be added to messages telling servers not to decrypt them for search purposes (or better yet, implement unique keys for servers themselves, allowing them to act as clients somewhat and also negating the need for key-sharing). Just some ideas.

I genuinely don't believe client-side search is viable in terms of performance, nor sensible in terms of resource consumption (wastage). But hey, that's just my 2¢.

[t3chguy]

It doesn't use all that much space tbh

[dylangerdaly]

Recently my Element profile got corrupted, I have a backup of my Element profile before this happened, am I able to manually restore my backed up search cache?

What sets the password for SQLCipher? I can't find any good documentation on how this is supposed to work.