TeamSpeak5 Beta is started

[YoshiFANGamer66]

Nice

 

[k-scripts]

Screen's of ts5

 

[fyfywka]

It's not TeamSpeak 5, it's TeamSpeak Client UI V2

 

[Leave2Andromeda]

haha nice

 

[YoshiFANGamer66]

message removed

 

[Clansen]

does someone still have an ts5 acces code and if so can i get one

Have the same question

 

[Meros91]

Have the same question

Have the same question too.
I'm really interested.

 

[Asphyxia]

it's TeamSpeak Client UI V2

That is funnier than hell.. they left their C:\GitLab-Runner information in there.

So we know a few things about TeamSpeak's development process and their technologies.

1. They use GitLab for development, a recent build was 98u6b36D and.. accounts of interest https://gitlab.com/xforce - also has an account over at https://github.com/xforce
2. "deps\protobuf\protobuf" You what m8? You need protobuf for protobuf to work, oh kk. Very much wow!
3. The actual name should be TeamSpeak 3 ClientUI V2, but illuminati is at work so V2+3 = 5, this means TeamSpeak 5 is the illuminati.

I guess they are going away from Qt which is a good idea, but they are likely swapping all their dependencies elsewhere clearly. Btw, if anyone wants to know what protobuf is go here. By the way, Mumble already has been doing this (since 2012) - https://github.com/mumble-voip/mumble/blob/master/src/tests/ProtoBuf.pro 'n' check https://github.com/mumble-voip/mumble/issues/3617 .. cool info over here https://forum.teamspeak.com/threads/128946-Will-there-be-an-API-for-myTeamspeak?p=443861#post443861

Btw, why use protobuf? Some girl named Sasha Rezvina gave some good intel sometime ago, check https://codeclimate.com/blog/choose-protocol-buffers/ because the below is from there!

Reason #1: Schemas Are Awesome
There is a certain painful irony to the fact that we carefully craft our data models inside our databases, maintain layers of code to keep these data models in check, and then allow all of that forethought to fly out the window when we want to send that data over the wire to another service. All too often we rely on inconsistent code at the boundaries between our systems that don’t enforce the structural components of our data that are so important. Encoding the semantics of your business objects once, in proto format, is enough to help ensure that the signal doesn’t get lost between applications, and that the boundaries you create enforce your business rules.

Reason #2: Backward Compatibility For Free
Numbered fields in proto definitions obviate the need for version checks which is one of the explicitly stated motivations for the design and implementation of Protocol Buffers. As the developer documentation states, the protocol was designed in part to avoid “ugly code” like this for checking protocol versions:

if (version == 3) {
...
} else if (version > 4) {
if (version == 5) {
...
}
...
}
With numbered fields, you never have to change the behavior of code going forward to maintain backward compatibility with older versions. As the documentation states, once Protocol Buffers were introduced:

“New fields could be easily introduced, and intermediate servers that didn’t need to inspect the data could simply parse it and pass through the data without needing to know about all the fields.”
Having deployed multiple JSON services that have suffered from problems relating to evolving schemas and backward compatibility, I am now a big believer in how numbered fields can prevent errors and make rolling out new features and services simpler.

Reason #3: Less Boilerplate Code
In addition to explicit version checks and the lack of backward compatibility, JSON endpoints in HTTP based services typically rely on hand-written ad-hoc boilerplate code to handle the encoding and decoding of Ruby objects to and from JSON. Parser and Presenter classes often contain hidden business logic and expose the fragile nature of hand parsing each new data type when a stub class as generated by Protocol Buffers (that you generally never have to touch) can provide much of the same functionality without all of the headaches. As your schema evolves so too will your proto generated classes (once you regenerate them, admittedly), leaving more room for you to focus on the challenges of keeping your application going and building your product.

