[Feature Request] Persistent chat messages

[lichtmetzger]

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:

  • Activation/Implementation per Channel would be best
  • Server/Admin choice (mandatory),
  • Client/User choice (would be good; in some cases legally required (see below))
    • Two methods for denial to choose from:
      • Blocking method: If one disagrees, Logging is disabled for that channel (for the time the client is in it)
      • Exception method: If one disagrees, only their messages get excluded (remaining problem: Content can be guessed from other people's content)
    • Important (Law Stuff):
      • Some laws require approval for each server (so we should not implement a general accept setting; instead a pop-up for each server/channel (at least an option to activate the latter))
      • Also some laws require an option to disagree later and for already saved content to be deleted (so it would be good to have options for that)
  • Alternative to Client/User choice: Only inform the user about logging.

• Encryption:

  • Two topics:
    • Transmission encryption
    • Log Data encryption
  • Two methods:
    • server-side encryption: makes it harder for attackers/other server users etc. to read the logs
    • E2E (end-to-end): logs would only be readable for the users

• Logs (Technical details and options):

  • logs per channel
  • file format: textfile, database
  • log size limits
  • content: text, html, images, more?
  • storage time: days, weeks, months, years, unlimited
  • compression
  • auto-resizing of images (would be useful in general)

• Special Feature: Limit participating users? To ensure the number of people being able to read the logs is limited.
  For example with:

  • Implementation only for password-protected channels
  • Special channels with invite on consent-function

• Additional Features:

  • Offline-Messaging (requires logging to happen on the server)

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:

• Server serves only as a cache, so that users can read messages they haven't received yet.
• Both options are combined

[cap-42]

I agree, persistent chat would be a gamechanger and ever so convenient ;)

[Kamori]

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]

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]

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]

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]

That's the feature I really miss in Mumble. Any updates?

[mkrautz]

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]

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]

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]

Any progress?

[davidebeatrici]

Unfortunately not, but we will start working on this after #3465 is completed and merged.

[shumvgolove]

Thank you for reply.

[davidebeatrici]

You're welcome.

Feel free to write here any suggestions you have about the feature.

[XP-Fan]

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]

I have an idea about persistent chat that may solve the "I don't want to be tracked users"

1. The Server has a chat log that tracks chat based on a clients history setting.
2. Clients have a history setting of how long they would liked to be tracked days: "0 to All"
3. If a client has a history setting of 0 then the server does not store that users messages in the chat log, if a users has 3 then the server would save 3 days of that users messages. When a client joins their chat log would be updated from the server's chat log based on how many days they have set.
   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]

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]

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]

As a supporter of privacy I think you should consider some things:

1. Even if users choices about logging are respected (like @IIIXJokerXIII's concept), users can still guess the content of the messages of users who don't want to be tracked, by the stored messages of others.
   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.
2. Some laws might require at least the approval of users.
   The fairest option would be to ask for permission per channel.
3. Server logging is always dubious because of the problem of Plausible deniability.
4. logs can be stolen and misused, so they should be time limited and encrypted by default.

My Recommendations:
General (and for client logs):

1. the users should be informed (per server or per channel), so that they know that others are logging them
2. an option for the server conf or even per user to prevent logging
3. Very important: No auto enable, or ask in the setup wizard

For server logs:

1. per channel logging only (and only on password-protected or access-restricted channels)
2. determined groups for channels (see 3,4,5)
3. encrypted logging (no access to others, including the server admin(s)), so that only the group has access
4. no access to (older) logs for new (group) members (or 5.)
5. only access to new group members with consent of other group members
6. enable logs only if all members agree to it

Edit: Added point 3 in general

[sugoidogo]

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]

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]

@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. must ask for users permission to save/store and provide their data.
   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).
2. must ensure data protection (also on a technological level (aka encryption etc.)) by default.
3. must limit the data processing and access to a minimum (so no unlimited option).
4. must delete the data at users request.
5. must declare exactly how, why, how long etc. the data is stored and processed.

Now there might be some things open to interpretation, like:

• Are the server owners professional data controllers or processors?
  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"?
  • If the server is available to the public it might not be a private purpose.
  • If the server is run for an organisation it might also not be a private purpose.

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]

@toby63 everything what you wrote applies to audio recording too, which is already possible without consent.

[toby63]

@streaps

everything what you wrote applies to audio recording too, which is already possible without consent.

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]

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]

@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]

@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]

My law topic is not about the software (mumble), it is about the obligations of the server owners, as they will use the software.

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.

[toby63]

one would need to think about log sizes (save images or not, size of images etc.)

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)

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]

Ah ok, personally I'd still want the ability to save original quality.
However I'd start with compression before resizing

[toby63]

@Krzmbrzl Maybe we could structure this a bit?

1. Split Client side logging into a seperate issue.
2. Add some comprehensive info to the first post; see for example my draft below.
3. I added a seperate issue for offline messaging Offline Messaging #4620 .

---

Concept Factors and Ideas for Server-side logs:

• Activation & Privacy:

  • Activation/Implementation per Channel would be best
  • Server/Admin choice (mandatory),
  • Client/User choice (would be good; in some cases legally required (see below))
    • Two methods for denial to choose from:
      • Blocking method: If one disagrees, Logging is disabled for that channel (for the time the client is in it)
      • Exception method: If one disagrees, only their messages get excluded (remaining problem: Content can be guessed from other people's content)
    • Important (Law Stuff):
      • Some laws require approval for each server (so we should not implement a general accept setting; instead a pop-up for each server/channel (at least an option to activate the latter))
      • Also some laws require an option to disagree later and for already saved content to be deleted (so it would be good to have options for that)
  • Alternative to Client/User choice: Only inform the user about logging.

• Encryption:

  • Two topics:
    • Transmission encryption
    • Log Data encryption
  • Two methods:
    • server-side encryption: makes it harder for attackers/other server users etc. to read the logs
    • E2E (end-to-end): logs would only be readable for the users

• Logs (Technical details and options):

  • logs per channel
  • file format: textfile, database
  • log size limits
  • content: text, html, images, more?
  • storage time: days, weeks, months, years, unlimited
  • compression
  • auto-resizing of images (would be useful in general)

• Special Feature: Limit participating users? To ensure the number of people being able to read the logs is limited.
  For example with:

  • Implementation only for password-protected channels
  • Special channels with invite on consent-function

• Additional Features:

  • Offline-Messaging (similar to log tech) (see also Offline Messaging #4620)

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 #2560 (comment) for details.

[Krzmbrzl]

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]

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]

I think client side log should effectively be an opt-in cache of the server log.

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]

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]

@Krzmbrzl

I don't think we really need to split this issue.

In that case we should add that to the first post too.

Either client-side logging or server-side logging, or a combination of both approaches, for example:
- Server serves only as a cache, so that users can read messages they haven't received yet.
- Both options are combined

@josephsmendoza

I think E2E should be a separate issue

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]

You're taking what I said too literally.

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.

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.

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]

any updates on this?

[Krzmbrzl]

No

[phantomboy0]

still waiting for this

[Krzmbrzl]

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]

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]

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]

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]

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]

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 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?"

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]

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]

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]

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:

• Compared with voice packets on a typical server, these messages are insignificant in numbers
• They are handled in the control thread and not the voice thread in the server. Thus, they would not delay voice processing (where delays of a couple of ms can get noticeable).

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]

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.

• Christian.

[svmhdvn]

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]

I've been watching this request for almost a decade now. Is there a branch anywhere that shoehorns this functionality into mumble?

[Krzmbrzl]

I don't think so

[jr0n]

I don't think so

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]

Yeah, that'd be the way to go.