> you want to have some sort of always-on service to store/buffer your messages.
An instance running on a NAS or similar device at home to provide that backlog capability should do the job, no?
I don't know if ring supports that, but the concept is simple and at least as old as bouncers for IRC.
Well, buffering that kind of stuff, is one of the more complex parts of an XMPP server (XEP-0013, XEP-0160, XEP-0280, XEP-0313). AFAIK IRC bouncers tunnel all the traffic and are not mobile aware. So to reduce battery usage, XMPP has some functionality within the protocol (XEP-0198, XEP-0352). So after optimizing your bouncer approach you will probably come up with what XMPP does (more or less, maybe with a few minor exceptions).
XMPP also knows how to do P2P connections (that is what 'jingle' is actually about, not just calls), but I think that the problems of P2P are actually the reason why there are still so many problems with XMPP calls. I mean if you want to build P2P that 'just-works' you will need STUN/TURN servers and while XMPP servers like ejabberd bring them with a standard installation, TURN servers require a lot of ressources (bandwith). At the same time the others parts of a XMPP server are very lightweight so that the TURN server causes scaling issues.
Well, if we take the people who would install ring in the first place and have some tiny server at home that can actually install software I would say the chances go up significantly.
It could use some streamlining, e.g. get it into package managers for whatever distro is running on it, automatic pairing (multicast on the local network), maybe detection of compatible devices.
UX is basically a separate set of problems you have to solve on top of making it work technically.
An instance running on a NAS or similar device at home to provide that backlog capability should do the job, no? I don't know if ring supports that, but the concept is simple and at least as old as bouncers for IRC.