Reason #4: Validations and Extensibility
The required, optional, and repeated keywords in Protocol Buffers definitions are extremely powerful. They allow you to encode, at the schema level, the shape of your data structure, and the implementation details of how classes work in each language are handled for you. The Ruby protocol_buffers library will raise exceptions, for example, if you try to encode an object instance which does not have the required fields filled in. You can also always change a field from being required to being optional or vice-versa by simply rolling to a new numbered field for that value. Having this kind of flexibility encoded into the semantics of the serialization format is incredibly powerful.

Since you can also embed proto definitions inside others, you can also have generic Request and Response structures which allow for the transport of other data structures over the wire, creating an opportunity for truly flexible and safe data transfer between services. Database systems like Riak use protocol buffers to great effect – I recommend checking out their interface for some inspiration.

Reason #5: Easy Language Interoperability
Because Protocol Buffers are implemented in a variety of languages, they make interoperability between polyglot applications in your architecture that much simpler. If you’re introducing a new service with one in Java or Go, or even communicating with a backend written in Node, or Clojure, or Scala, you simply have to hand the proto file to the code generator written in the target language and you have some nice guarantees about the safety and interoperability between those architectures. The finer points of platform specific data types should be handled for you in the target language implementation, and you can get back to focusing on the hard parts of your problem instead of matching up fields and data types in your ad hoc JSON encoding and decoding schemes.

When Is JSON A Better Fit?
There do remain times when JSON is a better fit than something like Protocol Buffers, including situations where:

You need or want data to be human readable
Data from the service is directly consumed by a web browser
Your server side application is written in JavaScript
You aren’t prepared to tie the data model to a schema
You don’t have the bandwidth to add another tool to your arsenal
The operational burden of running a different kind of network service is too great
And probably lots more. In the end, as always, it’s very important to keep tradeoffs in mind and blindly choosing one technology over another won’t get you anywhere.

Conclusion
Protocol Buffers offer several compelling advantages over JSON for sending data over the wire between internal services. While not a wholesale replacement for JSON, especially for services which are directly consumed by a web browser, Protocol Buffers offers very real advantages not only in the ways outlined above, but also typically in terms of speed of encoding and decoding, size of the data on the wire, and more.

What are some services you could extract from your monolithic application now? Would you choose JSON or Protocol Buffers if you had to do it today? We’d love to hear more about your experiences with either protocol in the comments below – let’s get discussing!

tl;dr TeamSpeak 5 is feels like a final attempt at making TeamSpeak relevant again. Unfortunately, in an age where TeamSpeak is still privately owned and not publicly traded, this kills potential significantly. TeamSpeak has a set allowance and that is where everything stops, right at their line of allowed spending. Between the relatively small TeamSpeak team, maybe they have a couple million dollars. I cannot imagine TeamSpeak holding even $10,000,000 in capital though. Notice I said capital. With the capital funding shortage from equity holders (owners), and a lack of investors.. TeamSpeak is limited to having a few developers with potentially amateur skillsets. I mean no offense to sir "Xforce" from GitLab. I only mean his commits are not nearly extensive enough to deliver on such a project as TeamSpeak. This is more than likely how and why we received word "TeamSpeak 5 is coming soon" and the project took closer to a year for our eyes. Overpromising is a large problem and I can understand there are obstacles and some are unforeseen. But then be honest and update everyone, the release may take longer than we planned - WE ARE SORRY and THANK YOU for patience. They did not do that though, they released puzzle pieces and kept everyone on the edge of their seat.

I like TeamSpeak 5 in the sense they are trying, I am admittedly nervous this is a temporarily hyped project. Without further development and more unique features to increase sales, I am unsure this will win the gamer market over that they appear to be targeting.

 

[fyfywka]

the server I created earlier in teamspeak 5 offline, server host i3d.net

 

[FromLondon]

Do someone know is the postgresql was supported db before ?

Added support for upcoming TeamSpeak Server releases using a PostgreSQL database backend.

 

[xforce]

I mean no offense to sir "Xforce" from GitLab. I only mean his commits are not nearly extensive enough to deliver on such a project as TeamSpeak.

