[jitsi-dev] Prevention of metadata collection


Hey there,

Now it is very important to be able to communicate without collection
of metadata on the server.

This is a fairly broad statement and depending on you are referring to exactly, this might be possible or not, useful or not.

I want to offer developers to add two protocols to Jitsi:

1. The ability to directly connect to another client on his IP
(domain name). Customers from the contact list periodically sampled
to determine their online presence.

There are two issues here.

First: connecting to a domain name is a fairly corner use case and that directly impacts the amount of resource the dev team could put into it. That said, patches for our RegistrarLess mode for SIP are very welcome. I'd be happy to discuss issues if anyone wants to look into it.

Second: the people routing your IP packets will still be able to log metadata, you may or may not be comfortable with that but it's worth pointing out.

2. TorChat protocol to connect to the client on its onion-address
using Tor. After connecting - NAT traversal and installation of ZRTP
direct connection.

Implementing support for the TorChat is probably even less of a priority. Same as above, we would be happy to consider a patch but I am not entirely convinced that the protocol has any substantial advantages to just using XMPP over TOR (+Jingle+ZRTP). I can see how it is less usable though.

That said it is probably worth mentioning that just a couple of hours ago we had a meeting with Jacob Appelbaum and Linus Nordberg from the TOR project and we did discuss various ways of improving integration between Jitsi and TOR. This is definitely a topic we are interested in pursuing.

Both protocols do not require any external server and registration.
This eliminates the use of metadata in the server. I think it would
be a very good addition to Jitsi. This is a needed feature, and in
any case it will be released - either by you or by someone else.

You would *always* need a server to serve as a fallback relay. The larger the deployment, the more that server would require resources and the motivation for anyone providing this has to be considered.



On 01.08.13, 22:31, Van Gegel wrote: