On a sidenote, on S60 there is a nice program which allows one to prioritize connections when multiple are available and decide to disconnect either one if one with higher priority is available. This is useful for corporate networks, but also when roaming and able to access WiFi hotspots. I have not tried this with something like Devicescape yet though.

Maybe you want the feader to decide what you (probably) like, or allow the user to create such filters. If the user has multiple feeds the need for this increases. Its a power user feature so to speak.

The dependancy on the browser woud exist because Web 2.0/AJAX is the current hype, but also the most used platform. Such platforms integrate well and add tons of services. Which device doesn't have a browser? That is what Yahoo/Live/Google/Ovi is all about. (Although the possibility to jump off the platform doesn't seem to be important to users yet. I'd say, if you have guts and believe in your platform, you allow the user this easily because you know they won't leave anyway. It is a bit like believing in quality of your open source code.) That first. Second, you can easily make this in PHP without some kind of new protocol. You just allow the user to manage their RSS feeds with advanced filtering. I would say allow them to provide feedback or suggestions for filters as well.

One could allow the user to grab the output on browser or RSS. But then this isn't synced either. Once you're leaving the browser paradigm (geeks...) it isn't a good abstraction layer.

I know this issue from other protocols as well. SIP, for example. You can phone from any account with which you logged in, but the last one who logged in will receive the phone call. In the console IRC client Irssi one can run a module called Irssi-proxy. A user can connect with any IRC client (from any platform) to this proxy, and once connected, the user can read/write to the connection with the server from both ways. I like this model. However, it still doesn't actually by definition provide offline synchronisation because often these models lack proper history support.

Works like this: Server <-> Daemon <-> Clients. The server or content provider is what we have now, they speak a protocol and standard (e.g. RSS over HTTP). The daemon understands these protocols and abstracts it, does some things with it e.g. blacklist, whitelist, greylist (tagging/marking) filtering/prioritising. Think of it as a firewall. It also knows what is read and not read and allows to map (this is part of the filtering; could be more advanced). Then the clients connect and are always synced. End result? Something like IMAP. The provider (e.g. IMAP service provider) can run this daemon, even as part of the protocol or service, but also customer/user can run their own. Corporate users or users who care about privacy might prefer the latter. If you take something like voicemail, which is inherently expensive and inefficient while synchronisation isn't important, you might not want to give the customer this power for financial reasons but that is a different story.