Jabber/XMPP support in MoinMoin

This page describes the idea behind and progress on implementation of Jabber/XMPP support for MoinMoin, being developed as a GoogleSoc2007 project by KarolNowak. You can read the original application information here.

Setting up

See here HelpOnNotification.

Planned features

This is the original list of proposed features. Feel free to add your own ideas here as comments.

• Notification support - notification with jabber messages about page changes for subscribed users
• Limited editing support:

  • Quick revert from jabber client to make fighting with spam or accidental changes more enjoyable.

  • Easy page append (possibly using a predefined template), to foster creation of discussion (Talk:) pages.

Since jabber supports various so-called "transports" to other IM networks, it should be fairly easy to extend the above functionality to other means of communication.

This functionality is going to be implemented in a stand-alone daemon (possibly automatically launched along with Moin). A simple notification protocol for wiki-daemon communication will be developed (or an existing one adopted). There are quite a few reasons that make me believe that it is the right way to do it:

• On large Wikis notifying all subscribed users can take a lot of time, causing annoying lag. Wiki can work faster when communication is being done in a separate process. This is even more important in case of encrypted connections.
• Notification could be done (?) in threads, but this would limit possibilities for user interaction. Jabber bot can process incoming requests and perform various actions on wiki. Note that authorization done by the jabber server should be sufficient to make it fairly secure. Even more on the security ground could be achieved with added GPG support.

Email change notification should probably be moved out to such a daemon as well. --FredDrake

Development

This section summarises development done so far (completion status for planned milestones).

XMLRPC communication details

Method names sent from jabber bot to a wiki instance will, generally, be the same as specified in XmlRpcToWiki.

ACL discussion

With the new event handling and notification system, an issue with access control emerges. Notifications (via Jabber/XMPP) are meant to help maintaining a wiki instance, thus they will provide a information about various changes and processes. Let's name a few:

• User creation
• Page modification
• Security issues (sudden surge in number of failed login attempts?)
• Server issues (strange errors happening?)

It's obvious, that some of them are meant for public, and some only for selected users and administrators. What's important from ACL point of view:

• Each of these classes of events consists of a number of specific events
• There will be many "specific events" in these classes
• It should be possible to forbid users/groups from receiving notifications about certain events

A question of granularity: should access control be applied to individual events (PageChanged, SubscribedToPage, UserCreated, etc), or to the whole classes? In the second case, it will be easy to add a few actions controlled by ACLs, using currently available syntax.

In the first case, however, listing all events one is interested in may be troublesome because of number of events one may be interested in, no?

The question is: which solution is preferred?

(Note that subscribing to events, user-side, is a separate issue)

History

Week-by-week log of activities related to this project.

• Week 1 (post-acceptance)
  • Studying the code base, setting up the wiki page, blog, getting to know people, etc...
• Week 2
  • Described the proposed architecture and submitted it for review.
• Week 3
  • Did some reading of XMPP RFCs "just in case", but generally spent this time away due to a holiday week in Poland.
• Week 4
  • Little done. Extended XMLRPC section.
• Week 1 (May 28th - June 4th)

  • Did some basic refactoring of notification code of MoinMoin - it's now event-based and supports simple plugins. Jabber bot is in a basic state, but works - sends notifications, honors contacts' presence information and doesn't send messages if it's DnD. Wiki communicates with the bot using XML RPC.

• Week 2 (June 5th - 12th)

  • Further improvements to the jabber bot. It handles it's contacts (albeit its just a basic support) and respects DnD status (queues messages for later delivery). New events are being reported by the wiki. Some code fixes (mostly PEP-8 and imports) as I learn the ways of Python the hard way.

• Week 3 (June 13 - 20th)

  • Bot -> Wiki XML RPC communication and some related bugfixing. Auth token can now be obtained using user's JID. GetPage, GetPageHTML, GetPageList and GetPageInfo commands implemented. Sample configs for the jabber bot and wiki (notification options). Users can select events they want to be notified about.

• Week 4 (June 20th - 27th)
  • Event handlers now return values in a generic response class. Added some unit tests. Stub logging using prints replaced with stdlib logging facilities. Users can select if they want to receive notifications via jabber, email or both.
• Week 5 (June 28th - July 6th)
  • Almost nothing done besides tracking progress on IRC and merging changes to my branch - exams and other life difficulties...
• Week 6 (July 7th - 14th)
  • Email notification about account creation. Email notification about new attachments.
• Week 7 (July 14th - 21th)
  • i18n is finally usable with one initial translation. Debugged a few pyxmpp related issues, filled bug reports, proposed patches.
• Week 8 (July 22nd - 29th)
  • Out of Band Data implementation for the bot. Some internal changes and cleanups: argument passing, event names, i18n of messages sent by the xmlrpc thread.
• Week 9 (July 30th - August 6th)
  • Some bugfixing. First unit tests for the xmpp bot. Fixed test_sourcecode.py.
• Week 10 (August 7th - August 13th)
  • Some bug fixing of Data Forms. Implemented search command (text and data forms versions). Improve service discovery and use OOB only when it's known to be supported by the client. Make it so the bot terminates gracefully on keyboard interrupt. Implemented page revert command.
• Week 11 (August 14th - August 20th: FINAL!)
  • Documented CHANGES. Page change notification, revert, search and detailed page information working with data forms. Bug fixing along the way.

Related pages

• IrcEventSystem

• EventSystem