Happy to work on B(and A?) as it’s already in our roadmap
For context I’m working on a runtime that runs ink-like programs(VOS) in a server environment(and the browser, embedded hardware and maybe JAM?), the runtime exposes a simple HTTP/WS RPC API used to call functions of any of the installed WASI(wink) programs.
The reason A and B could tackled simultaneously is that our governance API will be another wink program that simply interacts with a virtual filesystem(hidden away by the wink macro), I plan to use matrix as a decentralized eventually-consistent encrypted storage exposed to wink programs as a filesystem(allows DAOs and their members to share private “files”/state), git can be another(even easier to implement) virtual filesystem.
Hey all - this is something that came up early on for us on the Moonbeam side. We went with the Github approach and the Foundation hosts a specific github repository for it.
However, it’s a bit of a pain to manage. As has been pointed out above, the UX is not wonderful.
Separately, we’re looking at integrating the Storage Hub project into Moonbeam in order to provide immutable, verifiable storage.
We’ll be focused primarily on AI use cases but we’re also interested broadly in problems of this nature. APIs will be available which should make it relatively straightforward to integrate other systems to try and streamline UX.
However, we’re just getting started so it will probably be toward the end of 2025 when storage features are live Moonbeam so perhaps this particular use case can’t wait until then. Regardless, I thought I would mention it all the same as Moonbeam’s storage capabilities could serve as a general purpose solution for the broader Polkadot ecosystem…
