Hum… If I understood correctly, the secret or UUID is stored in a DHT entry without links to anything, so that when the joiner gets the secret it can get that entry?
not quite…
The secret directly ties into the DNA hash, via the UUID property of a DNA… e.g.
{
"uuid": "uuid-speller-dilation-kinsman-eastward-cylinder",
"zomes": {
...
}
}
taking the seecret shared by Alexander as an example.
That way, no one can have any clue about the DHT of a particular Project, unless they have the secret, and properly use the secret within the UUID property of the otherwise same template DNA, which is the part that’s publicly available.
Oh okey! So, in the open DHT you save some properties of the project DNA (“project_meta”), but only without the UUID. Then, one person wanting to join retrieves the DHT entry from that secret (I don’t know how this is done), attaches the secret and boots up the DNA. Am I right?
Have you considered using the validate_agent function in the projects DNA to block non-invited members? This is the mechanism @hedayat and me are using, paired with the nickname of the agent that enters the DNA. This way, even if someone gets the contents of the DNA, they won’t be able to join.
I think there was some misunderstanding 
There is no way to discover projects… only to join secret projects, based on someone sending you a project secret OUTSIDE of Acorn. There is no directory of projects. All projects are secret and local to the person who created it. Until, and unless, they share the secret with someone.
Then another person plugs that in to the form field, and the code converts it to the UUID… see here: acorn-ui/secrets.js at master · h-be/acorn-ui · GitHub
The passphrase IS also stored in the ProjectMeta entry for convenience, and for showing in the UI later, to the project owner. And the ProjectMeta entry is linked to a known anchor, so anyone can check if it exists if they have joined that DNA using a secret in the UUID. Since the project creator commits the ProjectMeta entry immediately after creating a project, it should exist, if the project exists, and if the Project creator, or any other member of the DNA is online/connected.
As I mentioned “passphrase”, which is the secret, is only stored on the ProjectMeta entry for convenience, not for security. The fact that the DNA was booted up using the passphrase in the UUID is where security is provided.
I am watching your other experiments about ways of managing membranes of inclusion/exclusion with interest!
Hum interesting… Where is that entry stored? In the global open DHT, or inside the secret small ones for each project?
inside the secret small ones for each project
Uhhh and then how do the agents inside the big open one access that entry? Through a send/receive to the creator of the project and bridge to the small DNA?
Nope… they just literally “jump in” to that DNA (because they have a secret) and then check in that DNA to see if that entry exists. A.k.a. there’s nothing stopping someone from punching in a random secret, “creating and joining” that DNA, looking inside that previously non-existent DHT for an ProjectMeta entry, and backing out of it (removing it from their conductor config again) if it didn’t. As I said, I am question that model a little bit, as it’s not good for asynchronous joins.
there’s no interaction between the “global” profiles DNA/DHT which everyone is in, and the Project DNAs. They’re totally decoupled.
1 Like
Ahaaaa okey now I get it fully, thanks for the explanation and sorry for all the questions 
I think for now it’s more than enough, also considering that validate_agent is not really working… In our case we’ve had to pretend as if it was working from the UI.
3 Likes
I think it’s a really cool pattern. It essentially makes the existence of something a secret and the joining of it independent of an index. That’s powerful!
2 Likes