#1281 new enhancement

implement a notification mechanism, e.g. for accounting messages

Reported by: davidsarah Owned by: somebody
Priority: major Milestone: undecided
Component: code Version: 1.8.1
Keywords: notification extensibility Cc:
Launchpad Bug:

Description

Brian Warner wrote:

* maybe broadcast channel of activity

  • daily, maybe at first hourly digest of aggregate usage
    • "Bob uploaded 62MB of data". "Alice downloaded 146MB of data"
    • "Bob is currently using 3.5GB of storage space"
    • "Alice is currently hosting 4.2GB of shares and has 0.8GB free"
  • also include new-server, new-client events
    • "Carol joined the grid, offering 3.0GB of storage space"
    • "Dave invited Edgar to join the grid"
  • and server-admin actions
    • "Carol froze Bob's shares: dude, you're using too much"
    • "David deleted Alice's shares: you unfriended me on facebook so I'm deleting all your data"
  • also generalized chat
    • "Bob says: anyone up for pizza tonight?"

Rather than implementing a new broadcast channel, we should co-opt existing channels on which users are already chatting.

Define an INotificationChannel interface that can send messages (UTF-8 strings) for a given protocol. File separate Trac tickets to implement a plugin for each protocol, e.g.:

Protocol Possible Python library
IRC http://python-irclib.sourceforge.net/
XMPP http://xmpppy.sourceforge.net/
Twitter API https://github.com/joshthecoder/tweepy
Facebook API https://code.google.com/p/pyfacebook/
SMTP http://docs.python.org/library/email and http://docs.python.org/library/smtplib

Making each channel implementation a plugin is essential because we would otherwise be adding dependencies on these or similar libraries, and we already have too many dependencies. There can be multiple instances of a given plugin with different destinations and account credentials.

To create a plugin instance, we can read the plugin name and parameters from a config file (in private/ since it may contain passwords), and instantiate a class chosen according to that name with a dict containing the parameters.

The messages will eventually need to be localized, although nothing else in Tahoe is localized (#841) so we can probably defer that.

Attachments (1)

chat.diff (4.8 KB) - added by warner at 2010-12-25T00:45:30Z.
zooko and I threw some code together at pycon2009, might be a starting point

Download all attachments as: .zip

Change History (3)

comment:1 Changed at 2010-12-21T03:23:07Z by davidsarah

  • Keywords extensibility added

See also #404 about plugins.

comment:2 Changed at 2010-12-25T00:04:48Z by warner

Hm. I like the idea of using existing channels, but we should be careful to retain the main Ostrom principle: all participants should be confident that everybody is seeing these messages, so that everyone feels like they're participating. And we should think about the way the messages are presented too: they should lead the grid members to feel like they're part of a club, or all sitting in the same room, making decisions about a common resource. It's a subtle social thing, and I don't know what's best to do, but we need to think about perception and "voice" or "register" (as used in Danny O'Brien's essay on secrecy) and the sense of "the medium is the message", in addition to the strictly technical aspects.

I wonder if highly outward-facing channels (like Twitter or Facebook) might work against this. If you know that all the messages you type into your tahoe grid channel show up on a twitter feed, and external non-members start commenting on them, you'll start to think of that external world as your audience, which may interfere with the real purpose of the channel (to manage the scare common resource of the grid).

You kind of want something closely tied to your use of the grid. If Tahoe had a regular GUI application, like a file browser or a place to drag-and-drop uploads into, you'd want it to appear in a corner of that window, like a built-in chat room (which I seem to recall was a feature of Mnet). So that every time you use Tahoe, you see the effects of your use in this channel, and by seeing everyone else's effects in the channel, you get conditioned to think about your co-grid-managers seeing your effects, and thinking things like "huh, I wonder if anyone will be upset if I upload this 500GB file" and *knowing* the people that could be impacted by that.

But we don't have a GUI app like that, or at least there are lots of ways to do things to the grid that don't go through a single tool, so we need some other ideas. Having something on the wui Welcome page is a start, but that's not where most people "hang out" when using the WUI. Maybe adding something to the corner of each directory page might help raise visibility, but I'm not sure I like the idea of making those pages so.. dynamic. Maybe we need to find a way to make the Welcome page more "sticky".. add enough interesting and fast-changing data that people will tend to leave it open a lot.

Ooh! I know, let's add that platform-shooter "try to destroy the shares before the evil Repairer replaces them for you" game we always talked about, to the Welcome page. That'd be awesome :).

So anyways, yeah, if there is an external broadcast technology that all members of the grid can agree upon *and will associate with their use of the grid*, then that may be a lot more effective than some extra text on a web page that nobody looks at anyways. But it's got to be "emotionally connected" to the grid somehow.

Changed at 2010-12-25T00:45:30Z by warner

zooko and I threw some code together at pycon2009, might be a starting point

Note: See TracTickets for help on using tickets.