Planet Jabber

Artur Hefczyc: All Tigase projects publicly available

kobit — Fri, 09 May 2008 11:43:11 +0000

Recent Minichat addition on the Tigase website raised lots of questions about access to the source code.

Following those requests we have listed all the projects Tigase team works on and all the source codes are now publicly available. You can go to the projects page and browse all the published projects.

Please note, most of the project trackers are in initial state and the web content might be missing. You can, however access the project source codes, bug tracking system and see the roadmap. We are working hard on adding missing elements.

Your comments as always are very welcomed.

Florian Jensen: Jabberforum.org - Mailinglists 2.0

Florian Jensen — Thu, 08 May 2008 22:19:48 +0000

It’s official. Jabberforum.org has replaced the old forums on Jabber.org. Besides running a real forum software, it has a lot of nice features.

Social Groups: Social groups are communities on the forum, where members can post some pictures and post messages. A bit like Jaiku Channels, just with pictures and without SMS.

Thats fun, but there’s more!

The coolest feature we just installed is: Mailinglist integration! You can now read all posts from the mailinglists via the forum, and also reply to them via the forum! We currently have set up 3 lists, Jadmin / Jdev and Juser, but we’ll add more soon.

I showed this to stpeter, who is mainly hanging out on Mailinglists, and isn’t really familiar with Forums, but even he said:

[00:08:28] <stpeter> niiiiiice!

This means something

So join the 21st century, join Jabberforum.org

Peter Saint-Andre: Microblogging Over XMPP

stpeter — Wed, 07 May 2008 22:07:51 +0000

There’s been plenty of talk recently about using XMPP to build a decentralized microblogging platform (think Twitter busted apart to run as a distributed network of microblogging providers). Indeed, as Bob Wyman points out, we have all the pieces:

The core XMPP infrastructure, comprised of 100,000+ messaging and presence servers plus millions of end users.
The XMPP publish-subscribe extension, specifically the personal eventing profile thereof, which enables your IM account to function as a virtual pubsub service and thus push out all sorts of notifications about you.
The Atom syndication format along with the Atom threading extension, which (being XML) is easily transported over XMPP.

Now it’s just a matter of putting the pieces together, so Joe Hildebrand and I have done just that in a little spec we call Microblogging Over XMPP. Feedback is welcome!

UPDATE: While I was at it, I pushed out a new version of draft-saintandre-atompub-notify. Enjoy!

Google Talkabout: New chatback styles

Bruce Leban (noreply@blogger.com) — Tue, 06 May 2008 21:12:12 +0000

New chatback badge style examples
One line basic:
Two line basic:
Hyperlink and status icon:	Chat with Itala

We recently added the ability to create Google Talk chatback badges in several new styles. These options are available by clicking on the “Styles” drop down menu when creating a chatback badge. Examples of the new types of formats can be seen on the right.

The two borderless versions of the badge make it easier to fit into your page and customize the appearance as you like. You can just paste the code where you want the link to appear. If you want to further tweak the appearance, you can add some style parameters: Add fontfamily and fontsize to choose a specific font or size, and textcolor and linkcolor to set the colors using a hexadecimal RRGGBB value. You can add these parameters to either the new badge URL or to the iframe's src URL in the generated HTML. You can also use the h and w parameters to specify the height or width of the badge.

For example, &fontfamily=courier%20new&fontsize=13&linkcolor=000000&textcolor=880000 will give you Courier New 13 with black for the link text and dark red for the rest of the text. Here is an example of how this looks with the classic badge:

In addition to providing more flexibility in terms of appearance, chatback can now be used on web sites that don’t allow frames. For these sites, use the new HTML version of the badge. This version can’t display a status messages but it will show your status as a colored circle anywhere you can embed an image. And if you can’t embed an image (like in an email message), you can use the hyperlink by itself or just the URL.

To create a badge, visit http://www.google.com/talk/service/badge/New or, if you are a Google Apps user, visit http://www.google.com/talk/service/a/DOMAIN/badge/New replacing DOMAIN with the name of your domain.

Bruce Leban
Software Engineer

Daniel Henninger: IntelliJ... Can we talk about this?

daniel — Tue, 06 May 2008 15:51:24 +0000

IntelliJ, why do you insist on bleeding memory relentlessly as I use you? I should not see your usage increasing by 3 megs every second. Sure garbage cleanup is taking care of it, but geez...

Supposedly this was supposed to be fixed in 7.0.3. I'll get back up with JetBrains when I have the patience to do so. Generally it doesn't seem to cause any real problems, it's just damned bizarre! See attached movie clip for fun. ;)

Matthew Wild: Jabber Abuse Handling

Matthew (noreply@blogger.com) — Tue, 06 May 2008 01:28:06 +0000

No blog post since... when? Never mind :)

Something that interests me became a hot topic in the Jabber community (specifically server administrators). We had a meeting at fairly short notice about possible solutions to the problems we know are around the corner.

The following are some *quick* rough notes I made (too early in the morning) of an abuse reporting method, very much along the lines of XEP-0161: SPIM Reporting and XEP-0236: Abuse Reporting. What I have in mind is something of a mixture between the two. Not all abuse is SPIM, so XEP-0161 should probably be a little more generic (as XEP-0236 is).

I haven't thought much about the below, but I believe the general concept is not that far from usable, and doesn't disrupt too much the distributed nature of XMPP.

End-user
It is nearly always going to be the end user who originates abuse reports. Whether they received spam to their JID, or experienced flooding in a MUC room they administrate.

The abuse report should be sent to the abuser's home server.

Abuser's server
Upon receiving an abuse report, the server may choose to act immediately, or wait and gather more evidence (possibly from sources it deems more reliable).

It is important that the server relates reports it receives to IP addresses when weighing the evidence, *not* JIDs, since obviously the same user may have created multiple accounts).

Upon receiving satisfactory evidence that a certain IP is abusing the service, the server may decide what action(s) to take.

Clearly the most obvious step is to ban the IP from the server, and lock associated (reported[1]) accounts.

The other (optional) step is to report the IP of the offender to a central reporting/blacklist service (ie. abuse.xmpp.net), to help aid other servers who wish to prevent similar abuse of their own service.

[1] Only reported accounts should be locked, since legitimate users behind the same NAT router as an abuser could otherwise be (overly) punished. Unfortunately there is no way to avoid that legitimate users are sometimes going to get caught up in the net.

Clearly blocking an IP is not the ideal solution. A new IP is not usually hard to come by. Each reported IP should be investigated, and network administrators notified of the abuse to reduce the chance that it will happen again.

Dates and times are very important. In the case of dynamic IPs, it is the only way to track down the offending user. Perhaps it would be useful to report more than one IP + time and date (ie. the last X IPs that used the account), for this purpose.

Apologies for the unpolished post. Time to sleep on this :)

Tobias Markmann: Inter-Project Collaboration during Google Summer of Code™ 2008

tm — Mon, 05 May 2008 07:20:18 +0000

Since XMPP is (becomming) the biggest player from all the instant messaging protocols out there, there are a lot Google Summer of Code™ projects in the XMPP field this year. BOSH, the highly discussed dream team for connecting to XMPP from mobile or other limited network environments, is covered by a lot projects this year. My GSoC project is, not only, about adding BOSH support to libpurple, the C instant messaging library which powers desktop clients like Pidgin and Adium and web clients like Meebo. libpurple doesn't only cover nearly any proprietary instant messaging protocol but also some open protocols like IRC, SILC and of course XMPP. For XMPP, as the (future) major instant messaging protocol, it's most important that XEPs get implemented, coded and used in real life. There is a huge number of XEPs which aren't implemented and may never be, who knows. I will implement BOSH from the beginning since there is no codebase in libpurple in the BOSH field and just contacted Safa Sofuoğlu, a GSoC student for the XSF mentoring organization, who updates Openfire's BOSH implementation. We plan to test our implementations of the two XEPs, XEP-0124 and XEP-0206, against each other since he'll write a server side implementation and I'm writing a client side implementation. Our aim is to have not just working and good performing implementation but moreover implementations according to the two XMPP Enhancement Proposals. I'm looking forward to the inter-project collaboration. Cheers and good luck to all Google Summer of Code™ students, Tobias

