Marvellous! I’ve been waiting for a glimpse of people using the admin API to spawn/fork private DHTs. @Connoropolous do you feel like you’ve developed a pattern that’s ready to share with people? I looked for a bundle.toml to see how you’ve configured DNA vs instances but didn’t see one.
Hi @hedayat, thanks for the invitation. I’m going to decline for now, I am intending and wanting to share lessons learned though so I am planning to write a blog post about that. I will share it when it’s ready which shouldn’t be long!
It made me realize how that is an interesting, and somewhat challenging aspect of Holochain DNA spaces, is that by ‘entering the space’, people don’t really have any way of knowing inherently whether anyone ‘entered the space’ before them. The only way they can know is by looking for a piece of data that everyone who joins the space can expect to exist. If it exists, someone entered the space before you, if doesn’t, we might (but shouldn’t necessarily) assume no one did.
Nice to see this! I’m planning on building a small zome that keeps track of all the dnas cloned from an existing template, to list them when you have not joined them yet. @Connoropolous have you already done something like this, and would it be useful to you?
That is a not helpful error, darn
However, I have one theory, which is based on something not immediately intuitive.
Each time a new person joins a project, it gets easier for new people to join the project. Here’s why: in order for someone to join a project, they actually need to verify immediately that someone else has actually created this project, and that means checking information that they committed to their chain.
So when the second person to join attempts to join, the first person who created the project needs to be online/connectable at the time.
So in those cases, it is best to coordinate a time when joining will happen.
After the second person has joined, only one of the first two people needs to be online when the third person joins, etc. Making it exponentially more likely that coordination between someone new joining needs to coordinate with an existing project participant about a time to join.
I am starting to think about an alternative to that, now that I’ve walked through it. But it will require rethinking more.
whoever gains access to the invite code for a project has the ability to join that project.
This is dictated by deterministically converting the secret into a UUID that gets placed in the DNA, and produces the same DNA hash address as the other players are playing in.
The catch to all this is that when a player actually attempts to join a DNA, it acts like a two way in and out flow, where it actually tries to join the DNA, it checks if that DNA exists as indicated by the presence/existence of an entry anchored to a predictable address that everyone knows. If no “project_meta” entry exists anchored to that anchor, then it reverses out of the DNA, and suggests that no such project exists. That’s why new project joiners require an immediate connection to an existing player.
without that"project_meta" being returned to the project joiner, that individual doesn’t know the name or image, etc of the project it is attempting to join, because that is stored in the DHT, that it hasn’t yet synced with.
I am considering the alternative now though, where we could store a list of “projects pending to be joined” … where it will just join it, and then wait for a prolonged period to see if it ever syncs with, and joins other nodes. In other words, don’t reverse out… just occasionally check back in to the DHT and see if any other nodes come online and provide access.