mirror of
https://github.com/mumble-voip/mumble.git
synced 2026-03-03 00:46:56 -05:00
[Feature Request] Persistent chat messages #1009
Labels
No labels
GlobalShortcuts
Hacktoberfest
accessibility
acl
asio
audio
bonjour
bsd
bug
build
certificate
ci
client
code
documentation
external-bug
feature-request
gRPC
github
good first issue
help wanted
help-needed
ice
installer
linux
macOS
needs-ckeck-with-latest-version
needs-more-input
overlay
positional audio
priority/P0 - Blocker
priority/P1 - Critical
priority/P2 - Important
priority/P3 - Somewhat important
priority/P4 - Low
public-server-registration
qt
recording
release-management
server
stale-no-response
stale-support
support
task
test
theme
translation
triage
ui
windows
wontfix
x64
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mumble-mumble-voip#1009
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lichtmetzger on GitHub (Sep 21, 2016).
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 https://github.com/mumble-voip/mumble/issues/2560#issuecomment-620195673 for details.
Implementation
Either client-side logging or server-side logging, or a combination of both approaches, for example:
@cap-42 commented on GitHub (Oct 7, 2016):
I agree, persistent chat would be a gamechanger and ever so convenient ;)
@Kamori commented on GitHub (Oct 9, 2016):
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?
@cap-42 commented on GitHub (Oct 10, 2016):
I personally don't have a need for client-side. Leaving offline messages for users/chatrooms would be great to have.
EDIT: that came out wrong. What I meant was, I haven't been able to find a bot that spits out the chat history either, and personally wouldn't know where to start. What class takes care of relaying text chat?
@lichtmetzger commented on GitHub (Oct 16, 2016):
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.
@Kamori commented on GitHub (Oct 17, 2016):
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
on init load the file and populate Log window with the data
close file
on chat/message insert open file for write and append, close file
@shumvgolove commented on GitHub (Mar 11, 2018):
That's the feature I really miss in Mumble. Any updates?
@mkrautz commented on GitHub (Mar 11, 2018):
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.
@shumvgolove commented on GitHub (Mar 11, 2018):
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.
@Kamori commented on GitHub (Mar 11, 2018):
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.
@shumvgolove commented on GitHub (Jan 14, 2019):
Any progress?
@davidebeatrici commented on GitHub (Jan 14, 2019):
Unfortunately not, but we will start working on this after #3465 is completed and merged.
@shumvgolove commented on GitHub (Jan 14, 2019):
Thank you for reply.
@davidebeatrici commented on GitHub (Jan 14, 2019):
You're welcome.
Feel free to write here any suggestions you have about the feature.
@XP-Fan commented on GitHub (Sep 12, 2019):
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...
@IIIXJokerXIII commented on GitHub (Sep 16, 2019):
I have an idea about persistent chat that may solve the "I don't want to be tracked users"
4.Give Admins control over the size of the server's chat log file size.
This gives users control over how much they want to be tracked & at the same time is limited by the server's file size set by admin
@XP-Fan commented on GitHub (Sep 17, 2019):
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.
@mctoddenstein commented on GitHub (Feb 11, 2020):
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).
@toby63 commented on GitHub (Mar 17, 2020):
As a supporter of privacy I think you should consider some things:
This is a big privacy concern, especially if other people than a fixed group (examples for others include: admins & new members) can have access to the logs.
The fairest option would be to ask for permission per channel.
My Recommendations:
General (and for client logs):
For server logs:
Edit: Added point 3 in general
@sugoidogo commented on GitHub (Apr 24, 2020):
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.
@sugoidogo commented on GitHub (Apr 27, 2020):
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.
@toby63 commented on GitHub (Apr 27, 2020):
@josephsmendoza
While I can see specific use cases for your unlimited concept (like a server just for members of an organisation), I want to add one layer to the already existing layer ("what should be done").
This layer is "the law":
I guess many of you have heard about the GDPR (the General Data Protection Regulation), which is defacto a European Union Law.
While I am no lawyer, i understand it like this:
Note: This applies mainly to server logging.
Client logging might be a different case.
We can assume that:
* chat logs are personal data
* chat logs are not necessary (data processing)
* mumble is a project in the EU (?; many of the dev-team seem to be in europe)(irrelevant for this specific law topic)* many servers are in the EU and many users are in the EU
This means:
Servers (or rather their owners of course):
1.a) Some interpretations go even further and say that the permission must not be a requirement to use the service (so users could disagree and still use the server).
Now there might be some things open to interpretation, like:
If the server is just run by a private individual for "purely" private purposes the GDPR does not apply (see Article 2, 2.c), but there might be other (national) laws for these cases.
Also the question is, what are "private purposes"?
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).
So I wanted to clarify that.
@streaps commented on GitHub (Apr 27, 2020):
@toby63 everything what you wrote applies to audio recording too, which is already possible without consent.
@toby63 commented on GitHub (Apr 27, 2020):
@streaps
No, because there is an important difference:
Audio recording is done and stored by the user.
I was referring to server logging (maybe should clarify that above), which is done and stored by/in the server itself.
So server logging (and recording) is a clear case of the law (imo), while client/user recording (and logging) is not.
Nonetheless there might be other laws to apply to that.
Also: Just because something is done, doesn't mean it is also lawful, or done in a lawful way.
@IIIXJokerXIII commented on GitHub (Apr 28, 2020):
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 ;)
@toby63 commented on GitHub (Apr 28, 2020):
@IIIXJokerXIII
You missunderstand.
My law topic is not about the software (mumble), it is about the obligations of the server owners, as they will use the software.
Now mumble can of course say "we don't care", but it would be much better to help the server owners by adding options to comply with the law.
@mctoddenstein commented on GitHub (Apr 29, 2020):
@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
@sugoidogo commented on GitHub (Apr 29, 2020):
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.
@sugoidogo commented on GitHub (Apr 29, 2020):
It would be nice for murmur to default to the most reasonable option per-platform once they are available.
@streaps commented on GitHub (Apr 30, 2020):
@josephsmendoza so you think it's not relevant that people who run a public murmur server or the mumble project itself could get legal troubles?
It's also not only about the European laws (there are or will be similar laws in other countries), it's also about the user. I do want to know if my conversations are logged and for how long.
@streaps commented on GitHub (Apr 30, 2020):
Sorry, but this is bullshit. If you offer a public service to users in the EU there is no way TOS around the GDPR. If it were that easy the GDPR would be useless.
@sugoidogo commented on GitHub (Apr 30, 2020):
@streaps I'll assume you weren't reading my posts, or are having a hard time understanding them, so I'll simplify my statements for you. Murmur should let admins do what they want with logs. Users should be notified of logging settings. Admins are responsible for keeping their logging legal. Additionally, logging should be disabled by default. Does that address all of your concerns?
@streaps commented on GitHub (Apr 30, 2020):
No
@sugoidogo commented on GitHub (Apr 30, 2020):
@streaps can you elaborate?
@Krzmbrzl commented on GitHub (Apr 30, 2020):
Absolutely not. While it is true that from a legal point of view, it is the admin's responsibility and not the one of the Mumble Team, it is also true that we can easily lose the trust of our users if we implement something like this sloppy (in a way that let's admin do whatever they want).
Thus we should take special care to prevent these scenarios. If you disagree with the implementation of a specific feature (like the logging of chat messages), you can always create a fork of the project and change the implementation. That is your right and that's also the beauty of FOSS.
@sugoidogo commented on GitHub (Apr 30, 2020):
@Krzmbrzl I should clarify that I mean admins should be able to change settings like log expiry, encryption, permissions, and size without mumble enforcing restrictions on those settings. I'm a little confused by your comment because I don't know what you would be restricting, or what this scenario is.
@Krzmbrzl commented on GitHub (Apr 30, 2020):
Ah then I guess there has been a misunderstanding. I was thinking you meant that admins should have unrestricted access to all log messages at all time.
Of course I agree that the settings about how long chat-logs are saved, etc. are up to the admin. However in my opinion the option whether or not chat-logs are saved encrypted is not an option I see fit for being under the admin's control. This falls in the category of data-safety a Mumble user can expect when using the official client & server.
@sugoidogo commented on GitHub (Apr 30, 2020):
I think encrypted by default would be the best implementation, as part of sensible defaults. For example:
The user could receive a pop-up or otherwise flashy and non-optional warning upon entering an unencrypted logging channel, which advises them to treat it like posting on the open internet.
@Krzmbrzl commented on GitHub (Apr 30, 2020):
But why would you want to be able to disable encryption in the first place? I actually don't see a valid use-case for that, nut maybe I just don't have enough imagination atm ^^
@Wadera commented on GitHub (Apr 30, 2020):
Example:
Enable true encryption on multi user chat isn't something easy to manage. You need to get some authority who can manage keys, authorise new users etc. It can be difficult to understand and use by "ordinary user".
Use case: Mumble server hosted on home server - I'm admin and have full access to hardware and software on root level. No one have access to this server anyway and I'm using it for gaming with my friends. It's just 5 people who joining and sending links or chat about World of Warcraft / PUBG etc. As we are only users on this host and we can see this chat anyway - there is no real risk and no reason to play with RSA key sharing, permission managing and learning my friends how to get access to mumble server from laptop and PC and get ability to read chat.
@sugoidogo commented on GitHub (Apr 30, 2020):
An example might be a public server with a public channel with logging enabled, where the encryption is pointless because anyone can join the channel and scroll back up, might as well save the CPU cycles since such a server likely needs all the performance it can get.
@Krzmbrzl commented on GitHub (Apr 30, 2020):
Yeah the example of a public server anyone can join to read the messages is a good one (might be more difficult though as one had to keep in mind that you might not be allowed to join certain channels and thus you can't read the chat history there).
I think that if anyhow possible the whole log-encryption stuff should work "automagically" and thus probably without most users even noticing. I don't know how feasible that is though (definitely no crypto expert here) 🤷
@sugoidogo commented on GitHub (Apr 30, 2020):
Log settings should be per channel so that same server could have a moderator channel with encrypted logs. The encryption could be done with the same keys used for tls, since log encryption would also be pointless if the messages are sent unencrypted in the first place.
@IIIXJokerXIII commented on GitHub (Apr 30, 2020):
Simplicity Simplicity Simplicity. I repeat myself because the only way this project moves forward in a timely manner is to keep it simple! I've already seen many projects fail because they became too complicated. If it becomes too complicated Devs will not want to work on it and server owners will become frustrated for thinking the program lacks what they see as basic chat features now days. Losing more users to other programs is not something the murmur project needs right now.
Like my 1st comment but with more detail
Now if a user had his history setting set at 3 only 3 days of his post are saved to the Server Chat Log. If that same user now changes that setting to 0 then the server will purge all of that users post when he disconnects or make a button to purge my messages from server. This would delete any of that users messages out of the Server Chat Log past his history setting value. <--Make this work and you could get more detailed with it later like the server log could be per channel and the purge could have options like only purge this channel of my messages or maybe per channel history setting so many options could be added. Discord would not have anything on this privacy & history WOW 👯♂️
@toby63 commented on GitHub (Apr 30, 2020):
Feature-wise:
related to #1813
Like I already said, the perfect scenario would be for chat logs only to be visible to participants and not to the server owners and everyone else.
I know this is a bit complicated, but there might be a solution for this, like seperate group-passwords (maybe in combination with a certificate) used for encryption.
My opinions:
I also don't see reasons for this; if I set up a server just for my friends, this server is of course access-restricted.
Mumble is no forum.
@josephsmendoza
One general thing:
I don't understand why some people here see my comments as invalid or negative.
All I say is that mumble should consider implementing options, so that server owners can comply with the law.
And if you look at the law, you also see that this is (mostly) good practice (asking for permission, encryption, information for users etc.).
Thankfully some users and devs see what I'm up to and agree 🙂 .
@Wadera
As @Krzmbrzl already pointed out, the whole encryption should run automatically in the background.
There are of course some potencial challenges for the developers (if we want stuff like End to End Encryption etc.), but in general its all about the usual encryption (certificates or keys are created by mumble and then used in the process).
@IIIXJokerXIII
You still ignore what I already pointed out: guessing what users said is still possible if the messages of their correspondents are visible.
Also the problem of Plausible Deniability remains.
Per channel settings are much better.
@Kamori commented on GitHub (Apr 30, 2020):
Hello everyone, unfortunately I'll be unsubscribing from this issue as I've moved on to just using Discord as it fits all my needs.
Having said this. I think there are a lot of good points here. But there seems to be a lot of over-engineering around a feature that doesn't exist yet. Perhaps we need to take a step back, create a functional prototype, and worry about non-technical issues ones we have a working base.
Keep up the good work, and I'm excited to see what Mumble turns into in the future!
@toby63 commented on GitHub (Apr 30, 2020):
@Kamori
I am sure the developers will do exactly that.
But having a concept before starting the work is mostly better, because changing the code structure afterwards (to for example fill in something that was not considered before) is maybe unpleasant work.
That said, if you think about it, the easiest way would be to just implement client logging.
@IIIXJokerXIII commented on GitHub (Apr 30, 2020):
@toby63
You're missing my point you're over thinking it. If you need a system that secure you should not be using mumble or like someone said above make a new branch yourself with that level of detail as the average user will never need it. It's overkill for a dev to put that much work in to making it so a user can not guess what you may have said lol. In the end look at it from a dev point of view as to how much work will need to be done to get this in and as always keep it simple. I just like to offer up ideas but let the coder/dev decide how complex he/she wishes to make it.
@toby63 commented on GitHub (Apr 30, 2020):
@IIIXJokerXIII
I don't think this has really something to do with complexity.
This is all about a concept.
Your concept ignores nearly every security and privacy aspect and as I have pointed out, this is not only valuable, but also a legal requirement (at least in many cases).
That said, of course the world is free.
@XP-Fan commented on GitHub (Apr 30, 2020):
@toby63:
" I don't think unencrypted chat logs should be allowed." If it was like that, I'd immediately leave and switch to discord out of principle. I would never accept having to encrypt something on my physical hard disk drive, be it on my desktop or my server. If I'm the only one having hardware access, then why the heck should I fuck up my processors like that? And yeah, I know that discord uses electron, but hey, there are IRC-gateways and unofficial clients, so, … Anyway keep in mind that with E2E it's getting hard for people like me who have about 30 different computers around, for the sake of being able to test handwritten assembly on different processors, and I want to have my main chat client everywhere. So, get over it, not everyone wants your encryption-nightmares, so if the mumble-devs really wanna code them, I'd beg them off to keep it optional, not enforced.
From: toby63 [mailto:notifications@github.com]
Sent: Donnerstag, 30. April 2020 18:46
To: mumble-voip/mumble
Cc: XP-Fan; Comment
Subject: Re: [mumble-voip/mumble] [Feature Request] Log text chat messages (#2560)
@IIIXJokerXIIIhttps://github.com/IIIXJokerXIII
I don't think this has really something to do with complexity.
This is all about a concept.
Your concept ignores nearly every security and privacy aspect and as I have pointed out, this is not only valuable, but also a legal requirement (at least in many cases).
That said, of course the world is free.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/mumble-voip/mumble/issues/2560#issuecomment-621970645, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKEBHTOVDRHDNNFHEGIUIMLRPGTMLANCNFSM4CQL3WYQ.
@Krzmbrzl commented on GitHub (Apr 30, 2020):
@XP-Fan could you please check your tone in this discussion?
Anyways I don't think that the discussion continues to bring a lot of new arguments at this point. I guess everything important has been said now and lately the discussion seems to have drifted into a battle of opinions. Thus if you don't have new arguments, I'd ask you to just +1 the posts that you agree with (and perhaps -1 the ones you don't).
From my point of view (as a Dev), I agree with @toby63 that it is very beneficial to have an idea of where a feature might go in the future when one is beginning to implement it.
That being said though I think ultimately it'll come down to the Dev that ends up implementing this feature. We have listed a lot of pros and cons for various degrees of security/encryption and as this is an OpenSource project, that Dev will most likely implement this as he or she thinks it is best. And I think this issue now give s solid ground to make up an opinion about the topic ☝️
@toby63 commented on GitHub (Apr 30, 2020):
@XP-Fan
E2E would not necessarily be mandatory. So where is the problem?
It would only be an additional feature, which was requested far before me (around 2015).
But yes regarding chat logs that are saved on the server, I would only implement an E2E solution. But as you said, its not my decision, I only give arguments.
Also 30 Computers? And you use them all to chat on the "same account"?
Also thats always the same argument against E2E.
Think about it, if you use a service like facebook, steam etc. on other computers, you have to log in as well, so why not copy the identity/certificate one time?
Mumble could even make it easier, with just a string of characters to copy into a textfield.
To remind you, many programs including mumble already use encryption (it seems to me that some people around here don't realize that...).
But ok, I agree with @Krzmbrzl all arguments are shared now.
I will maybe only add a compressed concept sometime.
@IIIXJokerXIII commented on GitHub (Apr 30, 2020):
@Krzmbrzl
I agree it's good to have an idea of where the feature might go but I just wanted to point out that over thinking it can be deadly for the whole project. I'm a dev also just not with the murmur project yet and we've had a few things fail because we were over thinking them. We had spent so much time that when we finished it with all of it's glory nobody was still around to enjoy it. Our users had moved on to other things. I would really hate to see that happen here with such a great project but to over look this could be a grave mistake. IMO murmur is in a scary place right now as to user count. Back in the day Murmur held the titles for best in performance, features and simplicity but that is no longer the case. As great of a program as it is users are not hanging around waiting on features like this anymore. Too many simpler solutions are out there now picking off murmur users left and right. If this project turns into a catch up for it's competitors features and does not have it's own unique appeal it's over anyways. It's great to have fresh new ideas but if you don't hold them to the Simplicity idea they will never see the light of day imo.
PS @toby63 Please don't think I'm being an ass it's easy to confuse an ass with passionate person. I'm very passionate about the project because I've seen more than 200+ servers with more than 3000 users drop to 1 server with less than 50 users. This was my wake-up call and to be honest I'm starting to run out of reasons when debating with my users now why we should stay on mumble. :/
@toby63 commented on GitHub (Apr 30, 2020):
@IIIXJokerXIII
Join the team 🍻 .
I would do it, but I don't have coding skills.
Thx for pointing that out, because I had the impression some people here are pretty hostile and I think that is not justified.
Well I understand that, but I use mumble because it is open source, free and private.
Most other services are surveillance tools.
And I think mumble can never compete with this stuff, because mumble is open source.
What people want (I always see that with social media etc.) is a centralized service, but mumble is not a centralized service, thankfully.
@sugoidogo commented on GitHub (Apr 30, 2020):
This conversation has been entirely derailed by privacy and encryption concerns.
These are not major points for this project, as evidenced by the fact that a server admin can already see all data that moves through their mumble server.As stated on the mumble home page:If you want privacy, then you should establish trust with your server admin or host it yourself. Sensible defaults should align with your suggestions, but a server admin should be able to scale that down or up as per their needs. A user should be able to view all log settings that a server is using so that they can decide if it's acceptable for them. I won't be discussing these points any further in hopes of focusing this conversation on the feature request. You can agree or disagree with your up/down votes.
@toby63 commented on GitHub (May 1, 2020):
@josephsmendoza
That is surely not meant the way you interpret it.
It means two other things:
I still don't see valid reasons for wanting non-encryption other than eavesdropping on the users and mumble should prevent that.
I don't understand this talk about focus, what focus? What else is there to discuss? And why are the privacy aspects not a valid part of this discussion?
@XP-Fan commented on GitHub (May 1, 2020):
@toby63
Well yeah, I'm aware that mumble encrypts the communication running through the internet, and that's kinda okay for me, aside from that I would be happier if it had an option to disable all encryption if the server is within the same LAN or VPN. Anyway, What wouldn't be okay is if I had to store my chat logs in an encrypted form on my local hard disk drive, as that seems to be an entirely sick thing to me. That being said, I never understood those people who are encrypting their hard disk drives. To me it's an insanely silly waste of valuable CPU-time. However, being an liberal-minded person, I think that everyone should have what he or she wants to. So I guess it would be best if mumble had the option for those who want it, but it shouldn't force it onto people. In my case for example an discord-like setup would be just perfect, with the only exception being the server not located at discords, but in my basement. Ah and as for my 30 computers, well, I do use an multi protocol messenger, so my credentials for Discord, Facebook, Skype and XMPP are saved in plain text within a file on a network drive (which is of course only accessible from within my LAN/VPN), and from there all 30 computers can log on as I power them up. Same goes for the chat logs, so I can always continue my conversations from where I left off and I know what I have been chatting about with a particular person recently, no matter on which computer I am.
" But yes regarding chat logs that are saved on the server, I would only implement an E2E solution." Ah, now I guess we are on par: So you are actually suggesting a setup in which the chat logs would be encryptedly sent to the server, stored there, and the clients would fetch them and decrypt them again, effectively ensuring that the server / server owner cannot read the contents? Well this might indeed be a reasonable default, however I'm not sure whether it would be allowed in the US. However, I was thinking that you want to dictate to the admins that they have to store their logs in some form of encrypted database and the server would always need to decrypt it, send it to the client, therefore of course reencrypt for the sake of TLS, then again retrieve a message from the client, decrypt it and reencrypt to store it in the database. This would be insanely stupid. However now it makes sense to me. Though I would definitely want to be able to store my client side logs in plain text, in txt-files or something similar.
@XP-Fan commented on GitHub (May 1, 2020):
Âh well one interesting thing which just popped into my mind is that if you prevent the servers from having access to the logs that's of course awesome for privacy, but it would definitely pull you out entirely if you ever wanted to add an server-side searching feature, for example, which companies for example might want if they're hosting servers for their teams which are internal anyway. So, as I said, nice idea, would be even great as a default, but effectively enforced, …, dunno… As you can see, there might be cases where it's either just not necessary, (think about a scenario where an admin creates a server for a closed group where he is in himself, or the company-example I mentioned), or where it even hinders, E.G.: server-side searching. Anyway, I have to lash back with my aggressions from yesterday and excuse myself, as it seems I misunderstood your suggestion. Assuming that I got it right now, it's definitely a valuable point and it shall be considered as an option, probably even a default setting. Anyway to finalize things I would say that since we have a whole bunch of opinions now, I guess there is only one sensible conclusion: It shall be as configurable as possible, so that anyone can scale it to fit exactly to their needs. I guess it would be fine if Toby's setup would even be the default setting, for those who don't want to fiddle and just want "the shit to work". But still as I said it shall all be configurable…
@sugoidogo commented on GitHub (May 1, 2020):
@XP-Fan your replies are including the messages you reply to, can you go to github and clean that up
@mctoddenstein commented on GitHub (May 1, 2020):
I just want to be able to use my mumble server to keep funny links and chat logs that my friends and I share for longer than the session that I'm logged in for. Sure, as the server admin, I can go back and scroll through the mumble.log file and see everything, but my friends can't.
I'm not particular on HOW an implementation occurs. simple is always going to be better. It looks like the server is already using sqlite so if the DB is packaged with the service, wouldn't it make sense to establish a key-value pair with the pre-existing channel_ID's and an associated log file for log rotation? Then use the mumble-server.ini file to have corresponding values for that?
Example:
Worth noting in the example would be that the logrotation should happen based on either size OR time, whichever criteria is satisfied first.
I'm by no means a dev or programmer, but I work as a Tier 3 Support Engineer for a software company. Looking at config reference files and looking over core code every so often to understand a piece of it isn't outside the scope of what my daily duties are.
I feel like the example above could absolutely use some love in the way of tuning/tweaking, but I think this is a step in the right direction for figuring out how to make sqlite and logrotate play nicely together.
With all of that said, I'm not trying to get into the nitty gritty of politics and how to apply law here. I think a basic model of how to move forward is more important than getting bogged down with all of the details first. I think a rough draft of this is more important to continue moving forward with this feature request. Technical details can be worried about later when it's closer to being finalized.
@sugoidogo commented on GitHub (May 1, 2020):
@toby63 you seem to have the mindset that the server admin is always a 3rd party. Like xp-fan mentioned, and plenty of users have popped in to say, companies or small groups of friends actually want their admins to see chat logs. These cases are not matters of privacy, it's required for the use case. If the user is made aware that admins can see logs before they send a message, then their privacy has not been violated. I want to focus the conversation on implementation details like @mctoddenstein has suggested. Which I think is a great idea, but I wouldn't put the admin in full control of the notification, perhaps in addition to those settings, a chrome-style lock icon could be present in the message bar to indicate log encryption/permission status. Unlocked = non-participants have view permission, red = unencrypted logs, and it obviously wouldn't show up at all if that channel isn't logging.
@XP-Fan commented on GitHub (May 1, 2020):
@josephsmendoza
Well that might be hard because I'm blind and there is hardly anything for me which is as challenging as webUIs. Anyway I'll ask a friend of mine to do it over anydesk, and ensure to cut off outlooks quotations in the future, like here for example. However thanks for pointing out…
@toby63 commented on GitHub (May 3, 2020):
Some technical stuff first:
server-side searching (suggested by @XP-Fan):
In E2E-mode searching per channel could be possible (only for participants of course).
Difference between the two concepts of encryption for chat logs (because there seems to be some confusion):
End-to-End-Encryption (E2E) for chat logs:
Like said above, it ensures that only the participants can read the chat logs and not even the server admin/owner etc. can access it.
This is my preferred setup/method and I hope everyone can see why this is useful.
But I admit that there are open questions (like authentification aside from mumble server) and it should probably be optional (🌵), but default.
Regular Encryption of Chat logs:
Some people here question why it is even useful.
Here are the reasons:
Regarding the key/password necessary for this to work properly; well I guess every system has a key-store-software on board, so it could be saved inside it and activated by regular login or (and thats what most people will not like) by a seperate password.
@XP-Fan
Thank you for agreeing on that.
Yeah I saw the political debate about prohibiting E2E (crazy stuff), I still hope it does not get implemented that way, but I admit that would be a game changer (and would make the optional part necessary).
👍
Even though you only missunderstood it halfway.
To clarify my position, I respect your opinion of not wanting (non-E2E)encryption (of chat logs) (though I don't understand it), but I still disagree with it 🙂 .
Reasons see above.
@mctoddenstein
A (good) programmer will always start with a good concept, that includes all things that seem to be necessary (or good) at the time of drafting the concept.
The big advantage is:
The first piece of software might not include all the functions, but it will be designed in a way, that the "missing" or additional functions can be implemented easier.
@josephsmendoza
Well, lets agree to disagree in many points, but we maybe could agree on two things:
So that might be something the potencial developers of this feature could consider as default.
He just repeated what was already clear.
@seniorm0ment commented on GitHub (Jun 23, 2020):
Unrelated to server side logging, I'd love to see a way to be able to log user messages client side, even better if not in plaintext (encrypted).
I assume it'd be fairly simple to implement (as an option of course)-Just select which servers you want to log, what types of messages (user messages, disconnect/connects, etc.), have it just constantly append to a text file (log) at the location of choice, and just give users the choice to auto-purge after a user specified time of choice.
This overall would be nice for servers who don't log messages, it would be entirely clientside, and will help maintain a conversation on reconnects or timeouts, a more persistent feel, etc. and of course again, if users don't want to log they can choose to keep it off. This way nothing has to get logged on the server period (aka servers don't need to enable it just to maintain messages, servers can give even more control to the users), but if a user wants to log on their side they can. Or the server can just enable logging, but that's not the point to be clear.
As for the encryption part, I'm not entirely sure, that may or may not complicate things. Would be very nice though of course so it's not readable by anything/one but Mumble and the authorized user.
Maybe this could be paired with signing the log with your Mumble certificate so they go hand in hand (If your certificate is imported into Mumble, the logs are viewable, otherwise not). Just an idea.
Also I do agree that users should be notified if the server logs or not.
@mctoddenstein commented on GitHub (Jun 24, 2020):
@grravity I'm not sure that setting this to client side is going to be the best option. I think server side management would be better for the sake of alerting users to the activity.
server side: 1 notification when you access the server "Hey, just so you know, this server has persistent chat logs"
client side: 1 notification every time a new user decides to save the information client side " has decided to use persistent logging" " has decided to user persistent logging"
The client side would also require rules for people who might want to opt out of logging which would mean that each and every client connected to the server would need that set of rules applied to their client. That's a lot of overhead for the server to write that every time and then pass it to every client connected to it.
The server side option basically just keeps that list local, updates it, and then null-routes any chat logs from who has opted out of logging.
@seniorm0ment commented on GitHub (Jun 24, 2020):
@mctoddenstein I'm not saying to not allow logging server side, I'm saying to also allow users to log locally if they choose.
There's only one negative I can think of, and that being that not everyone in the chat will have the ability to control other users logging choices obviously (one person can log everything without other users knowing, maybe this can be combatted with an icon next to their name if they have logging on.). But in defense against that, the text is literally already viewable to everyone, and I can't imagine it'd be too difficult to setup logging for Mumble if someone wanted to log messages.
This is possible to do on IRC clients, I honestly don't see the harm in implementing client side logging on Mumble. Again if someone planned on doing something malicious with logs, well not having a button (in a completely FOSS program mind you) to enable logs, probably won't stop them from finding a way to log messages anyways.
I think it'd be nice to be able to log messages client side, imo I'd prefer servers to keep it off and users log client side if they wish. One because server logs are all in plaintext, two because it's nice to be able to just have logs locally. But again, not saying to not allow servers to log, I'm just suggesting the ability to also log client side.
@mctoddenstein commented on GitHub (Jun 25, 2020):
@grravity That's totally fair. I know that people are going to log if they REALLY want to. I think my head was pointing more toward the sustainability/implementation side of things.
I don't actually know which would be easier to work with as I don't have a lot of C++ knowledge. I can parse through components and get an idea of how they work, but if I wanted to start writing in it, I'd be hard pressed to know where to start.
@theAkito commented on GitHub (Jul 30, 2020):
There have been some really good points made already, thank you to everyone involved for engaging in this discussion and keeping this issue alive, until it is actually solved. 😃
However, I really do not understand the privacy concerns. I am a privacy advocate and think that privacy is a human right.
But this is my stance on this issue:
Finally, from my own personal experience, which is a big reason for how I view this situation:
Sometimes I use TeamSpeak, because a couple of friends host their own TeamSpeak servers and people prefer using something known over something unkown, like Mumble. The servers have permanent logging enabled; you can read old messages that are months old. The only type of reaction from discovering this feature I got from users of this server was always positive. I have never seen anyone complain on those servers that messages are logged. It was the opposite. We all found it cool and super convenient.
Conclusively, privacy is an important thing for me, however at the same time I don't see a privacy problem in the logging of silent chat messages on a voice chat server, that is most of the time used by gamers, as far as I know. I think if you are so privacy concerned that this bothers you, you shouldn't join a Mumble server to begin with. Go use a fully E2E encrypted service with GnuPG, etc.
@kaymueller commented on GitHub (Oct 5, 2020):
Hello there,
I also think the option to enable serverside logging using the DB would be the way to go. And I don't think there is a real need to encrypt it in any way.
IMHO most people use mumble in a closed state with only a handfull of friends to chat during gaming OR they use it as a puplic space to discuss (just like you would with discord). I just want to share some links and cat pictures and take a look at themn some days later.
If I have to discuss something really important I will use Signal/Threema or antoher E2E-enabled communication platform. Nobody will use mumble as a platform for whistleblower. There is (again, in MY opinion) simply no need for mumble to become that kind of privacy related. I just don't want my data at foreign servers that I have no control over and owned by companies that are selling my data. I prefer to have a toolset of applications that each serve one kind of a purpose and do it simple and good rather than having one overkill application.
It should be disabled by start, and there should be a warning that logging is enabled, tho.
my regards,
Kay
@theAkito commented on GitHub (Oct 5, 2020):
@kaymueller
Great explanation, that propably most users can relate to.
@fattywompus commented on GitHub (Dec 6, 2020):
As a user of many platforms who has checked back here pretty frequently for quite a long while wishing for Mumble/murmur to have persistent chat so I can finally get off of Discord... I really don't get this worry and years long debate over server side logs and encryption at all. If I were communicating things I was that worried about someone else reading I would not be doing it on a Mumble server. Especially one that wasn't hosted by myself or someone I trust... whether or not it was supposedly encrypted. And if you do you need to reevaluate your decision making process. There are already plenty of other well established and publicly audited means of communicating OTR or whatever if you require some clandestine form of communication.
If Mumble starts touting itself as having any kind of serious encryption it would open the devs up to unending nonsense trying to stay ahead of the criticism that would ensue if it wasn't the most advanced and vulnerability proof thing around. Rather than being the FOSS, self hosted, discord alternative (which sounds awesome) it would be the encrypted chat platform with known vulnerabilities. It changes all the talking points.
And if you're that paranoid about the server operator what makes you think he wouldn't disable encryption or be snooping in some other way. He literally couldn't be in a better position for a MITM attack. Or some other person in the channel logging or getting screen caps. I mean some reasonable every day type of security and privacy with SSL/TLS or SASL or whatever that can be easily implemented and kept up to date is all good but that's the kind of thing you expect from anything. And you know you're still at risk if someone with the knowledge really wanted to get at your communication. It just gives you reasonable privacy putting you out of reach of the average user or script kiddies.
But end to end encryption as well as at rest encryption, and self destructing server logs. Come on now... are we gonna have to trade PGP keys off network with everyone we talk to as well? Because if we're not then how secure are we really being? It just gets stupid and I don't feel like this level of security worry is what anyone in their right mind expects from Mumble. Persistent chat logs so you can read what went on when you were away or announcements or whatever. Offline DMs and other functionality would be cool but really just simple persistent chat and suddenly we have a fighting chance to get our friends off of Discord. Please don't let some wierdness over pseudo security hold this up.
@theAkito commented on GitHub (Dec 6, 2020):
@fattywompus
Sadly, I can completely confirm your examples. Sometimes, when I do not want to lose a pile of links or whatever was posted in the chat, I just copy the whole chat and paste it into a text file. I am the server host anyway, so what is the point of that? Might as well get out of stone age and let my server do that automatically.
@sugoidogo commented on GitHub (Dec 6, 2020):
For the sake of progressing the issue, can we rename it to "persistent text chat"? I think that gets across the goal of the feature request better than the current title. (Edit: and also may attract less of these privacy zealots)
@toby63 commented on GitHub (Dec 6, 2020):
I don't understand this steady bashing on privacy concerns, if you want this feature implemented, then open a pull request for it.
It's not like the privacy discussion is holding this back.
As @davidebeatrici pointed out, this might be implemented in the future, after some other features are implemented.
Source
Nonetheless there are legal requirements and mumble would do good in helping server admins obey the law.
Also it would be nice, if mumble would take privacy seriously (that does not necessarily mean E2E (though that would be nice)), but it means for example:
I think "persistent chat messages" is a bad title.
@theAkito commented on GitHub (Dec 6, 2020):
First you say this.
Then you say this. Extremely restrictive stuff like this, is exactly what is holding this whole thing back. I can't speak for everyone here, but at least some people here just want server-side chat logging, that's it. Putting up rules like the ones you mentioned are restricting this whole thing and, more importantly, put more blockades in our way than necessary.
I personally would perhaps still accept the first bullet point, even though this cannot even be necessary, from a legal standpoint, or else literally EVERY TeamSpeak server would be kind of illegal. All the other points you mentioned are in my opinion way out of scope for the first implementation. Of course, I have nothing against adding more features in the long run! No issue there. But if we want this to finally work and be implemented, then we it would be unwise to blow this feature up even more with, in my opinion, unnecessary options which you pointed out as necessary, if I understood correctly.
@sugoidogo commented on GitHub (Dec 6, 2020):
I am in total agreement with Akito. To clarify my earlier comment, I don't mean to bash on privacy concerns. They are quite valid and will be necessary for mumble to remain viable when the server host is bound by european law or is otherwise privacy minded, but these are comparatively long term goals. An initial implementation which enables the option of persistent chat as simply as possible will immediately make mumble a viable alternative to services like discord. I would imagine that GDPR compliance could come next, and E2E some time after that.
@toby63 commented on GitHub (Dec 6, 2020):
should indicate very clearly that I don't say it's mandatory (though that is an open question, also depending on the country laws), but I have a right for my oppinion, so I keep suggesting my views/ideas.
I disagree, that basic privacy and activation/deactivation features should be implemented later.
The very basic things should be implemented at first release of the feature.
I think you overestimate the amount of work regarding (most of) the suggestions I make (notification, disable option, log deletion and channel permission). I don't think it will make development much more complicated.
No it is not, or has any developer said that it is?
The only things that keeps this feature on hold, are that:
So if you want it, then develop it, or find a developer.
That can be the case yes.
You have to see that the changes in Data Protection laws (in many countries and regions, not just the EU, though it's already big enough) are relatively new and that the agencys responsible for enforcement are underfunded. So right now it seems that many people, companies and organisations are kind of ignoring the new rules (at least partly) and keep waiting until they receive a warning letter.
The bad side for these people and companies is, that they sometimes have to pay big fines.
@seniorm0ment commented on GitHub (Dec 6, 2020):
Imo privacy and security need to be considered heavily.
That being said I have an idea not exactly about persistent chat but about a direct messaging system. I've expressed my suggestions and opinions on persistent chat in this issue above already.
I was originally going to suggest something like allowing users to set a homeserver they can self-host, however I feel like this goes against the nature of Mumble, with the certificates.
So what I think would be nice, is if two users who have certs and are registered on a server, and have added as a friend, want to DM each other, one can be totally logged out, the other can go into the server, click on the user, send the DM, it is completely end to end encrypted but uses the server as the transport. When the other user logs onto the server, it pings them with the message and they can respond. It would also be logged and saved onto their clients (locally encrypted by mumble, with the ability to export all their chats and import in case of a reinstall).
I think this would be really nice alongside a persistent server chat system.
I think work on chat could be done overall, stuff like allowing larger sized images, auto resizing images, etc. Without the use of plugins. Basic stuff.
@toby63 commented on GitHub (Dec 7, 2020):
@grravity Yes that would be interesting as well.
I think it was already mentioned somewhere.
Still it would be good to open a seperate issue, if it does not already exist.
That is true.
Some of it is also related to this, as @mkrautz mentioned above, one would need to think about log sizes (save images or not, size of images etc.).
@seniorm0ment commented on GitHub (Dec 7, 2020):
This issue could easily be mitigated by just making it optional, just add a checkbox that asks if you want to save images, or set an image size limit for logging.
Or a max log size, or an autopurge timer (slowly clear older log entires as time goes on)
@toby63 commented on GitHub (Dec 7, 2020):
Yeah thats kinda obvious (no offense), my point was that auto-resizing (like you mentioned) could also make saving logs better (smaller file size).
@seniorm0ment commented on GitHub (Dec 7, 2020):
Ah ok, personally I'd still want the ability to save original quality.
However I'd start with compression before resizing
@toby63 commented on GitHub (Dec 8, 2020):
@Krzmbrzl Maybe we could structure this a bit?
Client side logginginto a seperate issue.Concept Factors and Ideas for Server-side logs:
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 organisations to implement multiple things (asking for approval etc.)
See https://github.com/mumble-voip/mumble/issues/2560#issuecomment-620195673 for details.
@Krzmbrzl commented on GitHub (Dec 9, 2020):
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 👍
@sugoidogo commented on GitHub (Dec 9, 2020):
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.
@seniorm0ment commented on GitHub (Dec 9, 2020):
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.
@sugoidogo commented on GitHub (Dec 9, 2020):
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.
@toby63 commented on GitHub (Dec 9, 2020):
@Krzmbrzl
In that case we should add that to the first post too.
@josephsmendoza
It is: #1813
But it is related, so I mentioned it, though we could add the link to that issue in the first post. @Krzmbrzl
@seniorm0ment commented on GitHub (Dec 9, 2020):
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. :)
@asdfghjkl403622 commented on GitHub (Sep 12, 2022):
any updates on this?
@Krzmbrzl commented on GitHub (Sep 12, 2022):
No
@phantomboy0 commented on GitHub (Sep 25, 2022):
still waiting for this
@Krzmbrzl commented on GitHub (Sep 25, 2022):
Well great, but that doesn't get this any closer to being implemented.
Unless you are planning to actually work on this feature, such a comment is kinda pointless 🤷
You can vote for the feature by reacting with 👍 on the original post.
@ghost commented on GitHub (Feb 13, 2023):
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.
@sugoidogo commented on GitHub (Feb 13, 2023):
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.
@ghost commented on GitHub (Feb 13, 2023):
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.
@sugoidogo commented on GitHub (Feb 13, 2023):
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.
@ghost commented on GitHub (Feb 13, 2023):
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.
@theAkito commented on GitHub (Feb 13, 2023):
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 already exists. There is no overhead in using this feature to also keep the content between sessions or save it in some way.
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.
Let's not make elephants out of very tiny & bearable problems.
@ghost commented on GitHub (Feb 13, 2023):
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.
@Krzmbrzl commented on GitHub (Feb 14, 2023):
I also have to concede that I don't think the recently presented arguments against this feature are particularly convincing.
That obviously doesn't mean that I will jump to implementing this though, because I don't have the time.
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.
@hodeskutt commented on GitHub (Mar 26, 2023):
We have been providing mumbler servers for our small gaming community for years, and this feature would be aboslutely incredible to have in mumble.
Really really hoping this will be featured in the future.
@svmhdvn commented on GitHub (Mar 28, 2024):
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.
@jr0n commented on GitHub (Jul 9, 2024):
I've been watching this request for almost a decade now. Is there a branch anywhere that shoehorns this functionality into mumble?
@Krzmbrzl commented on GitHub (Jul 9, 2024):
I don't think so
@Wadera commented on GitHub (Jul 9, 2024):
The same. It seems like Mumble project is quite dead for many years now...
Here is some ChatGPT alternative suggestions:
Here is a list of free and self-hosted alternatives to Mumble or Discord that support logging chat messages:
1. Matrix (with Element)
2. Mattermost
3. Rocket.Chat
4. Zulip
5. Matrix Synapse (with Element Web)
6. Nextcloud Talk
7. Jitsi (with Prosody for chat)
Each of these alternatives offers robust features for communication and collaboration, with varying levels of customization and integration capabilities. They all support logging chat messages, ensuring you have the necessary records for your needs.
@jr0n commented on GitHub (Jul 12, 2024):
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.
@Krzmbrzl commented on GitHub (Jul 13, 2024):
Yeah, that'd be the way to go.
@SleepyRaz commented on GitHub (Feb 10, 2026):
I'd love to see persistent chat messages.
@Xlaits commented on GitHub (Feb 11, 2026):
Honestly, if persistent messaging were to be added, especially with what's happening with the current chat leader, it might make this a nearly perfect program. It would just need Streaming/Video as well, and it would be exactly the replacement I'm looking for.
@Warmag2 commented on GitHub (Feb 13, 2026):
@Xlaits Let's not ask for streaming/video here, as it's a completely different thing and likely massively more cumbersome to implement.
Regarding this discussion, my friends also want persistent chat, and cite it as the number 1 reason to use Discord over Mumble. I understand that the transience of communication in Mumble/IRC/other oldschool social media is a boon in itself, but this software is mostly used by closely-knit friend groups who want to see if something happened while they were away. Just make it configurable and/or add a setting to keep only X days of logs on the server.
BTW: maximum size of image messages is second most persistent complaint that I hear. Making large images a clickable link that would try to open the image in your OS's image viewer would be enough.
@Hartmnt commented on GitHub (Feb 13, 2026):
This will be better but not perfect in Mumble 1.6.x
I (and I think this applies to the other current core maintainers aswell) are totally positive about the idea of persistent chat messages. If we were opposed to it, the issue would have been closed already.
This is a huge undertaking though, and not at the very top of our priority list right now. I understand this is frustrating, but we spend our time working on Mumble based on our own preferences/priorities.
What makes this so hard? Well, first I would like to refactor the chat log UI to make it more accessible and consistent. Being able to address single chat messages programmatically would be a requirement when trying to implement persistent chat messages.
Then we need to implement a network protocol that let's the client request past chat messages in chunks. We certainly don't want to send the entire chat history at once when the client joins. This also needs to be rate limited to prevent abuse. The chat messages need to be stored in the database and we have to come up with a scheme that makes retention time settings possible.
These things take time. If anyone wants to help, we would appreciate it. Just be aware that this will probably not be a one and done PR, but will require lots of work over weeks/months.
@red-dragon commented on GitHub (Feb 15, 2026):
persistent chat would be an amazing feature. server side it would be nice to be able too choose how much chat is retained and sent out. ether by message count or age of message.
Would end up even more useful if one client instance could be connected to a few servers!
@Xlaits commented on GitHub (Feb 20, 2026):
Oh, I'm not asking for that, just voicing my thoughts.