Russell Coker: TPG Lies
Shortly before 9AM this morning I discovered that the IP address for my mail server was not being routed, according to my logs the problem started shortly after midnight. It s on a TPG ADSL connection, there is one IP address for the PPPOE link and 6 addresses in a /29 routed to it one of the addresses in the /29 is for my mail server.
It wasn t until 3PM that I was able to visit the server to sort the problem out. It turned out that the main IP address was working but the /29 wasn t being routed to it. So TPG had somehow dropped the route from my routing table. I pinged all the addresses from a 3G broadband connection on my EeePC while running tcpdump on the server, and no packets for the /29 came through but the IP address for the PPP link worked fine. I was even able to ssh in to the server once I knew the IP address of the ppp0 device for future use I need to keep ALL IP addresses of all network gear on my EeePC not just the ones used for providing services.
So I phoned the helpdesk, and naturally they asked me inane questions. My patience extended to telling them the broadcast address etc that was being used on the Ethernet device (actually a bridge for Xen but I wasn t going to confuse them). The system been power-cycled before I got there in the hope that it might fix the problem so I could honestly answer the question have you rebooted it (usually I lie rebooting systems to fix network problems is a Windows thing). But my patience started to run out when they asked me to check my DNS settings, I explained very clearly that my problem was that IP packets couldn t get through and that I wasn t using DNS and demanded that they fix it.
I didn t get anyone technical to look at the problem until I firmly demanded that the help-desk operator test the routing by pinging my systems. The help-desk people don t have Internet access so that actually testing the connection required escalating the issue. It seems that the algorithm used for help-desk people is to just repeatedly tell people to check various things on their own system, and that continues until the customer s patience runs out. Either the customer goes away or makes requests firmly enough to get something done about it.
So their technician did some tests and proclaimed that there was no problem. While said tests were being done things started working, so obviously their procedure is to fix problems and then blame it on the customer. It is not plausible to believe that a problem in their network which had persisted for more than 15 hours would accidentally disappear during the 5 minute window that the technician was investigating the problem.
In the discussion that followed the help-desk operator tried to trick me into admitting that it was my fault. They claimed that because I had used multiple IP addresses I must have reconfigured my system and had therefore fixed a problem on my end, my response was I HAVE A HEAP OF MACHINES HERE RUNNING ALL THE TIME, I USE WHICHEVER ONE I FEEL LIKE, I CHANGED NOTHING . I didn t mention that the machines in question are DomUs on the same Xen server, someone who doesn t understand how ping works or what routing is wouldn t have been able to cope with that.
I stated clearly several times that I don t like being lied to. Either the help-desk operator was lying to me or their technician was lying to them. In either case they were not going to trick me I know more about how the Internet works than they do.
TPG was unable to give me any assurance that such problems won t happen again. The only thing I can be sure of is that when they lie they will stick to their story regardless of whether it works.
It is great to see that the collaboration between 
This is the fifth year we hold an EDUSOL, and we are closing in on it. EDUSOL is an online encounter whose topics are Education and Free Software Actually, this year we are widening our scope, and we will include Free Culture as well as a base area.
Now, besides those three general areas, each year we have had a base topic around which we invite the speakers to talk about (although it is a lax requirement). This year, the base topic is social networks No, not in the Twitter/Facebook/blah sense, but as a wider phenomenon, studying interaction between people, the forming of communities. And for our particular areas, the forming of knowledge-based communities.
Anyway I agreed with the organizers to provide the English translation of the participation invitation. I will skip the call for papers, as we are basically at the proposal deadline (October 17), but if you have anything you want to propose, please tell us so!
Leaving that aside... Please excuse the quality of my translation, it is late and I'm tired. We will work on it :)
Videoconference reception
EDUSOL spans several participation categories. The closest category to a traditional, face to face conference. Each year, we invite a group of speakers to talk about a topic related to our main discoursive line.
Among the speakers that have confirmed so far, we have:
So, next Saturday 
Speaking of Minas Gerais, it is, according to Wikipedia, the fourth in size among the 26 States of Brazil, being just a bit bigger than mainland-France. Minas Gerais is one of the main earth transports hubs of the country (having the largest number of federal roads), and is famous for its tasty food, the beauty of its people, its cheeses, the calm, introspective nature of its people, its interesting way of speaking portuguese, and its alcoholic beverages.
Now, going away from Rio to Belo Horizonte has a single big disadvantage associated with it: we don t get to have the Sea a few minutes away, anymore. Our solution to that is, of course, going to one of the numerous bars (the legend goes around that BH has the largest absolute number of bars of all cities in the world), and drinking instead of swimming! Quem n o tem mar, vai pro bar!
The first Telepathy session session on Saturday evening at the Boston GNOME Summit was very much of a Q&A where myself and Will answered various technical and roadmap issues from a handful of developers and downstream distributors. It showed me that there s a fair amount of roadmap information we should do better at communicating outside of the Telepathy project, so in the hope its useful to others, read on
MC5
Ted Gould was wondering why Mission Control 4 had an API for getting/setting presence for all of your accounts whereas MC5 does not. MC5 has a per-account management of desired/current presence which is more powerful, but loses the convenience of setting presence in one place. Strictly speaking, doing things like deciding which presence to fall back on (a common example being if you have asked for invisible but the connection doesn t support it) is a UI-level policy which MC should not take care of, but in practice there aren t many different policies which make sense, and the key thing is that MC should tell the presence UI when the desired presence isn t available so it could make a per-account choice if that was preferable. As a related side point, Telepathy should implement more of the invisibility mechanisms in XMPP so it s more reliably available, and then we could more meaningfully tell users which presence values were available before connecting, allowing signing on as invisible.
Since MC5 gained support for gnome-keyring, its not possible to initialise Empathy s account manager object without MC5 prompting the user for their keyring password un-necessarily (especially if the client is Ubuntu s session presence applet and the user isn t using Empathy in the current session but has some accounts configured). Currently the accounts D-Bus API requires that all properties including the password are presented to the client to edit. A short-term fix might be to tweak the spec so that accounts don t have to provide their password property unless it s explicitly queried, but this might break the ABI of tp-glib. Ultimately, passwords being stored and passed around in this way should go away when we write an authentication interface which will pass authentication challenges up to the Telepathy client to deal with, enabling a unified interface for OAuth/Google/etc web token, Kerberos or SIP intermediate proxy authentication, and answering password requests from the keyring lazily or user on demand.
Stability & Security
Jonathan Blandford was concerned about the churn level of Telepathy, from the perspective of distributions with long-term support commitments, and how well compatibility will be maintained. Generally the D-Bus API and the tp-glib library APIs are maintained to the GNOME standards of making only additive changes and leaving all existing methods/signals working even if they are deprecated and superseded by newer interfaces. A lot of new interfaces have been added over the past year or so, many of which replace existing functionality with a more flexible or more efficient interface. However, over the next 4-6 months we hope to finalise the new world interfaces (such as multi-person media calls, roster, authentication, certificate verification, more accurate offline protocol information, chat room property/role management), and make a D-Bus API break to remove the duplicated cruft. Telepathy-glib would undergo an ABI revision in this case to also remove those symbols, possibly synchronised with a move from dbus-glib to GVariant/etc, but in many cases clients which only use modern interfaces and client helper classes should not need much more than a rebuild.
Relatedly there was a query about the security of Telepathy, and how much it had been through the mill on security issues compared to Pidgin. In the case of closed IM protocols (except MSN where we have our own implementation) then we re-use the code from libpurple, so the same risks apply, although the architecture of Telepathy means its possible to subject the backend processes to more stringent lockdowns using SElinux or other security isolation such as UIDs, limiting the impact of compromises. Other network code in Telepathy is based on more widely-used libraries with a less chequered security history thus far.
OTR
The next topic was about support for OTR in Telepathy. Architecturally, it s hard for us to support the same kind of message-mangling plugins as Pidgin allows because there is no one point in Telepathy that messages go through. There are multiple backends depending on the protocol, multiple UIs can be involved in saving (eg a headless logger) or displaying messages (consider GNOME Shell integration which previews messages before passing conversations on to Empathy), and the only other centralised component (Mission Control 5) does not act as an intermediary for messages. Historically, we ve always claimed OTR to be less appealing than native protocol-level end-to-end encryption support, such as the proposals for Jingle + peer to peer XMPP + TLS which are favoured by the XMPP community, mostly because if people can switch to an unofficial 3rd party client to get encryption, they could switch to a decent protocol too, and because protocol-level support can encrypt other traffic like SRTP call set-up, presence, etc.
However, there is an existing deployed OTR user base, including the likes of Adium users on the Mac, who might often end up using end to end encryption without being aware of it, who we would be doing a disservice by Telepathy not supporting OTR conversations with these people. This is a compelling argument which was also made to me by representatives from the EFF, and the only one to date which actually held some merit with me compared to just implementing XMPP E2E encryption. Later in the summit we went on to discuss how we might achieve it in Telepathy, and how our planned work towards XMPP encryption could also help.
Tubes
We also had a bit of discussion about Tubes, such as how the handlers are invoked. Since the introduction of MC5, clients can register interest in certain channel types (tubes or any other) by implementing the client interface and making filters for the channels they are interested in. MC5 will first invoke all matching observers for all channels (incoming and outgoing) until all of them have responded or timed out (eg to let a logger daemon hook up signal callbacks before channel handling proceeds), all matching approvers for incoming channels until one of them replies (eg to notify the user of the new channel before launching the full UI), and then sending it to the handler with the most specific filter (eg Tomboy could register for file transfers with the right MIME type and receive those in favour to Empathy whose filter has no type on it). Tubes can be shared with chat rooms, either as a stream tube where one member shares a socket for others to connect to (allowing re-sharing an existing service implementation), or a D-Bus tube where every member s application is one endpoint on a simulated D-Bus bus, and Telepathy provides a mapping between the D-Bus names and the members of the room.
In terms of Tube applications, now we ve got working A/V calling in Empathy, as well as desktop sharing, and an R&D project on multi-user calls, our next priority is on performance and Tube-enabling some more apps such as collaborative editing (Gobby, AbiWord, GEdit, Tomboy ?). There was a question about whether Tube handlers can be installed on demand when one of your contacts initiates that application with you. It d be possible to simulate this by finding out (eg from the archive) which handlers are available, and dynamically registering a handler for all of those channel types, so that MC5 will advertise those capabilities, but also register as an approver. When an incoming channel actually arrives at the approval stage, prompt the user to install the required application and then tell MC5 to invoke it as the handler.
Colin Walters asked about how Telepathy did NAT traversal. Currently, Telepathy makes use of libnice to do ICE (like STUN between every possible pair of addresses both parties have, works in over 90% of cases) for the UDP packets involved in calls signalled over XMPP, either the Google Talk variant which can benefit from Google s relay servers if one or other party has a Google account, so is more reliable, or the latest IETF draft which can theoretically use TURN relays but its not really hooked up in Telepathy and few people have access to them. XMPP file transfers and one-to-one tube connections use TCP which is great if you have IPv6, but otherwise impossible to NAT traverse reliably, so often ends up using strictly rate-limited SOCKS5 -ish XMPP proxies, or worse, in-band base64 in the XML stream. We hope to incorporate (and standardise in XMPP) a reliability layer which will allow us to use Jingle and ICE-UDP for file transfers and tubes too, allowing peer to peer connections and higher-bandwidth relays to enhance throughput significantly.
Future
Ted Gould had some good questions about the future of Telepathy
A new version of
There is no secret that many Debian contributors share their time between various projects, while Debian is one of those projects.
Once upon a time I wrote a blog compiler, a simple tool that would read in a bunch of text files and output a blog. This blog would contain little hierarchies for tags, historical archives, etc. It would also have a number of RSS feeds too.
Every now and again somebody will compare it to 
I tend to dress quite casually - unless there's a good reason to do otherwise I'll be in jeans and a t-shirt, or something similar. I'm comfortable in it and I take the view point that in general people shouldn't be making assumptions based on what I'm wearing. Of course they do, and while this can be infuriating at times it can also be amusing. The man at the RBoS who witnessed me signing the personal DD guarantee form for Black Cat obviously couldn't reconcile my appearance with what I was there to do, for example.