Daniel Henninger: BlatherSource has moved to Clearspace!

daniel — Sun, 04 May 2008 05:20:01 +0000

Yes that's right, Clearspace. Those familiar with Clearspace might be thinking to themselves ... are you nuts? Clearspace is a -beast- for just a blog! Well, you're probably right. However, I like it, I work with it, and I've been interested in writing some plugins for it for a long time now. The thing is, without actually running it live anywhere for myself, I never give any priority to writing said plugins. Now I have a solid reason to. =)

So what exactly -is- BlatherSource nowadays since I moved all of my projects away from it? Well, for alll practical purposes it's my playground. I continue to use this blog for posts related to my projects, XMPP, that sort of thing. I'll be running a number of services at this site. for example, I'm now offering public XMPP services here. If you are so inclined, feel free to register with blathersource.org. As the author of the IM Gateway plugin, there's a good chance this will be the first place I upload new versions for testing, and if a number of folk start using the service here, it'll help me get a window into what errors might show up. If folk start having problems that I'm having trouble dulicating myself, hopefully I can get said folk to register at blathersource.org and "demo" the misbehaving accounts to me and such. And just in general, if you are looking for a place to house your XMPP account, you are quiet welcome to register it here.

I'll post more details on the XMPP services at a later date, but anyone is welcome to register now if they are so inclined. I'm not sure what else I'm going to run here just yet. I got a general purpose dedicated server from Hosting And Designs. I've been quite pleased with it so far! I hosted my previous web services at Modevia, who were wonderful! However, I decided I wanted to run more services beyond just web services, and also needed to feed my old sysadmin bug since I no longer do that for my job. =)

Anyway, I'm excited for my new site. Who knows, maybe it'll get me posting more. Probably not, but it's wishful thinking.

Remko Tronçon: Mimicking Jaiku with Psi

Remko Tronçon — Sat, 03 May 2008 17:14:49 +0000

The day before yesterday, Peter Saint-Andre sent out a couple of Jaiku invites to all Jabber Google Summer of Code students and their mentors, including me. Never having looked at microblogging before, I toyed around with it a bit, and it quickly reminded me that I still had something on my Psi wish-list for a while now: a flat, live log of all Jabber events in your network. Since I had a long weekend, I quickly coded up a prototype, and hooked it into Psi.

The result looks a bit like this:

If you know Jaiku, you’ll probably notice that this looks very similar to the Jaiku web interface. Besides status messages, there are all kinds of (extended) presence events from your contacts, such as the currently playing tune or his/her current mood. Groupchat (`channel’ in Jaiku) and directed messages are interleaved with the events, and get a hyperlink which, when clicked, opens up the corresponding groupchat or chat dialog. This type of event log allows you to have a good overview of everything that is happening in your Jabber network. And if your log gets cluttered with groupchat events, you can always disable groupchat events (or any other type of event) at the top of the dialog, with a more compact log as a result. Finally, just as with the Jaiku Jabber bot, you can quickly reply to the last event from a certain user at the bottom of the dialog.

When will this prototype be production-ready, you ask? Well, I’m actually not planning to invest any more time in it in the near future. The reason is that Aleksey Palazchenko (aka AlekSi) will create a brand new history system for Psi for his Google Summer of Code project. I’m pretty sure his new history system will enable us to get a global live history of events, together with filtering based on type. And if we still need some extra functionality, we could always create a plugin.

Brendan Taylor

Fri, 02 May 2008 17:28:22 +0000

Google just released some statistics for GSoC 2008, which reminded me of something I'd noticed in last year's Student/Mentor map:

lots of people in and around Vancouver
a couple of people scattered throughout BC
two people in Calgary
two people in Edmonton

And then a huge gap until Toronto.

Western Canada isn't exactly a centre of exciting software activity. :(

Remko Tronçon: Improving Psi’s roster

Remko Tronçon — Thu, 01 May 2008 21:07:29 +0000

For a while now, Psi users have been requesting several changes and additions to the roster (or `contact list‘). These requests include grouping contacts into meta-contacts, nested roster groups, and displaying user avatars in the roster. We have been postponing all these changes to the roster as much as possible, because none of us wanted to touch the roster code, for reasons I’ll explain below. This year, Psi is fortunate enough to have Adam Czachorowski (aka Gislan), a student from the Google Summer of Code, to work on roster improvements.

