@The-A-Man makes sense to me, it seems to be an upgrade over the way things currently work
now:
there is an unsolvable data security issue that nobody wants to insure
some regulatory body creates an onerous list of checkboxes
some company sets out to tick all the boxes
independent auditors attempt to tick boxes on pieces of paper
the company creates a proprietary API in front of their box-compliant machines
consumers experience vendor lock-in due to the proprietary API (ever used Stripe’s API? or a bank API?) and they have little or no visibility on the audits (who did it? when? were there any outstanding items?)
the reality is that even if an audit lapses or failed, most customers will not know about it and even if they do they will find it very expensive and inconvenient to rebuild all their systems to a new API - yet customers can be held liable for non-compliance in a vendor’s breach…
the same thing on holo(chain):
there is an unsolvable data security issue that nobody wants to insure
some regulatory body creates a template DHT that enforces as much as possible in code
the regulatory body puts the DHT behind the signatures of independant auditors and a signing time server that the regulator maintains
any company that meets the requirements can apply to maintain the DHT
auditors inspect the company and make public the results as well as signing the company into the DHT
consumers write their systems to the interface of the DHT
consumers pay a premium vs. vanilla holoports for the additional compliance audits
consumers have no vendor lockin because they implement their systems on a standard DHT, and they are guaranteed the audits are real because vendors are automatically and immediately blocked from the system when the audit expires - consumers may not even be aware that their original vendors have changed over time, their service should continue uninterrupted by trust-equivalent new vendors (according to the regulator and auditors)
Yup, right… Can’t be more succinct. Really sounds like the web of the future, where every organizational body has got a role to fulfil, who do so in a clean organized clarified standard as dictated by the template.
I’m finding this thread overwhelming cuz I’m reading the whole thing at once but I have a few extra things to contribute:
If a person isn’t always using their app but has their computer on all the time (common scenario), the UI could be smart enough to do these garbage-collection, auto-like, etc tasks for them, as you said.
I do like your idea of ‘time gods’ or whatever you called them – trusted nodes who can do work for you – although there are certain very agent-centric tasks that might take a bit of work to model. In the “I always leave my computer on” scenario, the time god could do the automatic stuff rather than the person’s UI, but that seems like unnecessary complexity. So maybe you’d want to explore other options. For instance, maybe your app has some concept of delegated identity, where Alice creates a signed certificate saying that “Time God X can publish data for me and, as long as they reference this certificate when they do it, you can consider it as if it were me doing it.”
I hear you wondering about Holo hosts and whether they can take some responsibility for running automated tasks, since they’re always on. Initially I thought similar thoughts, but as I learned about Holo I learned that a host can’t do anything without a user’s consent.
Correct me if I’m wrong @thedavidmeister but weren’t the core devs toying with the idea of conductor-level cronjobs as a future feature? This would still require the user to leave their computer on, but at least there’s built-in stuff and you wouldn’t have to roll your own in the UI.
You’re right @The-A-Man that your DNA’s zome functions constitute an API that somewhat restrict how agents can access data. Yes, the data can still be accessed by someone who can produce the right credentials (“Yeah, I’ve got the right DNA hash, and here’s my membrane joining proof showing I’m legit allowed to be here”) but can bypass the zome API. What I’m learning, though, is that privacy has a lot to do with greasing/friction – that is, it’s not just about whether it’s possible to steal private data, but also about how hard it is (especially compared to the payout). However, a good security professional needs to be paranoid and think about what’s possible, not just what’s likely. What concerns me is the payout – with a cloud system, if an attacker compromises a user’s computer, they get access to the user’s stuff, and if they compromise the server (which is a lot harder), they get access to everyone’s stuff. But with Holochain, compromising a user’s computer can give an attacker access to all of ‘our’ data – that is, data that’s shared among the participants. There’s one comfort, in that people can still have a lot of private data on their source chains that the attacker can’t access, but it does put a responsibility on a hApp creator’s shoulders to think hard about DHT data and threat vectors. Another comfort is that the core devs plan to start encrypting all at-rest data, so an attacker would have to rely on the hApp actually running (that is, the user entered their decryption password).
yup, there are some challenges to agent-centricity for sure. My hunch is that the benefits will outweigh the challenges, but it doesn’t make the challenges go away!
Loved the greasing/friction metaphors… Looks like perfect privacy is a pipe dream at best! What should matter to us is that we be relatively more private than both client/server and blockchain’s fantasy (unscalable) web solutions!
but I have a few extra things to contribute: