Time to solve the assistant's cloud notification problem. This is really the last big road-bump to making it be able to sync computers across the big, bad internet.
So, IRC still seems a possibility, but I'm going to try XMPP first. Since Google Talk uses XMPP, it should be easy for users to get an account, and it's also easy to run your own XMPP server.
Played around with the Haskell XMPP library. Clint helpfully showed me an example of a simple client, which helped cut through that library's thicket of data types. In short order I had some clients that were able to see each other connecting to my personal XMPP server. On to some design..
I want to avoid user-visible messages. (dvcs-autosync also uses XMPP, but I checked the code and it seems to send user-visible messages, so I diverge from its lead here.) This seems very possible, only a matter of finding the right way to use the protocol, or an appropriate and widely deployed extension. The only message I need to send with XMPP, really, is "I have pushed to our git repo". One bit of data would do; being able to send a UUID of the repo that did the update would be nice.
I'd also like to broadcast my notification to a user's buddies. dvcs-autosync sends only self-messages, but that requires every node have the same XMPP account configured. While I want to be able to run in that mode, I also want to support pairs of users who have their own XMPP accounts, that are buddied up in XMPP.
To add to the fun, the assistant's use of XMPP should not make that XMPP account appear active to its buddies. Users should not need a dedicated XMPP account for git-annex, and always seeming to be available when git-annex is running would not be nice.
The first method I'm trying out is to encode the notification data inside a XMPP presence broadcast. This should meet all three requirements. The plan is two send two presence messages, the first marks the client as available, and the second as unavailable again. The "id" attribute will be set to some value generated by the assistant. That attribute is allowed on presence messages, and servers are required to preserve it while the client is connected. (I'd only send unavailable messages, but while that worked when I tested it using the prosody server, with google talk, repeated unavailable messages were suppressed. Also, google talk does not preserve the "id" attribute of unavailable presence messages.)
If this presence hackery doesn't work out, I could try XEP-0163: Personal Eventing Protocol. But I like not relying on any extensions.
PEP and pubsub are really widely used. You will have a hard time finding a server that doesn't support it.
Also note XMPPs ability to send status to only selected buddies and even resources. You can globally appear as offline while sending availability to myownjid@example.com/thatannexthere.
I'm using http://hackage.haskell.org/package/network-protocol-xmpp
While its author thinks "its current design (session in an XMPP monad) is a failed mistake", I've found it pretty good. Aside from the segfault problem, which we got fixed today.