Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
MSC2326: Label based filtering #2326
Some more potential problems:
Hey @dkasak, thanks for your feedback!
FWIW crawling the entire room history isn't always a realistic expectation to have from clients, especially in big and old rooms with thousands of messages and hundreds of servers.
Although I agree with your point, and like your solution, the whole point of using hashes instead of e.g. random opaque strings is to ensure that two clients can only use the same identifier for the same label text. Bearing in mind that we need to be able to use the label identifiers to filter the history of the room server-side (because we're not expecting clients to know about the whole history of the room, see my first point above), opaque strings had the following downsides, all originating from the fact that nothing would prevent 1000 clients from using each a different identifier:
Although what your proposing isn't using a random opaque string, it would still end up having different identifiers for a same label, which would end up causing the issues with filtering I've already mentioned. This
I realise that this explanation belongs to an "Alternative solutions" section of the MSC which I've actually forgotten to add, I'll update the proposal with it.
This was indeed the part I was missing, but I'm less clear on why this ability
I suppose the intent is to enable users wanting to talk about (e.g.) cats to
In essence, continuing an old thread seems primarily useful when you have the
I suppose the desired scenario might be to make labelling a message with
My main concern is that just hashing the labels has a rather large downside of
[*]: Which makes me think of another problem: is
All of this is a result of the fact that we can't realistically expect a client to know about the entire history of every room it's in (which is why we're doing the filtering on the server side btw), rather than the solution described in this MSC.
The MSC aims at allowing both scenarios rather than one to the detriment of the other. We want both to allow users to continue a thread à la Slack if their client can access one of the messages in the thread, and to be able to show conversation topics à la Zulip alongside messages in the timeline. To our (that would be mine and @Half-Shot's) knowledge, the solution that's currently described is the only one that allows both to coexist, because we can't rely on the client to know about every event, thus every possible label in a room.
If anyone has an idea for a better solution that allows for both scenarios, I'd love to hear about it.
Again, that is not an issue with this MSC, and this MSC doesn't aim to solve it.
My take on this is that the current solution makes it as hard as possible for rogue servers to figure out the labels on an encrypted event while allowing the features described to work. I agree on the fact that it's not a perfectly secure solution, and again, if anyone knows about a better one I'd be more than happy to hear about it.
The labels are not public information in E2EE rooms, which is the only scenario in which hashing happens (and is also the reason hashing happens).
I realized I haven't said so earlier, so just to be sure: I'm not advocating for this MSC to gain the ability to list all labels.
Yes, sorry, my wording was not the best. What I meant is that the server will be able to reverse the hashes (and hence read the labels) easily in a very large number of cases, if it wants to. I wouldn't had considered this to be the case for E2EE rooms intuitively, had I not seen this MSC.
That is, unless people start naming their threads with peppers embedded in them. ;)
(also, sorry, I didn't understand Travis' comment; is there a Github threading feature I'm not aware of or was that tongue-in-cheek?)
Would this be applicable for threaded messages as well or is the general consensus to leave this up to MSC1849 and MSC1198? Ex, it could be possible to set the label to an event ID. The issue is that syncing for threaded messages for every message in the displayed history could be costly.