Time-bound events are at odds with agent centricism.
How does one model one’s happ such that it implements events like “do something after x days after I do y”??? And other non-human stuff in an agent-centric system.
Originally posted another thread About the RSM Technical Discussion! category -
And yeah, now that you mentioned it, I remember thinking what Holochain’s approach might be regarding events (human actions that have repercussions sometime in the late future)… I think they’re unlike other use-cases like Artificial Intelligence which gladly Holochain doesn’t even pretend to support (unless you can model neurons as agent-ids, hahaha)! ‘Events’ is pretty much a very good candidate for social human-centered apps (i.e. Holochain-supported apps). Perhaps even good-enough to be natively supported by Holochain somehow…
Let’s say that you would like your post to be automatically deleted after 40 days. In the microservices world, it was as simple as spawning some routine-deleter service which does it for any post that was published 40 days ago. However, in the Holochain world, there’s no obvious solution for such use-cases… Sure, you can say to your customers that “hey, we’re not your servants; if you wish to delete your post after 40 days, then set-up a reminder in your phone and then delete it yourself when the day comes!” - against which I can’t find any technical argument though, haha. And besides deferring such use-cases to a smart-enough user-interface (i.e. the ios/android app in this scenario that sets an internal reminder to call the remote delete_post function after 40 days and stays active in the background somehow), there’s not much one can do about it currently… Plus the below code doesn’t look safe (at least to me it doesn’t):
// HDK extern function
#[hdk_extern]
fn post_a_post (...) -> ... {
// commit the entry and stuff like that...
// wait for 40 days (sleep, or whatever)
// delete the entry
}
Any ideas???
It’s a much more general question about the limitations of agent-centrism, I understand… But there’s not much app-remodelling you can do either (at least without upsetting your customers, as illustrated above)… And modelling such time-bound use-cases as full-fledged agents, much like some ancient mythical God-Of-Time (or perhaps Doctor Strange in Marvel’s jargon) all spawned and maintained by the developer… would make for a great comic book! I guess our life as Holochain developers would be a lot simpler if everyone could just stay connected and paired to their host and peers online all-the-time! But the sad reality is that this isn’t the case, at least as of now… If that were the case, node-to-node messaging would have sufficed (no need for asynchronous DHT messaging) and thus privacy could have stayed preserved! But you can’t move the private-keys up the ladder and to the host’s device, 'cause that would mean a total loss of sovereignty & privacy and would become the same client-server model that dominates today… What’s the workaround???
And before someone starts shouting, obviously the above code won’t even commit the entry to the outside DHT (at least in RSM) - the stuff would just stay in the scratch space!
And the below code won’t help much either…
// HDK extern function
#[hdk_extern]
fn post_a_post (...) -> ... {
// commit the entry and stuff like that...
}
// to be called right after_posting_a_post (TODO: implement as a callback)
#[hdk_extern]
fn post_of_posting_a_post (...) -> ... {
// wait for 40 days (sleep, or whatever)
// delete the entry
}
Don’t mind my naming conventions!
The holo-host could simply turn the hosting device off the next day, as there’s nothing that prevents it from doing so… see HIP: Economical Insurance Protocol (Holo Improvement Proposal)
Plus even if negative-incentives do get implemented in hosts, what about the user? The user can and will go offline often… and you can’t delete the post without the user/agent on-the-line!
Alright, now that I think of it, I realize that this one can be as simple as adding a conditional statement in the getter function that says that if the entry was created before 40 days, don’t return it, rather return some error message… Everyone plays by the rules… So yeah… Ought to say it’s a wee-bit counterintuitive though… But what about other time-related use-cases? Can every possible use-case be modeled as an agent-centric use-case? Is there no single use-case that’d not be possible in an agent-centric system? Plus if the entry is public (no matter if it’s marked as deleted or not), you can still bypass the DNA and retrieve it albeit illegally! The immune system does not prevent that!
Alright, what about collaborative-filtering in an agent-centric system? How does one go about that?
Imagine a news outlet start-up that says “hey petty customers, if you want similar news to what you’re watching, then simply check other’s history (the DNA does it for you, but yeah… verbally, this is what the DNA does) and see if you can draw some correlations from their reading habits… Then pick any news that they’ve read and simply recommend it to yourself! And worrying about privacy? Don’t worry, the DNA won’t expose any functions that let you see others’ history; however, the DHT that holds the history of everyone is unencrypted (Asynchronous Private Messaging), and eager stalkers can download this tool from uTorrent that can help with navigating through the public entries bypassing the DNA’s limitations! We’ve built on top of Holochain, so we traded away single-point-of-failure and single-point-of-trust! So now instead of trusting one company with your sensitive history, you’re now trusting all customers with your data! What’re you waiting for? Sign-up now”.
Good luck launching that!
Correct me if I’m wrong in my understanding anywhere…
You sound negative about this. Do you not realize that its easy to see what people see and not who sees it!?
A node does not carry all of a person’s data. It’s called sharding and Holo does is via random hashing
Don’t get me wrong. I’m as bullish on Holo(chain) as anyone… I love privacy, and I sure-as-hell love Holochain’s philosophy!
No doubt, I agree with you. The reason they dont talk about the flaws, is because 1) its bad PR and not a good business strategy, and 2) the ‘flaws’ are things they dont claim to be able to solve. They’ve been very upfront and straightforward about their value proposition.
The cool part of this design is that it gives dev’s freedom to create the landscape. Overall it incorporates what so many projects miss: the human element. As @carolyn said it best: How we Grow
In my opinion, game theory is not as simple as measuring data or evaluating outputs or predictive modeling. Way more often than not there are tons of underlying variables and alot of opportunity to capture and utilize a wide variety of metadata.
I’m sure the third-parties that Paul (@pauldaoust, please save me!!!) refers to aren’t the other participants (or rather agents) of the same (h)app (i.e. DNA; ambiguities are bad, I’m gonna do my best to be more accurate at communicating my fears about HC rather than assuming everyone’s on the same plane). Other agents would simply interact with the app via. its DNA’s exposed/exported functions. However, there’s an inherent fear that engulfs me when making an entry public: I expect that public means “public”, i.e. visible to all, not just the decent people interacting to the app via the DNA! And I’m sure there’s nothing the conductor can do to tell whether you count as ‘decent’: again, to clarify, in our terminology - to execute a simple get call (in the lower layer) the conductor simply takes the address of the public-entry (though it’s the public-header now, it’s still simpler to think this way), goes to the node nearest that address (it’s more complicated and requires more hops though, but let’s keep it simple yet succinct) and returns to you whatever it received! That’s all at the core’s core level! (@thedavidmeister please help!!!) It doesn’t ask you for any proof-of-legitimacy, and even if it did ask you for an agent-id, then great! Just give it an agent-id (again, what I mean to say is that anyone can make a public-private key pair at the snap of the finger!). As for the DNA-hash, well, it should be obvious that it’s no secret!
Privacy is an intricate topic and one simple yet powerful statement explains much of all I said:
“If there’s a secret that no one can access then there’s someone who can!” (Thank me later… Kidding) If the data is with you, it’s totally safe. If it’s in public but encrypted, it’s still safe. If it’s with someone else (a private company, for instance), it’s relatively safe. But if it’s in public unencrypted, how come it be safe at all! It’s as simple as that.
All public data is public and accessible to all. And private-only data doesn’t make sense for many apps! Most if not all use-cases only make sense if some sense can be made from the data. And to make any sense from the data, you need the data! However, in an agent-centric approach, YOU make sense of everyone’s data: mitigating single-point-of-failure, it also sacrificed single-point-of-trust! And every time I go about implementing some happ, it often comes as a major road-block!
@The-A-Man holochain and cryptography are just tools, if i show you a hammer and a screwdriver don’t say the hammer is useless because screws exist and the screwdriver is useless because nails exist 
yes anyone can make any pub key they want, many cryptographic protocols rely on this to have single-use keypairs for a specific task to achieve certain guarantees
all apps decentralised or not need a way to map raw cryptographic primitives against higher level concepts like identities
is holochain making that problem worse or somehow harder to solve?
2 Likes
@thedavidmeister
But is it true that a tool (just like a hammer or a screwdriver, let’s call it a chainsaw) can be made that accesses the public entries on an app’s Holochain network bypassing the DNA? Much like what EtherScan is to the Ethereum Blockchain. Can such a script be written? As far as I know, the repositories are all public and there’s no secret sauce that gives a conductor the privilege to talk to nodes and retrieve the public data! They just need to be talking the same protocol. Sure the DNA can dictate what public data it can be asked for… And if everyone plays by the rules, then great! But turns out, you don’t have to (at least for the public entries) play by the rules… The DNA/conductor haven’t any special privilege to talk to the network/peers. Anyone can write a binary that talks to the network and use it to ask the network for the public entries! And to make sense of data for most use-cases you have to make things public, things that normally you wouldn’t want to keep public (such as your history)! But now, instead of trusting it with just one decent company, aren’t you forced to trust it with the whole wild world?
I thought there was much more that Holo(chain) promised. It promised to be the platform over which to build social apps! Is that not something that it promises to support building anymore? Surely the cryptographic sorcery can’t be all that it does and promises?
And what’s a social app? A place where you can sign-up? Surely not! A place where you store your photos securely? Definitely not! A social app draws its meaning from its ability to draw extrapolations and make sense from all that data it has.
Are such social apps buildable on Holochain with at least as much privacy as the traditional centralized media giants offer?
@The-A-Man i can’t answer 20 questions at a time
you can make a private network by implementing the callbacks that determine who can join
if someone fails that challenge they can’t open connections with peers, even if they have the DNA hash
data can be ‘public’ to a private DHT in that way, which really just means that it is shared between the peers who are privately connected to each other - you can also layer encryption on top if this of you want, but data encryption and network access are totally separate things
no, you can’t bypass the check with a knife because you need to establish a valid connection with a peer (e.g. cryptographically) before they will send you any data
you don’t even need to use a public bootstrap service for a private DHT, so you wouldn’t even know the network location of the peers until you managed to first find and authenticate against the private bootstrap, let alone being able to connect to them
i don’t exactly understand what you’re asking or a specific problem presented here
trying to meet you in the middle by asking for clarification so i can directly answer your question
1 Like
Exactly what I thought while writing the above posts… However, another minute of thought reveals that all it takes is one person to give away his private/public key to the chainsaw hacker! That’s all! System sacrificed! Public (network-wide public, to the wider world private) data sacrificed!
And is there any secret-sauce about that? Anyone can build a protocol that talks to a holo-port! That’s how protocols work! A protocol is just a formal language of specifications about how the talk happens!
if you give information to someone they can give it to someone else
Yup, I get it. But it’s obvious that most successful happs will have a public bootstrap server! I mean, what’s the utility with a private bootstrap server? None!
Let’s not get side-tracked.