So far, the major cause of all Psi developers staying clear from doing substantial roster changes is probably the fact that all roster-related classes are very tightly coupled to each other. This has several consequences:

It’s hard to get a good understanding of which piece of code does what, since there is no separation of logic between the different classes, and none of them work without the other one.
The code is very fragile: if you change one tiny piece, you might break something completely different. Moreover, it’s hard to tell what you broke, since the functionality is spread out across the different classes.
The code is untestable: Since there is no decent separation of the roster logic (i.e. the structure of the roster) and the roster user interface (i.e. how it is shown), it has been impossible so far to create some form of automated tests for the roster code. Because of the tight coupling between the various classes, it is impossible to test each part of the roster functionality in isolation, making unit testing impossible. Given that the roster is the most central part of the Psi user interface, it is actually unacceptable that we have no form of testing whether it (still) functions correctly.
There can be no reuse of any of the roster code in other parts of the UI (such as the list of participants in the MUC dialog), or even for other IM clients that are based on the back-end of Psi.

Because of these fundamental issues, a complete makeover of the roster code is in order. More specifically, we want to have a clear separation of anything that has to do with UI, and the actual logic of the roster. Additionally, we want the (untestable) UI layer to be as thin as possible, pushing as much down to the logic layer as we can. Finally, we want to achieve a full coverage of the logic layer using only unit tests.

What Gislan will exactly do in his Google Summer of Code project still has to be worked out in detail. He will be responsible for a major part (if not all) of the roster rewrite, and get some new functionality in there as well (since that will be a breeze with the new code). You can follow his progress on his blog, and get more detailed technical information on the project page for his GSoC project.

Coccinella: Coccinella 0.96.8 Released

sander — Wed, 30 Apr 2008 21:44:26 +0000

The Coccinella project is pleased to announce today the immediate availability of Coccinella 0.96.8, a free and open-source cross-platform chat client with a built-in whiteboard for improved collaboration with other people. Coccinella 0.96.8 sees many usability improvements in transport integration. Staying in touch with people on networks which do not yet interoperate is now easier than ever as you can see:

Other highlights of Coccinella 0.96.8 include:

Better support for actions on multiple contacts
Close buttons on tabs
Redesigned directory structure for themes, stay tuned!
Undo & Redo of text
Support for multiple DNS SRV Records
Enhanced Mac OS X integration

Communicate with Coccinella and stay tuned for next version on September 24!

About Coccinella

Learn

Screenshots

View

Download Coccinella

Get

Dave Cridland: Ooooh. Toy!

dwd — Tue, 29 Apr 2008 08:51:00 +0000

PEP Aggregator, announced (very) early this morning, and nothing to do with my last post which talked about precisely this kind of thing. (I talked about bookmarks, he’s doing user tune, but it’s much of a muchness).

Stephan Maka wrote it, you can contact him on the jdev list if you’re interested in helping (and can code Ruby).

I know it’s terribly trendy to do this, but if you ask me, this is Web 3.0, and the shape of things to come.

Peter Saint-Andre: Jabbering via iPhone?

