To be a Tahoe-LAFS "target" you do need to be running their code on the server side ... and it's python.
We make a point to keep our environment as simple and sanitized as possible, which implies having no interpretors, so at this time you can't use rsync.net as a Tahoe-LAFS target.
BUT! We've always been very excited about Tahoe-LAFS and are well acquainted with Zooko and his team, etc., and so we are experimenting with a frozen[1] implementation of it that we can place into our environment as a binary executable[2].
The two solutions aren't really that related, as Tahoe-LAFS (sort of) implies that rsync.net would be just one of many (perhaps ten) remote containers out there, whereas this solution is targeted to just one remote host... but since you asked ...
[1] http://cx-freeze.sourceforge.net/
[2] We already do this with rdiff-backup, which is how we are able to support that ...
Of course, you could just use Tahoe-lafs to store everything on one or two nodes when they're reliable and durable, but then why not just use gpg or encfs, which don't require custom clients or gateway/introducer nodes?
http://git-annex.branchable.com/devblog/day_22__gcrypt_on_rs...
http://git-annex.branchable.com/forum/making_good_use_of_my_...