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…
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?
@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?
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
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!
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!
But the web APIs you’re talking about do so via a centralized firm running those API servers that serve those requests strategically! That’s the good old world, not our Holochain’s world!