Difference between revisions of "Upcoming"

From Mumble Wiki
Jump to: navigation, search
(added categories)
(Upcoming page linked to 1.2.5 security release)
(12 intermediate revisions by 4 users not shown)
Line 1: Line 1:
This lists upcoming features in future versions of Mumble. No ETA is given, and they will happen in the 2008 timeframe at the earliest. Also, some of these ideas are just ideas and not actual plans.
#REDIRECT [[1.3.0]]
''Please do not edit this page unless you plan to implement the new feature yourself. This is '''not''' a feature request page''
== User certificate ==
Many people have asked for a way to register new users from inside the client. Any such scheme is inherently dangerous, as it opens up for social engineering attacks and it also has the problem when murmur is connected to an external database. How do you add users to a phpBB database through DBus?
It also has major problems with account self-management. If a user forgets his password, how can he prove he is who he says he is? The current scheme using email authentication ensures there is at least a single fallback method, but an in-client solution has no such security.
As an alternative user authentication method, we plan to have each client generate a SSL certificate. This certificate is then your password. This password will never be sent to any server, it will just be used for public key authentication. As such, the same certificate can be used on all servers you connect to.
Once this is in place, it's pretty easy to "fix" connected user. Such an operation just assigns that user a murmur userID. So a server admin would click a user and "assign ID" or the ACLs would allow the user to do that themselves.
In such a system, it is up to the user to copy the certificate to a secure location. However, he only has to do so once, and it's the same certificate being used for all servers. We might even support using "real" third-party certificates that are stored in the certificate store of the OS.
== Video ==
The current overlay texture system is designed for high speed texture transfers in a format that happens to be 60 pixels high. This is no coincidence.
Using H.264 encoding, 80x60 pixels is small enough that we can encode a 15fps video stream with minimal CPU impact. The bitrate will also be low (lower than existing audio streams), and with a bit of filtering the quality is near perfect. I really mean this; what filtering did for the audio quality in Mumble it also does for video quality.
I'd like to see this happen; I miss seeing my friends when we're gaming. It's one thing to hear enthusiasm, it's quite another to see it.
There are two major challenges. The first is a technical one. 80x60 pixels is not much. It is enough to see a face clearly, if the face is the only thing in the picture. However, most people have their cameras placed so that 70% of the picture area is the room they are sitting in. That will not give a good enouh picture. So, we'll need a method to extract what we need from the image.
The second is bandwidth. Yes, the video stream will use less bandwidth that an audio stream, but it will be going the whole time. This means that while audio bandwidth scales linearly with the number of users, video bandwidth scales exponentially. For example, if we assume that each user has 30 kbit/s of audio and 20 kbit/s of video. When one user talks, the others shut up. With 10 users, that's 9*30=270 kbit/s out from the server. Video, which is going the entire time, is 9*20=180kbit/s ''for each user'', giving us a total of 1.8Mbit/s.
For all clans and guilds who host their servers somewhere with free bandwidth, this is not a problem. However, I don't really want to know what a 2mbit/s commercial hosting is going to cost. I doubt it's cheap.
{{docs en}}

Latest revision as of 15:40, 6 February 2014

Redirect to: