A feature I would love

I have a problem and it seems so far no one has come up with a good solution for it: Many web 2.0 services come in the form of a stream of items most of which I would like to see exactly once. Examples are RSS feeds, podcasts (here seeing could as well mean synching with the ipod), mail (in some respect), twitter, usenet, etc.

If I access them with a single program on a single device, this program keeps track if what I have seen so far and (at least in default mode) only presents me the new stuff. Excellent. Only that I use more than one device to access these services: I have my desktop, a laptop at home, a netbook on the road or in meetings and seminars, sometimes I even use other peoples devices.

What I want is a way that all these different devices have a possibility to share the information which items I have already seen. C'mon, this can't be that hard to implement. And I am sure I am not the only person with more than one computer.

The problem is most pronounced with RSS feeds. As mentioned some time ago, I used Liferea read blogs. This is where I first noted I would like to share the "read it flag" info between different computers. I thought that program might have a file like .newsrc in the old days where it records for each feed which posts have been seen before. Then it shouldn't be too hard to put this under subversion control or write a small perl script to merge those files. Except that information is not kept in a simple format. Instead, liferea keeps the downloaded content in some xml file and that file has flags. In order to merge the state of read items one would have to download them as does liferea and then sync the flags. Why do they have to mix the content and the meta information, why why why? I even looked at liferea's source but I couldn't see the possibility of an easy patch.

I "solved" this by giving up on liferea and moving to Google Reader instead. Since there, feeds are not read locally but on a single server, there is no problem with sharing state information. Only that I am not very comfortable with letting google know which feeds I like. And maybe at some point the GUI gets on my nerves or whatever. I don't think this is an ideal solution.

For more or less the same reason I use a similar approach to mail: All my different addresses' mail ends up in the inbox of my desktop computer (except for mailing lists etc which are sorted in appropriate alternative inboxes but on the same computer). In case I want to read mail on a different computer I ssh to the desktop. Except that it is not directly connected to the net. I first have to ssh to LMU's firewall. But that computer still cannot see my desktop. So from there I ssh to some PC in the Arnold Sommerfeld Center. From where eventually I can ssh to my computer (although only with a numeric ip since my computer is not important enough to get a DNS entry. And so far I was too lazy to hook it up to dyndns. But over recent months dhcp was kind enough to always give me the same ip and thus this chain of computers is supported by appropriate entires in .ssh/config . But I am digressing.

What I wanted to say about mail is not so much I don't want to use IMAP and one central mail server. It is also about saved mail in local folders. Those I have to many and too much volume to put them all in IMAP. At least on publicly accessible computers. And on my desktop (where I can install whatever I want) it would be of no use since this is always two hops away from the rest of the internet, at least for ingoing connections. OK, I could set up ssh tunnels. But those usually do not work reliably over longer times (we are talking at least weeks, I want to have reliable access to my mail even if I travel for longer time).

But again, the main problem seems to be sharing the 'read it' information.

One more incarnation of the same problem: ITunes does of course not exist for Linux. So I manage my ipod with Amarok. I would like to use my different computers to upload recent podcasts to the ipod but have not found a way to do this consistently.