We have an use case where we want to store a lot of data on very modest devices for various reasons. We make sure to create the data in such a way that it is sufficiently chunky. Our data is json data stored as dag objects, with a lot of potential for compression (your typical json data I guess).
I am tempted to just compress the data before storing and storing a compressed blob, but that would lose many of the advantages of ipld dag objects, namely the addressability of their content.
I think a much better solution would be to have compression at a file store and transport layer level. E.g. compress individual blocks in the file store once they exceed a certain size. Then communication between nodes via bitswap etc. could use this compressed data as well, provided that both sides understand the compression. Similar to content encoding negotiation in http.
The hash of the data would be computed before compression, so that the hash remains stable when switching compression formats and options.
I think for the data that is typically stored in ipfs, this could increase both storage efficiency and network bandwidth usage by a large factor. There would probably have to be a noop compression option for data that is already compressed, such as images or videos. But it should be pretty easy and cheap to detect if compression provides benefit when adding dag objects.
Is there any work ongoing on this, or do I have to resort to compressing individual blocks myself and lose the benefits of interplanetary linked data?