What I mean is that having an ipfs pubsub interface is not something that IPFS needs per se for the functioning of the filesystem. Sure IPFS might use pubsub internally but other than that ipfs pubsub is provided to the outside as a goodie more than a core feature, while the pubsub protocol in libp2p is pretty mature itself.
I understand that pubsub is experimental in IPFS, but suggesting to create a libp2p app to use the pubsub functionality kinda makes developing anything with IPFS and pubsub orders of magnitude more complicated.
Yes and no… it depends on the requirements. If the current functionality does not allow you to develop such app at all then it’s worse than complex. The IPFS and libp2p ecosystem provide the building blocks to build end-user apps which are optimized for whatever they need to be. We cannot optimize go-ipfs for every possible libp2p use case, but the pieces that make it are very customizable.
go-ipfs can be used as a library: https://github.com/ipfs/go-ipfs/tree/master/docs/examples/go-ipfs-as-a-library . I also wrote ipfs-lite (GitHub - hsanjuan/ipfs-lite: IPFS-Lite is an embeddable, lightweight IPFS-network peer for IPLD applications), so that I could build something similar to what you are describing. Textile provides some extra building blocks on top of IPFS that can be very useful. So does OrbitDB etc.
I wish things were different but there are 1000x ways of doing mix+match between p2p blocks and their configs, and go-ipfs as a program itself is focused in providing a distributed data storage layer rather than in offering a fully featured API to libp2p functionality, even though it tries to give a peek through experimental features etc.