Predictably, the MPEG-LA aren’t too pleased with this, and are no doubt winding up their PR and industry allies at the moment, as well as this opening a new front on the Apple vs Google ongoing platform battle. But if your business model is collecting money through what is essentially a protection racket and spreading FUD about patent litigation, the VP8 license implicitly creating a zero-cost zero-revenue patent pool is not going to be good news for you (from the department of Google deleting your business model). The question is now whether the allure of Google’s content will win over against the legal chest pounding of the patent trolls, and whether they start flipping switches to make YouTube only serve up WebM content after a while.

Also in amazing and incredible news, Collabora’s Telepathy/GStreamer/GNOME/Debian/general R&D guru and staunch Web 2.0 holdout Sjoerd Simons has actually now got a blog after a mere 3 years of us suggesting it to him since he joined Collabora as an intern. He’s been hacking on some RTP payloader elements for VP8 so we can use it for video calling on the free desktop. All very exciting stuff, especially in conjunction with Muji (multi-user video calls over XMPP) support heading into Telepathy thanks to NLNet‘s ongoing support.

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…

Should Empathy just disappear on the desktop as things like presence applets or GNOME Shell take over parts of its function? Maybe, yes. In some ways its goal is just to bring Telepathy to end users and the desktop so that its worth other things integrating into Telepathy, but Telepathy allows us to do a lot better than a conventional IM client. Maemo and Sugar on the OLPC use Telepathy but totally integrates it into the device experience rather than having any single distinct IM client, and although Moblin uses Empathy currently it has its own presence chooser and people panel, and may go on to replace other parts of the user experience too. GNOME Shell looks set to move in this direction too and use Telepathy to integrate communications with the desktop workflow.

Should Telepathy take care of talking to social networking sites such as Facebook, Twitter, etc? There’s no hard and fast rule – Telepathy only makes sense for real-time communications, so it’s good for exposing and integrating the Facebook chat, but pretty lame for dealing with wall posts, event invitations and the like. Similarly on the N900, Telepathy is used for the parts of the cellular stack that overlap with real-time communications like calling and SMS, but there is no sense pushing unrelated stuff like configuration messages through it. For Twitter, the main question is whether you actually want tweets to appear in the same UI, logging and notification framework as other messages. Probably not anything but the 1-to-1 tweets, meaning something like Moblin’s Mojito probably makes more sense for that. Later in the summit I took a look at Google Latitude APIs, which seem like something which Telepathy can expose via its contact location interface, but probably not usefully until we have support for metacontacts in the desktop.

Can/will Telepathy support IAX2? It can, although we’d have to do a local demultiplexer for the RTP streams involved in separate calls. It’s not been a priority of ours so far, but we can help people get started (or Collabora can chat to people who have a commercial need for it). Similarly nobody has looked at implementing iChat-compatible calling because our primary interest lies with open protocols, but if people were interested we could give pointers – its probably just SIP and RTP after you dig through a layer of obfuscation or two.

If you want to know more about Telepathy feel free to comment with some follow-up questions, talk to us in #telepathy on Freenode, or post to the mailing list.

• Corridor session with David Zeuthen, Ryan Lortie, Matthias Clasen and later joined by me and Will Thompson from Collabora, discussed a lot of the issues of integrating D-Bus into Glib and I think achieved a pretty good consensus about how GVariant and GDBus should fit together and start getting the pieces merged. Really looking forwards to it, GVariant looks mad ninja.
• Some nice discussions about Gtk+ 3.0 roadmap, although I’m still worried that the sealing/accessor work will take so much developer time there won’t be that much time to make the improvements its supposed to enable. Theming was mentioned but what else should there be? Also spotted Kristian Høgsberg, Cody Russell and Matthias again talking about client-side decorations, presumably Wayland scheming… :)
• Nice session about messaging and other notifications in GNOME Shell. I really like the way the project is going, and hopefully we can join in and spend some time hooking Telepathy up here, although as a fallback to make the existing stuff (which doesn’t have specific code to hook in and make a UI), then it’d be nice if the shell could also be a frontend for the notify/indicate stuff which Ubuntu have been pushing in GNOME 2.x already.
• Had some good brainstorming about Telepathy integration in games and Tomboy sharing too, as well as some slightly less conclusive pondering about how to deliver metacontacts (ie, merging multiple sources such as IM, social networking and other address books) in GNOME. We need to sync up with what Moblin is doing here as it looks quite promising and should give us some components to re-use.
• Will, Sjoerd and I spent an hour or two around a blackboard working out how XMPP end-to-end TLS encryption might be exposed to clients in Telepathy, in order to work out how best we’d expose OTR too. It looks like we have a fairly workable proposal now which we’ll be explaining in due course, but it means at least we can give more useful advice to people who are interested in implementing it, or move forwards on implementing it ourselves.