How did you come to that conclusion, I have basically never used my gitlab.com account for anything really and none of the teamspeak stuff happens on gitlab.com?
Since you actually managed to make a connection of my accounts to TeamSpeak(It says right on my profile so that should have been an easy one)...let me help you with giving some actual stuff I did specifically for TeamSpeak that is actually open source... https://github.com/xforce/cef/commits/3865-notifications this is the branch of cef that we use in the current teamspeak 5 client

If you had spend at least a few minutes browsing my GitHub profile you would have seen that I mainly do some small fun things that are never really meant to go anywhere (mostly just experimenting) and Game modding. Often I do not have the time or energy to spend on open source stuff, would love to do more...

Besides, I have been involved in the Chromium Embedded Framework project for quite a while now...here some more info on that:
I do regular work on the official CEF project (bug fixes, new features and chromium updates)...just search the history over there https://bitbucket.org/chromiumembedded/cef/src/master/
An example of the recent larger works I did for CEF (unrelated to TeamSpeak) https://bitbucket.org/chromiumembedded/cef/commits/ac2cc54e13ff1838c4484a4279ae73462a2caadf

Maybe you can do some actual research next time before posting some baseless statements that have no real connection to anything related to this topic...(a hint: if you dig a bit you will find that I have done some bug fixes in the official chromium project!)

 

[Asphyxia]

Maybe you can do some actual

Lol sorry I didn’t fbi background check you. I noticed some commits here and there and was just like wtf. Next time I’ll spend half my day checking everything everywhere

 

[xforce]

Lol sorry I didn’t fbi background check you. I noticed some commits here and there and was just like wtf. Next time I’ll spend half my day checking everything everywhere

If you post statements like "I only mean his commits are not nearly extensive enough to deliver on such a project as TeamSpeak", I would at least expect you to actually look at what is on the profiles...sounds to me like you actually didn't really do that.

 

[Asphyxia]

sounds to me like you actually didn't really do that.

Oh I did, I just didn’t see anything of quantity and quality. I mean you have some quality commits don’t get me wrong, I was just thinking for such a large project it would make sense the “coming soon” being a year with the code quantity lacking.
Maybe you can inform me why you think the beta was so delayed??

 

[xforce]

Oh I did, I just didn’t see anything of quantity and quality. I mean you have some quality commits don’t get me wrong, I was just thinking for such a large project it would make sense the “coming soon” being a year with the code quantity lacking.
Maybe you can inform me why you think the beta was so delayed??

