Something like this would be really cool, because it leads towards private-groups... but I'm not sure wether that's the best way to implement them.

I am pretty sure though, that the next step is adding support for passing a decryption key link along with a link to an encrypted message... probably want to do that the same as secret blobs: ssbc/ssb-ref#15 (and other issues starting out from there)

And also, figuring out exactly what the format for encrypted messages will be. That's the part with the highest technical barrier. hmm.

My goal was actually to start prototyping a blob content representation (like "content": "&sbBmsB7XWvmIzkBzreYcuzPpLtpeCMDIs6n/OJGSC1U=.sha256") rather than enc/dec, but from reading through the SSB code my intuition is that this may be like private messages, which need to be unboxed before they can be indexed. The problem is that multiblob's methods seem to be asynchronous will callbacks, but flumelog-offset expects a synchronous function without an option of using a callback.

I'm sure there are more high-performance ways of implementing off-chain messages, but I was hoping I'd be able to prototype it and get a better feel for the ergonomics (and deep-dive some SSB code).

Is there a better way of going about this?

FWIW, here's my current implementation, which works using fs.readFileSync():

ssbc/ssb-db@400d561#diff-e91c0d50d79d0bc8fced372dd077f906R72

It's basically just a hacky and synchronous implementation of multiblob.get(), but I wanted to reach out for feedback if there's a simpler way to prototype this.