Evan (@emschwartz) came up with this idea we sometimes refer to as Fishchain. The idea is that you can request a packet of data by broadcasting a payment where the condition is the hash of that data.
Not sure if this new or not, but I just noticed that the Fishchain idea works not just for message retrieval bounties as stated above, but message delivery bounties as well.
Imagine A wants to deliver a message m to B, but doesn't have a direct connection. C has a way to talk to both A and B, but doesn't want to relay a message for free. Neither A nor B trust C.
A could tell C: My buddy, B, will pay you 5 cents if you deliver my message to her.
C thinks that that is a fair price, so she first gets A to sign the hash of the message H(m). She then contacts B saying that she has a message for her whose hash is H(m) and presents A's signature over H(m). B promptly creates a transfer to C using H(m) as the condition.
C fulfills the payment and B receives the message as a result.
The obvious attack is that A could try to cause C to leak information to B in her request for payment. For instance, A might provide B's address as a URI, but secretly include the actual message in the URI. When C requests to be paid, B learns this "actual message" and no longer has any interest in paying C. This would only work for small messages which are small enough to be hidden in a URI, hash or signature. It may be possible to eliminate most of the venues for information leakage through commitment schemes. E.g. if A sends m to C and then A and C exchange random values and H(m) is seeded with the XOR of these random values, then C can be confident that H(m) is indistinguishable from random data and B does not learn anything about the message from looking at H(m).
Similarly, it may be possible for A to prove that B's identity has existed for a long time, e.g. by using a Ripple address as the identifier for B. If B's identifier predates the information A is wanting to send to B, then A cannot include this information in the identifier. A and B could still pregenerate multiple identifiers and map them to different messages, however note that C would likely not try to claim a bounty from B if it recognizes B's identity as someone who has not paid out before. This means that A and B would have to keep creating new identities and identities aren't free, the cost of this approach will quickly exceed the cost of simply paying C.