A few notes on what a lobber client for a mobile device could look like.
A Lobber storage-node consists of a BT client and a control plane that talks to the lobber service. This model could work for a mobile client too but the BT client may need to be stripped down to support fewer features. BT is well adapted to a mobile usage pattern where the device changes network connectivity often. Certain aspects of BT (i.e running multiple TCP connections in parallel) will need to be turned off on certain types of networks (eg EDGE) but this should not present a problem.
The control plane (PUSH+ATOM/RSS+REST) should not present a problem for a mobile device but certain mobile devices have access to native notification services that could work even better (eg iPhone notifications). The size of each notification message is very small (a torrent info-hash) which should not present a problem for any notification technology.
The limited storage available to most mobile devices means that the user needs to have control over which datasets to download. The reference storage-node implementation will download all subscribed datasets. On a mobile device it may be desirable to apply a size-based policy to determine which to download. A possible extension could be to allow the user to direct a stationary or cloud service (which would just be another storage node) to download the dataset instead of the mobile device.
Lobber allows users to share directed links to datasets to users. This would integrate very nicely in a mobile device where the buddy/contact list would be used to find the recipient of a "share link" which could be send over notification, SMS or email