stpeter — Mon, 28 Apr 2008 21:08:35 +0000

When it comes to telephones I am a confirmed user of trailing-edge technologies, but if it’s true that Apple is adding XMPP support to the iPhone then I just might need to reconsider. :)

Artur Hefczyc: Installing Minichat on your website

kobit — Fri, 25 Apr 2008 22:43:02 +0000

We have made Minichat available just to demonstrate new stuff we are working on, to do some tests and collect your opinions. The feedback we have got exceeded our expectations. The most common question was: Can I/how can I install it on my website?

Installing the Minichat on your website is very simple so I am putting here instructions for all of you who want to include the Minichat client on your website and allow visitors to chat with you.

Just to remind you - this code is still under development and will be updated and changed very often. It may even stop working temporarily or permanently. We can even intentionally block certain users or IP addresses if we discover any abuse. If you are ready for this and still want to have it continue reading...

Dave Cridland: Replacing ACAP - Sharing Data

dwd — Fri, 25 Apr 2008 15:35:09 +0000

There’s another part to ACAP beyond configuration, though. ACAP allows you to share bookmarks, for example, with anyone else on the same server, or with anyone at all, anywhere. It’s a precursor, in this respect, to the social bookmarking sites like Delicious, but with several key differences.

The most obvious of these is that the owner of the data remains in control of it at all times. If you want to stop sharing your data, then you simply stop sharing it. There’s no complicated privacy agreements involved here, it’s your account, and quite possibly on your server.

Admittedly, I’m a particular fan of people running their own servers. I should call this concept MicroServers™, and make myself famous for a new Meme™, but I actually call it Common Sense™. The real reason I think people should run MicroServers™ is to be in control of their own data, which just seems to me to be a pretty basic thing to want to do, and not some terribly dramatic new concept at all.

So, anyway - you do lose the rather nice feature of the social networking sites to aggregate and statistically analyse data. For example, there’s no way to see how many people have bookmarked the same thing. But that’s actually okay, because you’re free to grant the rights to social bookmarking entities to see your data and analyse it.

Now PEP also allows people to share data or keep it private. The neat thing is that we can share it by default with anyone who wants it from our roster. Given that these are the people who are - probably - our friends, that means in turn that this is probably a good mapping. Moreover, this is more powerful than ACAP can provide, because it’s allowing data sharing beyond people on the same server, without forcing such data to be simply public.

In a PEP-replaces-ACAP world, then, your browser’s bookmark and your “social bookmarks” are one and the same thing. You can choose to share your bookmarks with anyone you choose, including - most interestingly - social bookmark aggregators, one or more of them, which will take your data, analyse it, and provide aggregations and statistics.

No more closed data silos, just aggregation and statistical services - of course essentially the same privacy issues, but you could at least change from one to another easily, even if the old aggregator could keep a snapshot of your data if it wasn’t playing nicely.

Dave Cridland: Replacing ACAP - Personal Configuration

dwd — Fri, 25 Apr 2008 13:40:31 +0000

I’ve always maintained that I’m not wed to ACAP. I don’t like ACAP because I wrote a server, I like ACAP because it stops me swearing at my client when I switch from desktop to laptop. (Which I do a lot). That’s why I started using it, and that’s why I wrote a server. (And a client library. And a client that used it. And so on.)

In terms of investment of time, I’ve put a lot into ACAP. So you’d be forgiven for thinking that I’d be loathe to chuck it all away. But the truth of the matter is that, while I rather like a lot of the design of ACAP, the thing I particularly like about it is what it does. It means that when I configure my email client, I’m configuring my email client. Not “my copy of Polymer on my desktop”, but “my email client”. In principle, whichever ACAP-supporting email client I choose to use, wherever I choose to use it.

