Yeah, except Hypercore or SSB sync'ed data types are not as flexible as the relational model.
I'm building something like this, with one extra requirement: permissionless / trustless p2p operation. It works in the browser, here's the README:
I'm building something like this, with one extra requirement: permissionless / trustless p2p operation. It works in the browser, here's the README:
Each message can be linked by its content addressable hash. The engine allows for Map/Filter/Reduce queries which are not much different in capabilities from SQL queries, these can even be indexed to speed up views. The only real difference is that no schema is enforced on each message type, but it's not that difficult to enforce something like that on a higher layer when publishing entries.
If you think about it, storing JSON entries is a lot more flexible than table rows. Also, the content stored need not be JSON, but EDN, transit or reference to binary blobs.
What I had in mind is, while as you well said, you can link the data in a pub in any way you need, the distribution model is fixed. The only way to change that is creating more pubs.
I think the distribution model is an integral part of the data structure in a general p2p setting and needs to be customizable, within reason.
Cheers!
I think I understand a bit of your concern, although note that the pubs aren't necessarily required for replication in SSB, one can use onion routing, physical devices (sneaker nets), local area connections, etc. But I agree, that there are more areas to improve, such as changing the network/capabilities keys on the fly from within a message to ratchet the distribution, making reference to content hashes within different network keys, etc. I'm curious if your work takes any of this into account? Thanks again.