Right now it does affect the exchange of data between different nodes, yes. I believe they’re working on it; may already be fixed. In the meantime we’re just recommending that agents create an agent ID anchor for themselves – some sort of plain old app entry that holds a string, like their public key or the hash of their public key perhaps. Then they can use it the same way they would use their proper agent ID entry.
Will employees have their own accounts that they can log into? If so, is there room for employees to have their own nodes? The way Holochain is designed, a node = a user.
If the app is only meant for managers, however, then node = manager makes sense, because only managers should have user accounts.
Question: in what situations do the managers want to update information about employees in another manager’s department? Is it possible to have all that information public, in the DHT, rather than under the ownership of any one agent? That way it becomes “data we know about” rather than “data we own”. That’s the chief purpose of the DHT — to hold data in common.
Re: network overhead, I’d recommend waiting until you can collect real-world data before you optimise for this sort of thing. I understand your concern — you don’t want every single node to hammer the DHT with
get requests every time it wants to calculate an employee’s score. And it sounds like that’s why you want to optimise by having managers regularly pre-calculate scores, or be in complete control of each employee’s record so they can update the score on their own source chain.
Holochain is really powerful, however, when you can find some way to use the DHT. Here are a couple helpful tips:
- You can put arbitrary data into a link (the data goes into a field called the ‘tag’). If nodes were to collect all of an employee’s reviews by searching for
review links attached to their agent ID entry, and if you put just enough data into the link tag, you could calculate the score with just one DHT lookup.
- Any time an agent makes a DHT
get, the entry gets cached in their own DHT shard. You can’t guarantee that it’ll always be there, but it will help to optimise future lookups.
- You could make the users’ UIs keep track of the scores of the employees they’re interested in, and update the scores as they read new reviews. If the ‘state’ (the employee’s score) is calculated as the average of all the ‘facts’ (individual reviews), each of those facts can be considered ‘state changes’ that update the state held by the UI. If the UI loses that state data (maybe the hard drive gets erased), it can always recalculate it by re-collecting the facts from the DHT — which is slow, but also doesn’t happen often.
Anyhow, some food for thought. Let me know if I have explained anything poorly and I’ll try to find better words