I was really impressed by Jason Clinton and others’ summaries of the sessions, which I think are really valuable for the people who couldn’t make it to the summit. He asked me to take some notes about the first Telepathy session on Saturday evening while he was taking notes about the Outreach session. Rather than lumber him with my deranged scratchings from Tomboy, I’ll blog them separately.

Aside from that, we’re planning to hack on Empathy for basically the whole day, looking at MC5 porting and UI polish, so there will be a big load of Collabora folks and friends somewhere. Will update when I know where.

htop

A much-needed refresh of oldschool top, this still works on your beloved console but gives you visual bar-graphs of CPU, RAM and swap, lets you scroll through the processes and deliver signals/renicing without having to copy the PID off the moving target. Its like the future!

iftop

One of those things I use so often now I have no idea how I even survived without it. Why is this server lagging, who’s hogging the wireless/DSL, which VM is chewing all of the upstream bandwidth? iftop shows you at a glance how much traffic is being used by which host pairs on a given interface, and you can toggle port numbers on and off with simple key-presses. Absolutely indispensable.

iotop

Does this box feel slow to anyone else? Is it swapping, or is it the database server chewing all the IO? Why does my drive keep seeking? It’s amazing… top for IO bandwidth usage!

A passing mention is deserved for apachetop too, which is pretty neat, but when a server is being hammered it’s not something I found too hard to get a feel for just by tailing the log for a while, so it’s not been as life-changing as the others. Maybe that just means my servers don’t see enough traffic.

“… all programs that interact with e-mail are broken in one way or another. Please be careful.” – Lars Wirzenius

I seem to have a cunning knack of finding problems with configuring server software, particularly involving e-mail, where a) I can’t find answers in Google, b) most people I go and ask for help say they’d usually ask me such things, and c) if I go onto IRC or mailing lists I end up helping other people and not getting any help with my problem. It’s quite likely this is just because I’m something of a perfectionist, so the ridiculous crappy hacks people come up with and seem content to entrust their mail to are unacceptable to me for one reason or another. Anyway, in my ongoing quest for the perfect mail system, I’ve painted myself into a corner again.

(I’m currently running with postfix, postgrey, clamav-milter, dspam, dovecot using LDA, managesieve and the cmusieve & antispam plugins. If I can get the current incarnation working, I’ve had enough requests to write up a full HOWTO, and seen enough around with pretty questionable content, that I’ll probably do it before too long.)

I’ve got postfix’s local transport configured to hand mail to dspam over LMTP, using mailbox_transport = lmtp:unix:/dspam/dspam.sock. dspam is configured to listen here, add X-DSPAM-Result and signature headers, and then deliver the mail with dovecot’s deliver LDA (which I’ve set to 4750 root:dspam). From dspam.conf:

ServerParameters "--deliver=innocent,spam -d %u"
ServerDomainSocketPath "/var/spool/postfix/dspam/dspam.sock"
...
Preference "spamAction=tag"
Preference "signatureLocation=headers"
...
TrustedDeliveryAgent "/usr/lib/dovecot/deliver"

My dovecot configuration is pretty standard, using PAM for both passdb and userdb, and provides the auth-master socket that deliver needs. The problem I have is that postfix’s local transport is qualifying the local username with the FQDN of the machine before delivering it to dspam with LMTP (the local mail transfer protocol), even for locally-originated mail which was only addressed with a bare username! dspam doesn’t mangle it or care if the user is local or not, and then cheerfully invokes deliver -d robot101@omega.example.co.uk, which returns EX_NOUSER (addressee unknown) because my username is just robot101. From mail robot101:

Mar 6 02:25:40 omega postfix/pickup[13607]: DAA4942F41F: uid=1000 from=<robot101>
Mar 6 02:25:40 omega postfix/cleanup[13637]: DAA4942F41F: message-id=<20090306022540.DAA4942F41F@omega.example.co.uk>
Mar 6 02:25:40 omega postfix/qmgr[12552]: DAA4942F41F: from=<robot101@omega.example.co.uk>, size=339, nrcpt=1 (queue active)
Mar 6 02:25:40 omega dovecot: auth(default): passwd(robot101@omega.example.co.uk): unknown user
Mar 6 02:25:40 omega dspam[13527]: Delivery agent returned exit code 67: /usr/lib/dovecot/deliver -d robot101@omega.example.co.uk
Mar 6 02:25:40 omega postfix/lmtp[13640]: DAA4942F41F: to=<robot101@omega.example.co.uk>, orig_to=<robot101>, relay=omega.example.co.uk[/dspam/dspam.sock], delay=0.08, delays=0.05/0.01/0.01/0.03, dsn=4.3.0, status=deferred (host omega.example.co.uk[/dspam/dspam.sock] said: 421 4.3.0 <robot101@omega.example.co.uk> Delivered (in reply to end of DATA command))

So, no e-mail for me. Dearest lazyweb, which of the three components is behaving wrongly, and how can I fix it?

(And no, I’m not just going to switch to GMail. I store my data on hard drives, which are sometimes in servers, not “in the cloud”. Until about a month ago, most people I knew spoke about clouds which were made of particles of water in the sky, rather than as a data storage media. What if it rains? ;)

Update: The problem is fixed! Even though arguably the problem is dspam’s for not knowing which users are local or not, it’s fixable in dovecot 1.1.x using the auth_username_format = %n option. Thanks so much to Angel Marin for helping me out.

Update 2: There’s also a patch for dspam floating around which adds a StripRcptDomain option, which makes the LMTP server truncate the e-mail address at the @, so essentially assumes everyone to be a local user. The problem with both of these fixes is that they’re both blunt instruments which will break virtual users on the same host. I think the real fix would be something more like a LocalDomains option in dspam, to choose which domains should be considered local and truncated from the e-mail addresses for delivery purposes.

It’s the last day of the most awesome linux.conf.au 2009 conference in Hobart, Tasmania. I’ve just witnessed the a room full of 500 people sit with baited breath as Linus wielded a set of clippers to shave Bdale Garbee‘s beard, followed by Bdale (with a razor with 3 more blades than last time he shaved, a tiny bowl of water and a hand-mirror) trying to make it look neater. The LCA twitter feed was up on the projector, and someone rightly observed this whole event was actually pretty weird. There are already pictures on flickr too. However, well done to Bdale for being such a good sport, but it looks like his wife Karen will accompany him next year to make sure he doesn’t agree to anything else like this, and supervise the waxing of Rusty‘s chest… :)

What’s this all in aid of? After the incredible auction for this beautiful picture from Karen, and generous donations at the Penguin Dinner on Wednesday night, the conference has now raised between AU$ 35k and 40k towards the Save the Tasmanian Devil appeal. Around AU$ 1.3k of the nonsensical winning consortium’s AU $10.6k bid came from the Collabora folks who were at the dinner, and AU$ 1.2k from Collabora and Collabora Multimedia directly. We were all set to place a winning AU$ 3k bid but then Matthew and Daniel came up with the Bdale shaving scheme, and then things really picked up. I’m glad we took part – the lead scientist from the project was really grateful, and I hope the money can make a real difference to their great work.

On more mundane matters, I also gave my talk this morning, and my slides (Telepathy slides v2.0 thanks to Marco) are online. I also made a few demos of new awesome stuff you can do with Telepathy (most of the patches are already merged upstream or well on the way):

• Geolocation support (XEP-0080) support in the XMPP backend and Empathy, using GeoClue to find your location and the libchamplain Clutter & Open Streetmap widget to display where your contacts are. Thanks to Pierre-Luc, Alban and Daf for their work here – more details on Pierre-Luc’s blog.
• Support for launching file transfers over link-local XMPP from Nautilus using the Empathy plugin for nautilus-sendto. This is already merged upstream but needs a patch to work with trunk Empathy. Thanks to Marco, Jonny and Guillaume for their work on this.
• Alban also made a neat hack to Rhythmbox which allows exporting your DAAP music server to one of your contants over a Telepathy Stream Tube. Thanks also to recent work from Marco, these tubes now go over XMPP’s SOCKS5 Bytestreams, giving much better throughput than the earlier in-band implementation, network permitting. The next step is unleashing the full might of our libnice NAT traversal library, signalling tubes with Jingle, and therefore making connections work peer to peer in up to 95% of the cases. However, this won’t affect the APIs, stuff will just go faster! Isn’t Telepathy wonderful?
• Olivier stepped up to show off the demo from his talk about Farsight, which shows his branch using the new telepathy-farsight library to allow recording Telepathy video calls directly into the PiTiVi video editor. His network was screwed up so it didn’t work, but I did see it work in his talk yesterday! Awesome stuff, hopefully Edward and friends can pick it up and merge it in before too long.
• Unfortunately we ran out of time for Will to show off Guillaume’s recent work on Telepathy-enabled Abiword on the desktop (rather than just Sugar’s Write activity), but I expect he’ll blog about it soon!

On that note, these were just the five that I picked to try and fit into my talk. There are a load more demos in the pipeline from the other guys in Collabora of doing stuff with Telepathy, so keep a close look on Planet Collabora for the next cool thing.

My brother Alastair is a health editor for the Bupa private health insurance company, and thought of this neat project which was implemented by my housemate Martin Kleppman, and announced at new year. It helps you keep track of how long since you’ve smoked, how much money you’ve saved, lets you and your friends know how you’re doing, and has health tips about the improvements that you can expect from your new-found abstinence. I’m not a smoker but hopefully someone will find it useful.

I just upgraded Gtk+, Cairo and Pango to the versions in Debian experimental while I was upgrading some Telepathy packages, and got this the next time I loaded OO.o. Magic. But seriously, anyone got any ideas what’s going on?

Update: I switched my Debian mirror to .au and downloaded OpenOffice.org 3.0.1~rc2, and installed the Gtk+ and GNOME stuff too, and not only did the fonts came back, but it no longer looks like the 80s. Score! Thanks for the tips. Back to my talk…