Forum


Notice to all users

We are migrating towards a new forum system located at community.teamspeak.com, as such this forum will become read-only on January 29, 2020

Results 1 to 14 of 14
  1. #1
    Join Date
    February 2012
    Location
    Germany
    Posts
    577

    Future design proposals

    I complained a lot about Teamspeak falling behind modern voip solutions, so I have a few proposals what can be done. I don't know how similar that design is to Discord (I don't regularly visit that app and didn't analyze it too deeply), but I assume in general similar apps converge to similar designs these days.

    This is a somewhat users/admin/client side point of view.

    1. Connect
    1.1. The user starts the voip client by either clicking a link in a web site or starting a standalone client
    1.2. If there are connection details provided with the link, the user connects to the given server/channel.
    1.3. On the absence of connection details, the user connects to the last server/channel he was connected.
    1.4. If there are neither connection details provided nor a last known server, the client starts with an empty tree in its UI. Or to the Teamspeak public server if you like.

    2. Credentials
    2.1. as long as the user didn't define any credentials, the client uses an anonymous guest identity that is identical on every server.
    2.2. the user can connect his client to identities from Google, Facebook, Microsoft whatever social media that supports identity linking. If he doesn't want to, he can generate an identity on MyTeamspeak. For closed communities, an identity server is provided as sub-service on one Teamspeak server. Keys are not stored locally on any client, username+password+2 factor auth is used to authenticate. In the Teamspeak server database, tokens from the identity providers are stored, never passwords and never password hashes.
    2.3 The client connects to a server with the credentials he used the last time for this server
    2.4. If the client didn't connect to a server before, he tries to connect with the credential he set as primary
    2.5. If the server requires some identity the client did not yet provide, the user is prompted to provide it

    3. Client UI
    3.1. The client's main window contains a tree, whose top level entries are all servers the client did connect to in the past. This replaces any bookmark or connect menu. Instead of a direct connect menu, there is a '+' button to add a new server entry to the UI.
    3.2. The 2nd level (and down) hierarchy is the client channel tree of the corresponding server.
    3.3. If the client is connected to a server, a live channel tree view of that server is displayed. If the client is not connected to a server, a cached view is displayed.
    3.3. A client can jump from server to server by just clicking on a live or cached display of a channel on a different server. It looks like as if all servers with all their channels are always available to him. He doesn't 'connect' to or 'disconnect' from a server - he starts the app and is in the last channel he was when he closed the app. Or some default channel he defines if he wants to. Then he just changes channels without seeing that he is in fact changing servers.
    3.4. A new server has one default channel. Every additional channel on a server is created as sub channel from the default channel. In the UI tree, the server entry itself is the default channel.

    4. Permissions
    4.1. The permissions are role-based, configured with acl (access control lists)
    4.2. Every item for that access has to be managed, has a 'create', 'read', 'change', 'delete' and 'manage' permission. Depending on the type of item, additional permissions may be necessary. For example a channel has an additional permission called 'join'. A permission is either 'allow' or 'deny'. In absence of any permission, access to that item is denied. Permissions can be inherited from higher level items.
    4.3. Permissions can be assigned to groups. For example, to be able to connect to a server, you need a 'login' permission to the server and the 'read' and 'join' permission to the default channel. This group may be called 'login'. There may be many groups, for example each channel may have a group that regulates access to it.
    4.4. Groups may be nested. This way, access to resources can be collected and accumulated to a higher level. A group 'moderator' may contain all groups that define moderator access to several channels.
    4.5. Users may be assigned to groups. A user that is assigned to the group 'moderator' is able to perform moderator duties according to the permissions in that group and nested groups.

    5. Policies
    5.1. Policies are rules that are assigned to channels and take effect to this channel only or this and all sub channels. Each policy contains a condition and an action.
    5.2. Policies may contain settings to enforce in this channel. Examples: format of user nicknames, duration of inactivity, etc.
    5.3. If the condition part of a policy matches, the action is executed. For example: if condition 'inactivity time > 30 min' matches, action 'move to hannel "afk"' is executed.

    6. Chat
    6.1. The client UI is divided horizontally or vertically and one displays the server+channel tree and the other the chat of the currently joined channel.
    6.2. Channel chat is saved in the server database and can be scrolled back, so users can read what was written while the user was not in that channel (scrollback may be controlled by permissions)
    6.3. chat is rich text with user icons, emotes and embeddeable images, chat message tree indented in Whatsapp/sms app style

    7. Whiteboard and desktop sharing
    7.1. Users may share their desktop or single desktop apps, and everyone in a channel may connect to and see what is shared.
    7.2. an alternative/additional source for desktop sharing is a whiteboard with simple text writing and drawing facilities. Everyone can write and draw who the initiator of the session gave permission to.


    Have fun.

  2. #2
    Join Date
    January 2010
    Location
    Secret Base in Arctic Region
    Posts
    1,671
    (Meister Dante, feel free to edit or delete this post )

    @Schlumpi:
    Rejected, we wont add/do this.
    Were too conservative and fear change.

    No, some of your suggestions are sounding good and could be realised in TS 4.
    Me wouldnt need the Policies thing and your permissions could be complex to (like the current system).
    Simplify them.

    Whats the opinion of others, esp. Bluescream and Numma_Cway?

  3. #3
    Join Date
    August 2013
    Location
    Germany
    Posts
    541
    Well, tbh the 'classic' TS UI makes me feel like i'm using a PC tool and not like i'd play a mobile game. So i'm okay with some exceptions:

    6.1 Can be done with https://github.com/svenpaulsen/ts3cl...lugin/releases
    6.3 Can be partially done with https://github.com/Luch00/LxBTSC/releases

    7. Can be done with https://mfreiholz.de/ts3video/ and https://manycam.com/ for example.

  4. #4
    Join Date
    December 2015
    Posts
    273
    Relying purely on addons for such things is never a good idea.

    I mean.. these addons you mentioned aren't even on the official TS3 Addon store. So how should a normal user find them ever? And how long will they get maintained?

    I used firefox for several years. And with every major Firefox release I needed to find some new addon-clones, because the ones I was using for certain tasks (open Tab always to the right from the active one, etc) were no longer compatible and got abandoned by the developers.

    Some basic UI customization is always a good core feature (at least 2-3 Layouts to choose from, especially when the current layout needs an overdue.)

  5. #5
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,368
    Why aren't they on myTeamSpeak?

    Quote Originally Posted by Dimos View Post
    I used firefox for several years. And with every major Firefox release I needed to find some new addon-clones, because the ones I was using for certain tasks (open Tab always to the right from the active one, etc) were no longer compatible and got abandoned by the developers.
    Or disable version checking. There have no noteworthy changes from Firefox 0.x to 56, so I set the max version for all of my addons to 1337. 57 however did change addons by removing addons.

  6. #6
    Join Date
    December 2015
    Posts
    273
    Quote Originally Posted by numma_cway View Post
    Why aren't they on myTeamSpeak?
    The Author said in a thread to me that he can keep better track of it via Github (issues, feature request, pull request, etc) + the TS3 store policy of pulling updated addosn for as long as the update review takes is just plain bad.

    Dante even said some time ago that they are looking into "changing" that. That was a few months ago.
    Must be incredible hard. I mean its rocket science after all.

    Quote Originally Posted by numma_cway View Post
    Or disable version checking. There have no noteworthy changes from Firefox 0.x to 56, so I set the max version for all of my addons to 1337. 57 however did change addons – by removing addons.
    So you can just ignore the API version in the TS3 addons? Didn't knew that. Thanks.

  7. #7
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,368
    I just said that your comparison is bad. TeamSpeak does care about the API version, because the plugin interface is not a script language.

    But I agree with you in terms of the first part of your message.

  8. #8
    Join Date
    December 2015
    Posts
    273
    Quote Originally Posted by numma_cway View Post
    I just said that your comparison is bad. TeamSpeak does care about the API version, because the plugin interface is not a script language.
    And that's why I said its a bad idea to give the responsibility of a good layout(or other core feature improvements that everyone agrees on are a good idea) into the hands of some random plugin/addon developers. Where you don't know if it will work after the next update or not.

  9. #9
    Join Date
    November 2017
    Posts
    181
    Quote Originally Posted by Schlumpi View Post
    1.1. The user starts the voip client by either clicking a link in a web site or starting a standalone client
    1.2. If there are connection details provided with the link, the user connects to the given server/channel.
    This is already the case, isn't it?
    Quote Originally Posted by Schlumpi View Post
    1.3. On the absence of connection details, the user connects to the last server/channel he was connected.
    1.4. If there are neither connection details provided nor a last known server, the client starts with an empty tree in its UI. Or to the Teamspeak public server if you like.
    This "last server" thing should be an option which may or may not be the default since I'm sure there will be situations where I don't want to be thrown onto whichever server I used last when I start TeamSpeak.

    The "TeamSpeak public server" suggestion sounds like one of those "make it easier to get started" suggestions and just throwing someone onto a public server with who knows how many weird people around them may not be the best option to achieve that.

    Quote Originally Posted by Schlumpi View Post
    2.1. as long as the user didn't define any credentials, the client uses an anonymous guest identity that is identical on every server.
    With the current system, this would imply that banning that identity bans every "anonymous" user from the server. From a server owner's point of view, I don't want different users to share the same identity as it comes with security implications. I can no longer tell people apart and if I happen to grant server admin privileges to such identity, I grant server admin to everyone.

    Quote Originally Posted by Schlumpi View Post
    2.2. the user can connect his client to identities from Google, Facebook, Microsoft whatever social media that supports identity linking. If he doesn't want to, he can generate an identity on MyTeamspeak. For closed communities, an identity server is provided as sub-service on one Teamspeak server. Keys are not stored locally on any client, username+password+2 factor auth is used to authenticate. In the Teamspeak server database, tokens from the identity providers are stored, never passwords and never password hashes.
    2.3 The client connects to a server with the credentials he used the last time for this server
    2.4. If the client didn't connect to a server before, he tries to connect with the credential he set as primary
    2.5. If the server requires some identity the client did not yet provide, the user is prompted to provide it
    I'm all for the idea of being able to connect other platform accounts as it opens up opportunities for working with such platform's APIs.

    I'm not sure about using these providers for authentication directly with the TeamSpeak server though. Currently (if I'm not mistaken), the "identities" and the "myTeamSpeak" account are two differents things which are not directly connected. Sure, you can sync your identities with "myTeamSpeak" but the server only gets to see the identity. The "myTeamSpeak" login is more or less a client-side feature.

    This also seems to imply that you cannot change your identity anymore unless you link a different account. I'm currently using at least three different identities, a main one with full administrative privileges on my server, a mobile one with limited administrative privileges in case I loose my mobile device and an anonymous one I use to connect to "untrusted" servers until I'm certain I want to "expose" my main identity.

    Quote Originally Posted by Schlumpi View Post
    3.1. The client's main window contains a tree, whose top level entries are all servers the client did connect to in the past. This replaces any bookmark or connect menu. Instead of a direct connect menu, there is a '+' button to add a new server entry to the UI.
    3.2. The 2nd level (and down) hierarchy is the client channel tree of the corresponding server.
    3.3. If the client is connected to a server, a live channel tree view of that server is displayed. If the client is not connected to a server, a cached view is displayed.
    3.3. A client can jump from server to server by just clicking on a live or cached display of a channel on a different server. It looks like as if all servers with all their channels are always available to him. He doesn't 'connect' to or 'disconnect' from a server - he starts the app and is in the last channel he was when he closed the app. Or some default channel he defines if he wants to. Then he just changes channels without seeing that he is in fact changing servers.
    3.4. A new server has one default channel. Every additional channel on a server is created as sub channel from the default channel. In the UI tree, the server entry itself is the default channel.
    This imposes a LOT of changes to the current system and is similar to what Discord uses. However, discord has separate "text" and "voice" channels and you can only be connected to one "voice" channel at a time. In TeamSpeak, you can be connected to many voice channels while one is the active one you are speaking to.

    I think your concept won't work with TeamSpeak's multi-tab feature.

    Quote Originally Posted by Schlumpi View Post
    4. Permissions
    5. Policies
    For the love of whatever higher power you may believe in: let's not introduce another flavor of an over-complicated permissions system.

    The problem with TeamSpeak's permissions system has always been that they wanted it to be "powerful" which lead to a complexity which average users and even long-time users of TeamSpeak just don't understand.

    Discord uses a simple role-based concept with a bit of inheritence and that's it, no complicated "grant", "negate", "skip" and "group membership" fancyness. For most use cases, this is absolutely sufficient and it's amazingly easy to setup.

    TeamSpeak's permissions system is so complicated that they had to create a whole sub-forum just for helping people to set it up.

    Maybe it would make more sense to introduce a simple role based system as an alternative to the "advanced" system we currently have rather than hiding the complexety behind a "simple" frontend. Let server administrators choose to go with either the role-based system or the advanced one with a one-way option to "upgrade" to advanced after explaining the implications.

    TeamSpeak appears to lack someone with a bit of background in building user friendly software. If they had someone like that, maybe that person would come up with a system that is "powerful" and easy to use.

    Quote Originally Posted by Schlumpi View Post
    6.1. The client UI is divided horizontally or vertically and one displays the server+channel tree and the other the chat of the currently joined channel.
    6.2. Channel chat is saved in the server database and can be scrolled back, so users can read what was written while the user was not in that channel (scrollback may be controlled by permissions)
    6.3. chat is rich text with user icons, emotes and embeddeable images, chat message tree indented in Whatsapp/sms app style
    Yes, that's another case of TeamSpeak being "old-fashioned", I guess.

    However, what is going to happen with the channel description? I heavily rely on channel descriptions as they are pretty much the only way (apart from "hoster" features) to customize my server's look and feel.

    So when you strip down the design to basically just two columns, I'd at least want a way to kinda "expand" the channel description as a third column or whichever design concept the devs may come up with as long as I don't have to give them up completely.

    Quote Originally Posted by Schlumpi View Post
    7.1. Users may share their desktop or single desktop apps, and everyone in a channel may connect to and see what is shared.
    7.2. an alternative/additional source for desktop sharing is a whiteboard with simple text writing and drawing facilities. Everyone can write and draw who the initiator of the session gave permission to.
    I think there are existing solutions our there which are way better suited for that purpose. I'm not even sure TeamSpeak has the "know-how" to get started with video stuff. It's a whole different thing.

    Also, this sounds more like a "business" feature and TeamSpeak is still primarily designed for Gamers. Maybe one could use the plugin framework to integrate an existing solution instead.

  10. #10
    Join Date
    February 2012
    Location
    Germany
    Posts
    577
    Don't ask yourself how Teamspeak has to change its app to fit my proposal, ask yourself how you would design a modern voip chat system from scratch instead.

    A lot of changes to the current system? Certainly. It's completely different from the ground up.

    I disagree to your feel my proposal contains a complicated permission system. It's essentially the same as the Windows/Active Directory permission system. I work in an enterprise with about 100.000 employees that has Active Directory domains with tenthousands of clients and thousands of servers. I work in customer networks that have an equal size or even bigger. I tell you: this permission system scales from 1 machine to 1 million machines and is definitely not over-complicated and allows distributed and delegated administration. In fact, the only thing that is really different to the current Teamspeak permission system is that it uses hierarchies of group memberships instead of user levels (or how it is called by Teamspeak: power levels).

    The policies part addresses what is mainly accomplished by bots and background jobs these days and what is partly configured as static attributes of a channel or a server.

  11. #11
    Join Date
    November 2017
    Posts
    181
    Okay, so we are talking about TeamSpeak 4 here. That was not obvious from reading your original post.

    Also, copying a system which was designed for "tenthousands of clients and thousands of servers" doesn't automatically mean that it's the best option for a software where "tenthousands of clients and thousands of servers" is a very rare and rather unrealistic use case.

    As someone who works in an enterprise with about 100.000 employees, you certainly heard of the KISS principle. I bet most people who administrate TeamSpeak servers are actually gamers and not full-time active directory administrators who have no interest in "digging into the details of configuring a powerful permission system".

    You might not be beware that many TeamSpeak users still prefer channel passwords over setting up the permission system, simply because it's much faster and easier to setup.

    The point is that the average TeamSpeak user does not WANT to deal with permissions. They just want to talk to their friends without being interrupted by weird strangers. That's all.

  12. #12
    Join Date
    February 2012
    Location
    Germany
    Posts
    577
    You own a PC, don't you? Or a smartphone? Of course, otherwise you wouldn't be able to write your post. Then you already have it, that permission system. It's already there. You already dealing with it. In this very second. Windows PC, iOS, or Android/Linux - it's already present, working and in force on all these devices. Billions of people own these devices and I don't read too much complaints about it that people aren't able to use their devices properly.

  13. #13
    Join Date
    November 2017
    Posts
    181
    I still remember the simple attempt of sharing a file over a Windows based private network usually ending in having to create a shared folder with write permissions for "everyone" while ensuring that every device is in the same "work group" while user name and password are exactly the same on each device in order for it to have a maybe 20% chance to actually work.

    I also remember requiring root access on Android devices in order to be able to perform a "simple" task such as doing a complete backup of my phone.

    I also remember NTFS permissions not doing what they were supposed to do when moving disks between systems.

    I also remember people recommending to run TeamSpeak as administrator because their keybindings wouldn't work which also looks a little "broken" to me.

    All in all, I remember tons of things not working the way I as a user would expect them to work. Also: do iOS, Linux and Android incorporate a Windows/Active Directory like permission system by default? That's news to me.

    It looks to me like you are merely trying to defend to the death a system that you believe to be "the only option" while denying even the possibility that it might actually NOT be "the best" for everyone and every situation.

  14. #14
    Join Date
    February 2012
    Location
    Germany
    Posts
    577
    I am in the comfortable position that I don't have to defend anything and that I don't have to deliver anything here. I'm just a simple forum user. I just proposed some voip software design tidbits to Teamspeak to help them consider how to modernize their software, since they apparently did not employ any core software design since at least 8 years.

    Between you and me: I don't expect Teamspeak read or consider anything of this. I expect Teamspeak milk their cash cow as long as they can by delivering their software in its current state for the next 5, perhaps even 10 years, and as soon as maintaining the software becomes more expensive than the income, the owners will retire.

    It's perfectly valid that they do this. It's their right to do this. It's only that I as a server provider for my community have to have this in mind and have to plan a more modern voip platform in the near or medium future. Otherwise we would not be able to recruit young people any more as members who refuse to install that old-fashioned software. That's the only task I promised to deliver: a state of the art voip platform for my community.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Future of TeamSpeak
    By Dimos in forum Suggestions and Feedback
    Replies: 151
    Last Post: April 23rd, 2019, 12:54 PM
  2. Paid Channel Design and TS3 Design
    By baetzor in forum Off Topic
    Replies: 0
    Last Post: July 6th, 2016, 08:58 AM
  3. Future of TeamSpeak3
    By Kubuxu in forum Off Topic
    Replies: 2
    Last Post: June 30th, 2014, 01:19 PM
  4. TS3 Future Updates
    By SightUp in forum Suggestions and Feedback
    Replies: 26
    Last Post: December 16th, 2009, 07:52 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •