Hey Andrew - thanks for the reply and no worries on the time!
Regarding IPFS, I’ve been looking at using IPLD for persisting graph structure, but definitely just writing an IPFS CID onto the Fluree ledger gives you provenance, and then using a combination of smart-functions and i.e. Lit, we get full access control - which I grant is not always something you want for shared semantic data, lol, but sometimes is.
I think the biggest win is that by using a RDF database underneath Logseq, you get all that great semantic querying from the graph engine itself. People have done some interesting things to extend the semantics of GraphQL, which can be a lot more accessible than people having to learn SPARQL, if they don’t need all of its features. That has the benefit of making Logseq data objects accessible using one of the most popular API styles on the web, easily consumable by things like React apps.
But I think your basic notion of putting blobby content into IPFS and referencing it in the graph is probably the best strategy for that aspect. I’m using that approach elsewhere and it seems to be a good fit.