The main point here is that we at TeamSpeak work on a self-hosted Gitlab instance, so you will never be able to correlate any amount of work being on a public site to the actual work being done on the client.
I use the GitHub account only for private and personal projects, the cef project is the only exception to that but that is only because we do not plan to have notification support in the official CEF project (, so I maintain that fork for use at TeamSpeak with notification support.

Really can't get into details on why it was delayed...

 

[Asphyxia]

we at TeamSpeak work on a self-hosted Gitlab instance

I realize the need for self-hosted repos on a project such as TeamSpeak. Look man, I am thankful for all your work and everything TeamSpeak does. I am just highlighting the core differences between TeamSpeak as a private company and Discord as a highly invested company. TeamSpeak simply has less capital funding and the developer teams at TeamSpeak are likely to be:
1. Smaller
2. Less credentials (higher credentials equals higher developer cost, typically.. and developers can expect to make $100,000 each)
3. Less experienced.. for example employees at TeamSpeak (not just developers) have questionable amounts of experience.
4. In the past, code security and overall protocol security has shown to be weak. I am very curious how this evolves moving forward?!

When the f*** is TeamSpeak hiring a director of information security or director of devsecops-related role btw? last question.. and no I would never want to work there.

 

[dosh]

I don't know why you guys keep talking sh** on teamspeak, it was the first actual good software for years this forum won't even exist if it wasn't for teamspeak3. Yes the license system is sh** but still people use it and will keep using it there is no denying that, discord is better for sure in many ways but for me I don't use it daily can't get used to it.

Also the ammout of dark sh** going to discord PM/servers is amazing really soon there will be restrictions on the servers or something, servers dedicated to ddos and other illegal things that are advertised publicly will not last long Discord will receive some notice about this soon.

 

[Asphyxia]

soon there will be restrictions on the servers or something, servers dedicated to ddos and other illegal things that are advertised publicly will not last long Discord will receive some notice about this soon.

This is how anything hosted is required to be. If you are hosting a terrorist or otherwise illegal voice chat server, your sh** is going to get shutdown sooner or later whether by legal force (with investigation, fines, and legal processes).. long story short, Discord has to have rules to keep themselves protected from user's illegal activity. We have rules here too, post a credit card or social security number and get immediately banned!

TeamSpeak is making a stronger transition toward enforcing myTeamSpeak use, which is a cloud-based account system. One of the sole reasons I have ever enjoyed using TeamSpeak is the privacy and lack of a cloud-based centralized authorization system. Now, TeamSpeak apparently is requiring users to login.

They (TeamSpeak) offer two "privacy" type of profiles but as with most providers of any cloud-related system, they default your selection AWAY from "limited data collection, private".. to a more advanced data collection profile.

This means your email address can be traced to where you connect. Overall the heavy enforcement of myTeamSpeak oncoming is the beginning of a less private TeamSpeak user experience. You can think I am just aimlessly hating on TeamSpeak or that I aimlessly hated on Discord. Many people think I am fu**ing psycho, but hey. I launched this website when Dante696 told me to f*** off about a security concern.

We are still here, funny that right? A bad customer support experience from TeamSpeak caused this website..

check 'em here https://forum.teamspeak.com/threads...e-Crash-Freeze?p=376413&highlight=#post376413

 

[dosh]

Not that it matters but in my oppinion if teamspeak dies this forum will go down soon too.
The only time that there is activity here is when teamspeak does something.
And you won't have the same if this gets based off discord besides I bet discord will be sold soon by a stupid ammount of money to a company that will eventually kill it/launch stupid changes.

In my oppinion if teamspeak still has this license system its because they don't see the need to change it/make it free yet.
By the way there are exploits for discord for 1 month already and it was not patched where you can crash users...

 

[Asphyxia]

you can crash users...

That is a Unicode issue I believe which impacts plentiful Windows software. It crashes modern browser software or freezes it also.

I know some people are religious about TeamSpeak as I was. I also realize our primary userbase consists of TeamSpeak users and I work in diversifying our target audience. We of course have a reputation with TeamSpeak for being a forum you can complain to admins and not get banned lol. On TeamSpeak you’d be banned for disagreeing with any mod.

If I am not mistaken, the issue stems from the way in which Windows handles the specific unicode characters as tooltip text - another reason I love Linux.

Run that in a Chrome affected browser to see an example of the patch working. This obviously does not patch the UI framework issue Chrome (or Windows) suffers from. But for an admin protecting user clients, this is a solid fix in the interim.

In the above quoted post, you can see a quick write-up on what you mentioned! These happen from time to time, they are normal and called bugs, TeamSpeak on the other hand was riddled with vulnerabilities. But what is inexcusable is the lack of security TeamSpeak had on their caching system, this resulted in the ability for us to infect over a million users - WE CHOSE NOT TO. If you have not watched this, I highly recommend:

Many crashes or freezes with both Discord and TeamSpeak have been Windows-related. Should the software developer just say "Sorry users, Windows sucks and they need to fix this! Good luck."

No, hell to the no. The software developers must implement interim patching to mitigate the issue reached from the software to the operating system. This takes a degree of risk management and awareness of handling variables in programming securely. All inputs should interact with the user's operating system in a smooth and secure way.

TeamSpeak has shown a lack of urgency in fixing highly critical issues in the past, but we are thankful their developers have gotten to work patching some. I can only hope the new TeamSpeak 5 client has less security-related issues and I look forward to debugging the client.

P.S. here is an example of what I am talking about, how Windows kinda sucks sometimes:

https://www.reddit.com/r/discordapp/comments/ateo0b/_/eh3e9ez