Chewing on all this some more…
Trust
My hunch is that there will be two different kinds of embedded devices: ones that have the power to run a full HC node (e.g., RasPI Zero W) and really tiny embedded devices that send data points to a full HC node. In both cases, there’s at the very least enough memory and muscle to:
- store a keypair
- store a manufacturer’s certificate ‘blessing’ the keypair as legit
- hash a data point
- sign the data point with the stored private key
This might be a useful start for getting the device to prove authenticity of manufacture. How to prove that it hasn’t been tampered with, or that it isn’t a clone created by someone who figured out how to extract the private key from memory… Not sure Best to reduce the surface area, I think: have the signing happen as close to the sensor as possible, and have an additional sensor that senses compromise of the physical enclosure. Not sure; I’m not a hardware guy (although I like to think about it!)
Your ideas about non-binary, reinforced trust are also intriguing and very Holochain-esque
Discovery
I like that you’re already thinking about the difficulty of mapping a space of mushy boundaries to the sharp boundaries of a DHT. At one point there will probably have to be an oversimplification of reality just to make the discovery DHTs small enough. What’s the ‘user portfolio domain’? Sounds like an important concept for me to understand. Re: overlapping/fractally-sized domains, what sorts of rules for membership are you thinking of? And how are you thinking of applying bridging here?
One challenge that occurs to me now is how to point a subscriber to a publisher’s most recent signal DHT. Obviously this happens in the discover DHT, but how? If the publisher writes an entry in the discovery DHT with every migration of the publish DHT, and the publish DHT only has three entries per, then you’re still publishing one signal one entry for every three signal entries. There’s a storage savings, but it’s only 66%.
Another alternative might be to have a node discovery DHT, a signal DHT discovery DHT (yeah, I know, complicated), and finally the signal DHT. The mid-range DHT is thrown out every day, and only requires daily writes to the agent’s chain in the ‘big’ discovery DHT. Obviously you’d want to tune numbers like ‘daily’, ‘3 signals’, etc based on real-world observations… What do you think?
Other options are using node-to-node messaging and signals (of the Holochain type, not the pricing type), rather than published DHT entries, to find out what signal DHT an agent is currently publishing on. Can it be assumed that most publishing nodes will be online most of the time? If this is viable, the publisher agent would still have to have some sort of persistence so at least they know what DHT they’re using. If you’re not using a source chain for that, you’d have to keep it client-side somewhere — some sort of daemon, maybe, that knows what publishing DHT the agent is using and can respond to requests for that info. I presume the architecture already a daemon that automatically grabs signal info for publishing.