The thing I particularly *don’t* like about it is that nobody, and no clients, use it - I still run one of four or five full ACAP servers on the planet, and I wrote all of them. (Unless someone’s going to tell me they run Cyrus smlACAPd. In which case I shall be impressed). Only Polymer does a full job of ACAP, although actually, most ACAP users are Mulberry users - Mulberry doesn’t do standard configuration, so the magical interop is lost. A shame - I don’t think Polymer is perfect for everyone all the time, but email clients have to try to break the Barnum law, and please all the people all the time, and that’s why, I think, all of them suck.

But what would be great is if there were a protocol that did essentially the same thing as ACAP, but did so in a way that somehow avoided The Great Bootstrap Problem, so that it was relatively easy to get to a point where all clients supported it, and so you could decide to use, say, Thunderbird for reading your mail, and Polymer for organizing it, and they’d both use the same accounts, colour your messages the same, use the same flags, etc.

And luckily, there is. Sort of.

PEP, core of the rich presence support in XMPP, provides the basics of what’s needed. It means that every email client, web browser, etc would all become an XMPP client (although not an IM client), which would be quite amusing, but they’d pick up bookmarks, IMAP configurations, etc all from PEP.

To be fair, not everything is there, but PEP does look like a pretty good base. Things missing:

Offline support
Better synchronization
Microformats for data
Other stuff I haven’t thought of

None of these are as critical, or as hard, as you might think, though. Offline support and better sync basically are accomplished by the same mechanism that allows client-side caching to improve bandwidth, which we need for mobile rich presence anyway.

Microformats are pretty easy to define, because we have the starting point of the ACAP dataset class definitions, which were arrived at by sufficient people thinking about not only how email clients (for example) are configured, but how they ought to be, too. And since dataset-classes map quite simply onto XML, this is nice and easy.

I suppose, given a nice website in pastel blue with rounded corners and bright green/orange highlights, that we could probably solve this in a couple of weeks. Anyone fancy tackling it?

Ignite Realtime Blog: Open-Even-More-Fire 3.5.1 Released!

jadestorm — Fri, 25 Apr 2008 02:22:16 +0000

We are pleased to announce the release of Openfire 3.5.1, now with even more openness! This release represents the first stage of the Enterprise plugin split into open source plugins. We're very excited to be able to provide these to everyone for free, and seeing what the community does with them, both in terms of contributed code and use case scenarios. So lets talk about some specifics.

New Plugins!

Monitoring: Adds support for server statistics and chat archiving and reports.
Fastpath: Support for managed queued chat requests, such as a support team might use.

These are the first two pieces of the open sourced Enterprise plugin. Client management is coming very soon, as is clustering. SparkWeb will also be released tomorrow as a separate product. So you might be wondering, hey, why is there an Openfire Enterprise 3.5.1? Well, due to the lack of all of the plugins being available right now, we've provide 3.5.1 for existing enterprise customers to make use of. It includes some important clustering fixes though! (as will the clustering plugin when it is release)

Important, Seriously, Pay Attention, Read This

If you install the Monitoring and/or Fastpath plugin, make absolute sure that you read the readme first! There are included instructions for how to migrate your database from the Enterprise plugin to the new plugin database tables. If you have ever run the Enterprise plugin or the old Fastpath plugin before it was integrated with Enterprise, make sure you don't forget this or you will be unhappy!

Big Connection Manager Improvements

The connection managers have been updated to bring HTTP binding up to date and a couple of library upgrades that include a number of improvements. It is important to note though that the conf/manager.xml file has been updated and you will need to update yours as well. The new http binding section that you will need to add is described here.

Ok Fine, Where Do I Get It?

You can download Openfire 3.5.1 here.
You can see the entire changelog here.
You can view the documentation for 3.5.1 here.
Plugins can be downloaded from the admin console or here.

Artur Hefczyc: Minichat - Web client on Tigase website

kobit — Wed, 23 Apr 2008 22:00:24 +0000

We have just installed the Minichat - simple web client on the Tigase website. It allows anybody who visits the website to chat with "admin" - me ;-). No user name, no password is required. Just click to connect to the XMPP/Jabber server and you can start conversation.

