Anytime a user adds content an IPFS daemon, provide messages are sent out to the closest peers containing the cid of the newly added content. The peers will store the record, the cid of the content, and who told them about it. The peers will not request and download the content. However, you could set this up on your own.

It's not a configuration option though. You would either have to build up your own system using the ipfs libraries, or monitor the events from a daemon.

Unfortunately there is a bug that is not allowing the information required to be logged correctly in the events, so the actual cid of the content is not exposed.

If it where, you could look for the `handleAddProvider` or `handleGetProvider` operation through the event logs (`ipfs log tail`) and then inspect the object (`ipfs object stat`) to determine if you wanted to pin it.

> Ideally with some kind of mechanism to store poorly seeded data.

This would be a little more difficult, but you could attempt to query the dht to determine how many peers are already providers for the data (`ipfs dht findprovs`).