-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Persistent chat messages #2560
Comments
I agree, persistent chat would be a gamechanger and ever so convenient ;) |
I'd like to pose a question in regards to implementation of this. Would it be better to log client side so if you're not on you can't see the messages. Or make it persistent to the server so when you login you can see messages from the day? |
I personally don't have a need for client-side. Leaving offline messages for users/chatrooms would be great to have. |
I'd prefer client-side logging of messages. If you do it server-side, there is always the chance that single users don't want their messages to be stored. |
https://github.com/mumble-voip/mumble/blob/master/src/mumble/Log.cpp This should be the class that controls the messages that go into the chat messages. (Hopefully i'm right) My thoughts on how to accomplish this. define file save location |
That's the feature I really miss in Mumble. Any updates? |
We'd need to come up with a design for this first. Since Mumble supports HTML messages, the log format would need to include images. People send Mumble images inline in messages most of the time (data: URLs). That means that log files would quickly grow big. How would Mumble store the logs? Should they be stored per-session? Single file per server? A new log file per day? Etc. etc. |
As written before, it seems to me that it is best to store logs for each user, because there is a possibility that someone will not want his logs to be stored on the server. From my point of view, we need to give users the choice of how long to save logs -- day, week, month, year or as much as they want themselves (including forever). Lastly, to be convenient to understand, I think it is better to save logs of text chat separate for each voice chat. |
So if the idea is server side, I think that is up to the admin to decide, not the user. While yea it would be cool to offer flexibility for ignoring users from chats, I'm of the opinion per channel will would provide the easiest steps forward. Length of time, i'm flexible on personally. If i need logs rotated out i can just setup log rotate on my own box. |
Any progress? |
Unfortunately not, but we will start working on this after #3465 is completed and merged. |
Thank you for reply. |
You're welcome. Feel free to write here any suggestions you have about the feature. |
Well, I also wish that mumble had a persistent chat, just like discord. Of course, logging should be able server-side, so when let's say you're on holiday for 3 weeks and you come back, you can read what your co-workers have been discussing in the meantime. However, as for the design, what we also have to take into account is that it should then be possible for someone to write an private message to a contact who is offline, which is then waiting on the server until he logs back in. This would finally make it possible to replace discord with mumble in so many, if not all cases, and that would just be incredibly awesome, considering that mumble runs on Windows XP... |
I have an idea about persistent chat that may solve the "I don't want to be tracked users"
|
Well good idea, but then it should be also possible to set the whole thing per channel, so for example within my company I would like everything to be persistent, just like Discord or IRC with a bouncer.
|
This is actually the major point keeping my friends and I from switching from Discord, etc. Aside from the switch decision, it'd also be good to have some logrotate functions in there for the log itself. Iterate through like chat.log, chat.log.1, chat.log.2, etc to however many are decided by the team. This would all depend on settings that were established by the server admins themselves. Even better would be per-channel chat log settings assigned based on channel name or channel ID. In that case, you could create _chat.log. With that the server could parse and load in the log based on the channel name or even channel ID (depending on which is more convenient). |
As a supporter of privacy I think you should consider some things:
My Recommendations:
For server logs:
Edit: Added point 3 in general |
I think the suggestions by toby are overkill. Specifically, logging should be available for any channel, not only password protected ones, and their permissions should be the same as the channel by default. The user should be made aware that the channel/server is logging before they send a message, since they won't get logged if they don't send any messages. Encryption, expiry, and size of logs should all be configurable, to allow setups as strict as tobys or as (insert opinion here) as discord. |
I should specify that I would use Toby's settings for my own server, and agree that any privacy-respecting server should, but it doesn't fit all use cases. At minimum a user should be informed when logging is active, and be able to view the logging settings (who can view logs, expiry, etc) but anything beyond that need be adjustable. I also think client side logging should only be available as a mirror of server logs. A user should not have to worry about another user joining chat, and suddenly they're being logged. |
@josephsmendoza This means:
Now there might be some things open to interpretation, like:
tldr; Sry for the long text, but doing unlawful things can get expensive (just search for "gdpr fines" and you will see how high the costs can get). |
@toby63 everything what you wrote applies to audio recording too, which is already possible without consent. |
No, because there is an important difference: Also: Just because something is done, doesn't mean it is also lawful, or done in a lawful way. |
I'm going to try and keep this train from running anymore off the tracks. You should never bring up the LAW of a specific country as it will not apply. The reason for this is because in the terms of use you could easily make the user give up ANY rights by using the program. You just let the user know that if he/she installs and uses the program their information may be recorded and used. This is how all software agreements work just look at Microsoft, Google, Facebook if you want to see some real scary terms lol. Users are okay with this they will just click next and the ones that are not don't install the program anyways. Before any of you say No remember the terms now pretty much cover this already ;) |
@IIIXJokerXIII |
@toby63 i agree with @IIIXJokerXIII that we're getting into semantics of how to apply the law instead of the feature request itself. With regards to implementation, I can understand informing the client-side users of the update. If the server gets updated and has this built in at that point, yes, it would be important to let people know that logs are being saved for SOME period of time. The HOW of the matter would likely require adding entries into logrotate or some other way of log rotation to ensure that data is only retained for as long as server admins want to keep it. At that point, the logs start to iterate and roll off. Making sure that these chats stay specific to individual channels is also important instead of having a global chat that spans across multiple voip channels. How the association would be handled per channel would be outside of my knowledge |
We are here to talk about Mumble. Mumble is a tool, like any other software. A tool should not be opinionated, and this tool is not specialized to GPDR countries. The implementation should allow the end user/admin to customize such settings to their requirements, so let's leave the privacy and law concerns to them. I believe this feature makes the most sense serverside, as a way for offline users to see old messages. If I'm not mistaken, murmur is cross-platform, so the initial implementation could be plain text files per channel, and then logrotate, database, etc, can be added after the most basic implementation is done. |
Yeah thats kinda obvious (no offense), my point was that auto-resizing (like you mentioned) could also make saving logs better (smaller file size). |
Ah ok, personally I'd still want the ability to save original quality. |
@Krzmbrzl Maybe we could structure this a bit?
Concept Factors and Ideas for Server-side logs:
Legal requirement: For example the GDPR (the General Data Protection Regulation) of the EU (European Union) requires at least for companies and organisations to implement multiple things (asking for approval etc.) |
I don't think we really need to split this issue. To me it seems that ultimately what everyone aims for is a way to have persistent chat. Thus this essentially all belongs into the same issue 🤔 I added your summary to the first post though 👍 |
If we don't split the issue, then we should specify that the main log has to be on the server for offline users to see missed messages. I think client side log should effectively be an opt-in cache of the server log. If the server has logging disabled, I don't think a user should be able to log those messages (at least not as a feature of mumble), since other users may be specifically avoiding having their messages logged. I don't like either of the denial options, especially as the first would allow a user to effectively override server settings. I think that if a user doesn't want to be logged, it should be enough that they know a channel is logging, as they can simply not send any messages in that channel and they won't be logged. The exception method would likely have most of its framework implemented by the implementation of the "option to disagree later" laws, but I'll refrain from commenting on that since my opinion differs from the law in that matter. I think E2E should be a separate issue to have all of mumble's communications be possible over E2E, but like stated before, mumble is not a tool for secure or private communications. I believe anything not required by law or for a functional persistent chat should be discussed in a separate issue. |
This seems overly complicated and will put load on the server for no reason. Especially with a lot of users. It'd just be duplicating the messages for everyone, it would have to send them the messages, and then also send each person them again to actually log them. Ontop of this, it would not be hard for someone to just modify the Mumble client to just log everything that comes through even if the server disallows logging, so idk. I mean I understand making it more difficult, so if that's the goal then sure. However I still think the logging should be done client side, and if the server disallows it, then just grey out the checkbox for that server. But the actual logging should be done client side, and maybe sync up once they connect to get missed messages. |
You're taking what I said too literally. The client logs should not literally be only a cache of the server logs, but the effect should be the same, hence 'effectively'. When a client connects to a channel, it might request the chat log for the time it was disconnected, or for the last few messages, or something like that. The client should log messages itself while connected to a logging channel, but it should not be able to log independent of the server. It's not a matter of making it more difficult or trying to stop people from logging, but rather that the mumble client shouldn't implement spyware like features such as invisible logging. |
In that case we should add that to the first post too.
@josephsmendoza
It is: #1813 |
Quite frankly not sure how else I was supposed to take it, I read it as I understood it. But it looks like we're on the same page as far as the actual logging goes.
Except for this part, which I can't say I entirely agree with. Again my original point is Mumble itself is FOSS, anybody can just take the client and fork it, and make it so it can essentially log anything without much trouble. I think it would be a small waste of efforts to try to prevent logging in that sense, however again as I said if it's to make it more difficult (i.e. not have it baked directly into the client that's understandable). IRC itself can do client side logging, and log pretty much everything. I can't say I view Mumble as much different as far as the text chat goes, and I don't see the major issue. I think it would be nice for an implementation that shows whether or not users are logging, like a little icon. It could be up to the users to hop to another channel, server, to chat. I can't say Mumble should be used for sensitive information in that sense either, so I don't see this being a major worry. If a user wants to self-host, he can simply password protect the server. But I think it's fair to expect logging from anyone when going on other servers, as they can be basically considered untrusted. Now as for my suggestion on direct messages, I think there should be some questioning on whether or not logging should be on that, however it should 100% be end to end encrypted and the server itself should have no knowledge of the conversation, only the two users. So at most, server side logging shouldn't matter there? Just whether or not users would be able to log direct messages. Again Mumble could be forked and someone can just log anyways, so it may be better effort to just do indicators, to show whether or not someone is logging. Just throwing some ideas, I could be totally wrong take my post with a grain of salt. :) |
any updates on this? |
No |
still waiting for this |
Well great, but that doesn't get this any closer to being implemented. |
I think it's safe to say that anything that can be used for good, can be used for evil. Given the technology landscape such as it is, I think more people appreciate Mumble because it doesn't warehouse data it doesn't need to. I've seen a few statements in this request regarding user consent and it doesn't really help sell the idea of collecting information that a user may or may not understand how or why it is used in the first place. I am willing to concede that it would be nice to have a chat history for nostalgia purposes, but the only really widespread use I see for this feature will be enforcement in lieu of understanding how ACL's work. I would rather see more time devoted to educating people about that and building out a smarter user and group management feature set than keeping communication histories that may or may not be used to exploit users. The fact that the legal aspects were front and center in the request should be enough to say we probably shouldn't proceed this way. After all, laws make sense when you agree with the person or group that advocated for them. When they are implemented they have a way of coming back to haunt people even if they safely operate within them. That is territory we probably shouldn't subject developers, admins, or users to if it can be avoided. Mumble's primary function and focus is VoIP. Chat is a nice accessibility layer and a fallback in less secure scenarios. It doesn't behave like other similar applications, nor should it in this regard. Given that and the failure to agree on the ethics and merits of this request I suggest we close this. |
Let's be more clear about why we want chat history: to be able to catch up
on messages that were sent when we were offline, or to send messages for
offline viewers to see when they come online.
The legal ramifications of such a feature are the problem of the server
operators who enable those features. The developers may choose to build the
feature to be compliant with those laws or not, or to build a bare bones
version now and make a compliant version later. That's not a reason to
dismiss the feature outright.
This thread is ethics heavy because some participants are, whether
willfully or not, ignoring that.
|
Sure, but it makes more sense for the implementation of Mumble to remain simple so the attack surface remains small. There were other technical challenges mentioned that would incur overhead on the client. The expectation would also be to encrypt the chat at rest creating overhead at both ends. On low population servers that may be minimal depending on the algorithm, and conversely the overhead could be massive on high population servers. I don't see what the benefits would be in that regard, either. Mumble isn't a pane of glass experience and that seems like a feature already. The fact that erroneous data isn't stored by Mumble is a boon not a bane. |
When you say "encrypt the chat at rest", I'm assuming you mean when stored
on the drive? I don't think that is a widely held expectation. I would
expect the messages to be encrypted in transit, in the same way I expect
any online communications to be encrypted. But how it's stored I would
expect to be configurable, all the way down to plain text. And like I've
said multiple times in this thread, all of this would be configurable
anyways. If you don't want chat logging, don't turn it on for your server.
That's not a reason to oppose it's implementation in the first place.
|
Yes, "encrypt the chat at rest" means when it is stored on the client and server. That is the definition of the concept. It is already encrypted in transit. Did you have some implementation you would care to share about how else the history would be stored so it would be accessible? I already gave a reason why I would oppose the implementation and that is from the perspective of channels. The original request is as follows:
It puts everyone, including the team, at risk. It could also degrade Mumble as a viable option to closed source options that farm data like Discord. I think the only compromise for the features you are discussing is a messaging queue that is applied on a per user basis possibly as a PM. It would listen for someone else to come back online, deliver the message, and forget it on both ends. That seems more reasonable and we probably could have rationalized that. |
To be honest, the most recent arguments against implementing this feature sound like a cheap excuse. For example, if someone really wants to "exploit" that functionality for something important, it is already possible. Everyone can copy chat & save it in a text file. Same thing with jurisdictions. A lot of the law talk is very pointless, because it's only really necessary for huge servers. Most servers are either invite-only or really tiny. There are only a few huge ones, as there aren't that many users in total, to begin with, compared to other services. Finally, the "attack surface" or "overhead" arguments really sound extremely made up. We are talking about keeping the content of a chat, which already is implemented. That's it. The chat is not the core point of the application, but it is extremely crucial. I think, it's at least as or even more important, than the chat functionality in other services, which have a chat heavy focus, because if you're going to use this application's chat, it'll probably be for key elements of the conversation. My point is, this is a small feature with huge benefits. |
Both of you are welcome to submit a PR for review if you have something in mind that is both secure and doesn't increase the latency or overhead. |
I also have to concede that I don't think the recently presented arguments against this feature are particularly convincing. And to make things clear: Everything that goes into the direction of "but the server admin could do x with the chat history" doesn't make much sense, until we implement E2E for chat messages. Because as it stands, the server already has full access to messages in clear-text and thus the admin is only a small patch away from extracting that data on-the-fly (same as for voice data btw). Another thing raised was latency: I believe this is a non-issue for text messages for the following reasons:
And in terms of conforming to laws: I think that in the end we don't care. Only the server admin has to care. And as long as we make this feature configurable (so that it also can be turned off) this shouldn't be an issue. |
We have been providing mumbler servers for our small gaming community for years, and this feature would be aboslutely incredible to have in mumble.
|
I'd also like to start providing mumble as part of a business IT infrastructure project I'm working on. I'd love to see this feature being implemented, even if it is very basic support at first. |
I've been watching this request for almost a decade now. Is there a branch anywhere that shoehorns this functionality into mumble? |
I don't think so |
This comment was marked as off-topic.
This comment was marked as off-topic.
Can we agree that data at rest (chat history) can simply be stored in the existing salted database and enabled by the server owner using a configuration flag? This option can be disabled by default. |
Yeah, that'd be the way to go. |
This was posted a few years ago on Sourceforge and probably got lost here on Github. I'd really like to see this feature, too:
"It would be really nice to have a chat log. Like a constantly logging text file in the client directory. This would create a different text file for every channel, user private message, or global. Basically a different text file according to who the message was sent to or received from. This could be opened regardless of whether mumble is open or not. We have sound recording (which is awesome), why not text logs?"
https://sourceforge.net/p/mumble/feature-requests/961/
Summary:
Activation & Privacy:
Encryption:
Logs (Technical details and options):
Special Feature: Limit participating users? To ensure the number of people being able to read the logs is limited.
For example with:
Additional Features:
Legal requirement: For example the GDPR (the General Data Protection Regulation) of the EU (European Union) requires at least for companies and organizations to implement multiple things (asking for approval etc.)
See #2560 (comment) for details.
Implementation
Either client-side logging or server-side logging, or a combination of both approaches, for example:
The text was updated successfully, but these errors were encountered: