Pending Cross channels conversations

[eduardoroeder]

There should be a switch to turn off or on the cross channels conversations.

I really think it is a good idea, but this opens space for privacy issues.

Users are used to have their own chat and information exchange inside the room where the only people who can see the information is the ones connected to the room.

If other people can see and they are not unaware, this could leave space for stealing information (such as user exchanging account information via the chat to their fellow members in the same channel, while other people can read it all).

I know this probably could be "soft fixed" by adding and removing the permissions, but yet what if this behaviour should be disabled server-wide?

The same thing goes for the chat history. If a user can read the chat history after he returns, the "information" that could contain privacy problem is there.

I know it is a design for a discord-like structure of channels (like I said, I persoally like this setup), but since this is not based in discord, the users still feel they are in the same voice software they were, with the same privacy setup aswell.

Not mentioning that having the whole chat history inside the server files is also another privacy point, but this is not the main question. It could be explored as a bad-faith server admin that could read all their users information exchanged via the chat, if he got his hands into the conversation files.

 

[WolverinDEV]

Hey,
thanks for sharing your thoughts.

Yes, I agree: Users are used to have their channel chats volatile, but by using the TeaClient you'll quickly notice how the chat system works.
So if the user was unaware, he wouldn't be for long. (Using any other clients is unsupported and so it will not be thought through!)

Each channel itself has a property for how long, and even if, messages are saved, but this setting isn't yet editable via the TeaClient/Web UI.
Even thou via a channeledit command this property can be changed such as the channel gets private which implies not saving messages and being able to read them only when you're a member of the channel.

A server wide setting isn't intended since such private channels are intended to be the edge case instead the regular.

As you, if you took a look, noticed, the conversation files are "encrypted" and not human readable.
Breaking the encryption/decryption take as much as much effort as patching the server itself and directly reading the messages.[/icode]

 

[eduardoroeder]

Yes, I agree: Users are used to have their channel chats volatile, but by using the TeaClient you'll quickly notice how the chat system works.
So if the user was unaware, he wouldn't be for long. (Using any other clients is unsupported and so it will not be thought through!)

Well, actually I noticed this after using TeaClient. Personally I entered a channel of one of those 1k TS and there was relevant information that I could just get but wasn't avaiable to the TS3 clients.

Like we already discussed about, your software is designed around another one. You even compare them in the home page. We can't deny that the compatibilities are the key to the long-run success, even if you plan to give up the compatibilities later on. Almost all of the settings included in TeaServers are directly related to TS3 clients, and the TeaClient is designed to be better (or different?) than TS3 and even then connect to TS3 servers. So you can't really give support to other clients, but I know you do take in consideration the counterpart of what happens in TS3 clients when you change something in TeaServers.

I'm pretty sure you have some statistics around the clients connected, and I'm sure that the great majorty are TS3 clients (can you share with us? it would be nice to have a progression graph of how many users are migrating to TeaClient and such).

If you focus on giving support to working things only for TeaClients and breaking stuff to TS3, you know where the userbase would go, right? I know that I didn't need to say this because you are doing and amazing job at pushing those compatibilities together, but "Using any other clients is unsupported and so it will not be thought through" isn't really a way to resolve a multi-client scenario.

That said, people are used to how TS3 chat works. That's how the voice system works, and the beauty of the whole TS protocol. Only the people inside can hear/talk/chat. That's it. No cross information, no crosschat except from PM and Whisper.

Implementing changes to it may need users to adapt to it. That's how software evolves, and like I said: this is a nice feature, I do like it. If I had a plain TeaServer with only TeaClients, I'd leave it activated.

But since you are kind of "reinventing the wheel" (just like using the same protocol and implementing changes around it), people are used to one way and then can't be forced to use other way. IDK if I could make it undestandable, in my head it made more sense hahahaha

Each channel itself has a property for how long, and even if, messages are saved, but this setting isn't yet editable via the TeaClient/Web UI.
Even thou via a channeledit command this property can be changed such as the channel gets private which implies not saving messages and being able to read them only when you're a member of the channel.

Is it a permission? Or a property? I'll take a look.

A server wide setting isn't intended since such private channels are intended to be the edge case instead the regular.

Well, that should be right in a point. It is the edge case, but like I said. Probably the majorty of TeaServer connected clients are TS3 users, which are used to TS3 chatting system. So if all the TS3 users changed to TeaClients, that would be a regular use aswell. But no problem.

Just like you have the IP global-switch, where it doens't save IP globally (implying IP privacy reasons), there should be a no-chat-history aswell, since it all comes to privacy again. TeaServers doesn't have any EULA that allows we as server hosters to store any chat typed in by the users. The users also doesn't have any option to opt out from this. So, it should be a option aswell.

As you, if you took a look, noticed, the conversation files are "encrypted" and not human readable.
Breaking the encryption/decryption take as much as much effort as patching the server itself and directly reading the messages.[/icode]

Yea, I've tryied to open it and it is kind of encrypted. Didn't try much into it, but it should be as simple as copying the server folder and opening it and joining the server to read. Believe me, there is always people that does that.

 

[WolverinDEV]

> Well, actually I noticed this after using TeaClient
Yeah, that's how it's intended

> Like we already discussed about, your software is designed around another one
Well yes and no, TeaSpeak started with a similar concept than some other software, but has developed it's own style and goals.
The goal isn't, to replicate anything already existing.

> If you focus on giving support to working things only for TeaClients and breaking stuff to TS3
I'm actually focusing on TeaClient/WebClient only supported features. I've no priority the implement such to non TeaSpeak software.
The only thing I'm currently doing is still having the early implemented features untouched, which implies no changes, so no bricking of any older client versions.

> you know where the userbase would go, right
No I don't since I'm only counting as user base, members which using the TeaClient/WebClient.
Yes, the statistics on my landing page may drop, but that's no harm at all.
The lovely thing of a free time project is the non commercial aspect. You're not bound to anything.
Well, except the boundaries you're setting your self, like creating a VoIP solution which fits modern needs and is actually responsive to their community.

> just like using the same protocol and implementing changes around it
HAHA No. The end user does not have any exceptions just because a certain application uses a certain protocol (which the user may not even know).
There are a lot protocol specifications out there, which are wildly used in many different applications, such as what I'm using.

> Is it a permission? Or a property? I'll take a look.
It's a property.

> Just like you have the IP global-switch [..] there should be a no-chat-history aswell
Well that's actually a good point. And you got me thinking about to, as the IP switch, hide/remove the user name from the logging.
If done so, the chats are anonymized which should, I'm not a lawyer, fit the gdpr again.

> Yea, I've tryied to open it and it is kind of encrypted.
Well if you're having access to the server in the first place, and you're able to copy the files, you probably also can change the log level to trace and read thru the chats there


So over all, I think the privacy thing is something to consider, but I'm still against a global disable switch:
We only support TeaSpeak, and no other software.
Since the new chat system is intuitive, it needs no extra introduction to users which may have a different expectation by being used to any other software. Using our software with any other third party software is unwanted, unsupported and may even violates the TOS of such third party software. So considerations about such scenario not to be considered.