This is the AJAX application created using GWT (Google Web Toolkit). It connects to the XMPP server via Bosh and signs in using SASL Anonymous.

This is our first version of the client and we are going to move things further to add fully functional AJAX client to Tigase project. The AJAX client and the XMPP library written in GWT is also available under GPLv3 license and will be released publicly very soon.

Please have a look, experiment and let us know what you think...

Coccinella: Yearly Overview #1

sander — Wed, 23 Apr 2008 18:23:53 +0000

Almost one year ago, the new Coccinella website was launched (1). Since then you were provided with nearly 6 Coccinella releases: 0.96.0, 0.96.2, 0.96.4, 0.96.4.1, and 0.96.6 (2) of which 2 were synchronised releases. It was a productive year.

The website itself was also a success with increasing numbers of people discovering Coccinella and XMPP. However, not everything went as fluently. In the summer of 2007 you could not access the website during nearly a whole week (3) due to major troubles with our former hosting provider (VistaPages). Read more in our VistaPages Review (summary: VistaPages sucks).

Speaking of reviews Coccinella also was reviewed by a popular Czech website (4), Lifehacker.com (5), and others. Luckily, and obviously, we came much better out of these reviews than VistaPages came out of ours.

PS: A new Coccinella release is in the pipelines. So it's time for you to download the daily breakfast build and start bug hunting!

Ignite Realtime Blog: SparkWeb Open Source

DavidSmith — Wed, 23 Apr 2008 00:37:59 +0000

Earlier today I exported our svn repository for SparkWeb and committed the intial import to the new open source repository! Instructions for getting and building the source are available. Getting and Building SparkWeb. A chat room for discussion of SparkWeb development can be found at sparkweb@conference.igniterealtime.org. I'm looking forward to seeing what the community can do!

Kevin Smith: Summer of Code ‘08

Kev — Tue, 22 Apr 2008 21:15:53 +0000

As summer 2008 approaches, students have been busy applying, the XSF has been busy scoring applications, and mentors have been busy preparing. It’s time again for Google’s Summer of code, a scheme to pay students to work on open source code for the summer, and hopefully for them to continue contributing afterwards. This year has [...]

Extended Conversation: Google Summer of Code 2008

stpeter — Mon, 21 Apr 2008 19:39:19 +0000

For the fourth year in a row, the XMPP Standards Foundation is participating in the Google Summer of Code. Our projects for 2008 are as follows:

Mateusz Biliński — Plug-in system for Gajim (Mentor: Yann LeBoulanger)
Adam Czachorowski — Metacontacts support and various roster
improvements for Psi (Mentor: Remko Tronçon)
Tomas Karasek — Bidirectional-streams Over Synchronous HTTP (XEP-0124) support in Gajim Jabber client (Mentor: Yann LeBoulanger)
Aleksey Palazchenko — Psi: Message history (Mentor: Kevin Smith)
Safa Sofuoğlu — Updating and Improving BOSH Support of Openfire (Mentor: Gaston Dombiak)
Paweł Wiejacha — Themable WebKit-based Chat Dialogs (Mentor: Kevin Smith)

Here’s to another successful summer of coding!

Alexander Gnauck: agsXMPP and Silverlight

gnauck — Sat, 19 Apr 2008 10:45:03 +0000

agsXMPP supports lots of platforms which currently include Windows, Linux (Mono) and Windows-Mobile. And the next version I am currently working on will also support Microsoft Silverlight.

This opens new possibilities to xmpp web development.

I attached a small screenshot which shows agsXMPP for SIlverlight in action. Follow this blog for updates.

Dave Cridland: The Famous XMPP and IMAP specialist

dwd — Thu, 17 Apr 2008 21:04:31 +0000

Yeah, bugger off, James - you’re apparently the only person to use that phrase, according to Google.

But thanks for using your twitter stalkers to find me Library Thing, even if it means I actually owe Bill Thompson a thank-you, which is a strange position I never thought I’d be in…