Less protocols and less codecs means less
Well, no, it does not. It actually means more maintenance and work. If
we spin a light version of Jitsi with fewer protocols and codecs, as you
suggest, we would still be maintaining and developing stuff for the
non-removed protocols and codecs because they would still be supported
by the full version. On the other hand we would need to maintain a new
branch with its own builds, versioning and downloads.
It means much simpler system, easier understood by a common user.
The only simplification that would reach users is that in the "protocol"
combo box when creating a new account. This may indeed be an advantage
for some but it, in our opinion, it would not be worth the effort of
maintaining one extra version.
If such a basic thing like port usage, causes confusion among active
users, it is a bad sign.
I lost you here. First of all I don't see how "port usage" is a basic
thing to users. It is a concept that may even be confusing to some IT
professionals. Secondly I am not sure why users should be exposed to
that concept. Jitsi does not normally require users to configure
anything port related.
There are of course cases where this may be necessary. We are already
doing some things to circumvent such problems and we have others (such
as TCP support for Jingle Nodes) scheduled for the future. We'll get
I 've been playing with Jitsi for a few months and for me the only
reliable Jitsi feature is chat (and only via jit.si).
Audio often does not work ("ICE failed"). Video almost never works.
For the record, I am an IT professional.
Well ... we'd be happy to hear about your individual problems and see if
we can do anything to address them.
I believe, that the problem is my lack of knowledge. A simple setup
procedure + clear system messages (eg. "Direct connection impossible.
Open port X.") would be the solution.
It seems that you already have completed all the necessary steps. All
you need to do in Jitsi is create an account (e.g. on jit.si) and start
using it. I assure you that, as a user, we are not expecting you to do
If things fail for you it is not because you did not configure Jitsi
properly. Problems are most often due to overly restrictive firewalls,
issues that we may have with specific hardware (such as webcams), and of
course, the occasional Jitsi bug.
About the central points. Even if the communication is encrypted
end-to-end, the central server knows when I am online and when I am not.
It knows my contacts. That's damn a lot!
Not every private individual is willing/capable to run his own XMPP
server, 24/24, 7/7.
Therefore a distributed system would be safe, convenient and reliable.
Well, personally I am not aware of a mature and stable technology that
allows you to do this in a reliable and way. There are many efforts out
there (SIP Witch, P2PSIP, etc.) that provide various degrees of
distribution (note that central points are still often necessary) but I
am afraid that neither of them is in a stage that would allow for a
straightforward integration in Jitsi. They would all require a
substantial R&D effort and we currently have other priorities.
Hope this answers your question,
On 28.05.12 13:50, Adrian wrote:
On 28/05/12 12:43, Emil Ivov wrote:
On 28.05.12 12:08, Adrian wrote:
Concerning the recent discussions on security, I think, that the open
source nature of Jitsi, encryption and - above all - being outside the
mainstream, makes Jitsi very secure.
However I dream of a communicator having no central authority, no
Well ... you can get that by running your own XMPP server. The XMPP
world is federated and there is no main XMPP server.
Any central point can easily be destroyed or coerced into giving up data.
This is true and this is why we support end-to-end encryption mechanisms
like ZRTP where compromising a central point does not affect your call
security. At least not without the user seeing it.
Distributed database technology is there - I2P (Java!), Bitcoin, old
good Cademlia, etc.
If Jitsi would be capable of that, it would make it really unique (and
very much wanted) in the world.
Maybe there should be a light version having just one or two good audio
and video codecs, supporting just one or two protocols and being able to
work without central servers.
I am not sure what would be the point of a version that has less
protocols and less codecs. It certainly wouldn't impact performance or
size in a significant way. Did you have something else in mind?
/“Fascism should rightly be called Corporatism, as it is the merger of
corporate and government power.”
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
firstname.lastname@example.org PHONE: +18.104.22.168.43.30
http://jitsi.org FAX: +22.214.171.124.47.31