4 ms·

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: per

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: https://github.com/hyperhyperspace/hyperhyperspace-core https://github.com/hyperhyperspace/hyperhyperspace-core

nanomonkey 6y ago
I'm not sure what you mean by not as flexible as relational model. I'll address SSB, as I'm more familiar with it, as I've built a CRDT system on top of it in clojurescript. 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.
- sbazerque 6y ago
  > Each message can be linked by its content addressable hash. 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!
  - nanomonkey 6y ago
    Thanks for your response, I find this stuff super interesting to watch evolve. 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.

nanomonkey 6y ago

I'm not sure what you mean by not as flexible as relational model. I'll address SSB, as I'm more familiar with it, as I've built a CRDT system on top of it in clojurescript. 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.

sbazerque 6y ago
> Each message can be linked by its content addressable hash. 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!
- nanomonkey 6y ago
  Thanks for your response, I find this stuff super interesting to watch evolve. 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.