Implementation node-to-node messaging

Technical Discussion App Development
,
#1

Where can I find source code that explains node-to-node messaging?

I’m trying to make nodes communicate privately in the background.
I found send function, but I have some ambiguity in the implementation and need answers for these questions :

  • How can I get parameters such as Agent Id and network status?
  • How can I receive the message?
#2

Here’s a bit of info…
https://developer.holochain.org/api/v0.0.32-alpha2/hdk/api/fn.send

2 Likes
#3

The ‘api’ section of the docs, relating to the HDK itself, will have better details on usage

1 Like
#4

Yeh the explanation in API is much better. :+1:

Thank you so much @Connoropolous

Do you have any idea about traits : and its usage?
Is it mandatory for the success of communication?

#5

I think that’s just marking the send_message function as a hc_public function so you can call it from outside the conductor.
You will need to have the agent’s id in order to send a message to them.
Each agent can get their own address with this https://developer.holochain.org/api/v0.0.32-alpha2/hdk/api/struct.agent_address
You might want to setup an anchor that links to all the agents names and their address like an index. Alternatively you can get an agents address from the first commit in there source chain.

#7

I think it is much clearer now. :+1:

so that’s mean I either can get the agent address by:

  1. Struct hdk::api::AGENT_ADDRESS
    let to_agent: Address = AGENT_ADDRESS.to_string().into();
  2. link all agents addresses together, then retrieve them using get links function
    hdk::get_links(&base, "item_tag")
  3. returned value from commit function :
    let to_agent = hdk::commit_entry(&post_entry)?;

I’m not sure about the last one. hope you correct me if I misunderstand it.

#8

Other question:

if I want to make the receiver do some actions when receiving my message. How can I do it?

Actually, I want the agent updates some data within its own local storage according to my message.

#9

@freesig

#10
  1. for sure
  2. I think you could do this.
  3. This is the address of the entry that is returned.
    I think the agents address is held in the first entry. It really depends what you’re trying to do.
    If you have an entry from an agent and you want there address you can check the provenances and it’s the first signature. (I think that’s correct @pauldaoust ?)

This next question:
Thinking this through you can’t ever rely on another agent to do something on their end unless they can prove it to you some how.

I’m thinking they would need to commit an entry to prove that this has happened but it’s pretty hard to prove something is in a certain state outside of Holochain.
Can you give me a bit more of a use case?

#12

Hi @freesig It is something like this:

a system that manages users’ profiles, where users gain scores according to their activity in the network. So, each user profile should be updated frequently as much as a user interacts with others.

I’m thinking to make each agent responsible for managing a group of users, compute their score based on opinions from others and do some checkings before committing data.

I think it is pretty difficult to make all agents participate in updating the same profile and its difficult to find the evaluator in case of fake scores.

#13

I might be mis-understanding something here but could you no just make the users computer their own score and publish it to the dht so other agents can validate it.

Validating the other players would look something like you get another users score entry and then you rerun the entry through the validation rules. It if passes then you know they weren’t faking the score.

The trick here is finding an algorithm that you can run on any users entry in order to calculate the score.

Does that help or have I missed something?

#14

The idea is each node acts as a master node for a group of people. So, the master node is the only one who’s responsible for managing profiles of people within its zone and update their data.

Other nodes can either read data from the master or pass a new score to tell the master to update this person.

54%20PM
Screen Shot 2019-11-07 at 12.34.54 PM.png876×766 65.5 KB

For now, my concern is how can I make Node B tells Node A to update data about A: 003
Hope it is clear now thank you @freesig and sorry for bothering you

#15

Hey @Rzan
Don’t be sorry at all, I love these conversations. I think they are very helpful to have and for others to read.

One thing you could do is create a message type call something like UpdateUser and then when it’s received the receive zome function could match on that message type and commit the update to the person.
You would need to have something in the validation code for the commit which updates the user to check that the user does belong to the node.

In this example:

  1. Node B messages Node A with an UpdateUser message for A:003.
  2. When Node A gets this message the receive callback is run and a new commit is made that updates A:003.
  3. The commit that updates A:003 has a check in validation that looks for a previous entry (Could also be a link) that shows Node A is the master to A:003.

You would also need to figure out some rules on how users get a master so that this is validated as well.

Hope that helps :smile:

#16

It’s nice of you @freesig . I’m also enjoying while discussing things in the forum. It helps me in understanding since some parts of the documentation are not completed yet. Also, this GitHub project was very helpful https://github.com/holochain/peer-chat

I notice recently my problem is in receive callback . It works only when the agent sends a message to itself. I think the reason is in the version I’m using. So, I will update it and see.

#17

@Rzan I meant to jump into this conversation a long time ago but it escaped my consciousness :sweat_smile: I’d like to ask a question about your model: Does a node represent a person, or is it more like a server that’s responsible for a few people? Holochain’s ‘agent-centric’ paradigm maps nodes to people 1:1 (well, m:1, really, because a person might own a laptop and a phone and would want a continuous identity across them both). So in a Holochain app, Node A would only be responsible for 001, Node B would only be responsible for 002, etc.

But that doesn’t address the issue of adding scores. Going back to the ‘agent-centric’ paradigm, is there a way of modelling your app such that a user’s score is always dynamically generated from the sum of all the opinion data that other users have published about them?

Here are your ontological building blocks:

  • An agent = a node = a person
  • Every person publishes their own ‘agent ID’ entry to the DHT
  • Everyone is in charge of the data they produce, and it shows up on their own source chains before being published to the DHT
  • Anyone can create links from any one DHT entry to any other DHT entry, including agent ID entries, entries they’ve produced, or entries someone else has produced (although there’s a bug in HC right now that’s preventing links on an agent ID from being published)

Eager to see what you dream up! :rocket:

#18

Hi @pauldaoust so glad to see from you

It is actually like a server that coordinates a group of people.
To make things clear, let’s assume each node (server) represents a department of the company. So, each department will be responsible for employees’ scores within its region.

I’m trying to reduce the network overhead by making each department manager be responsible for employees under his charge ( calculate their final scores after collecting opinions from others then publish it to DHT).

So it will be like this :

  • An agent = a node = manager.
  • Each manager responsible for registering employees and publishes their own ‘agent ID’ entries to the DHT.
  • Every employee sends his opinion toward others to the manager.
  • Manager collects and dynamically re-calculates and update the final score in DHT.

Yes, I’m working to make node (manager ) updates score dynamically as soon as receiving new opinions

Does this bug effects in exchanging data between different nodes? Is there any update about this bug?!

#19

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 :wink:

#20

Yes, each manager represents a single node >> that’s what I’m working on right now. Managers need to update information about other departments in case the employee changes his department.

Tracking and Cashing are good ideas. I will consider them :+1: :sparkles:

Thank you @pauldaoust for your informative response.

#21

Okay, in that case I’d let the DHT be responsible for that information rather than any one agent, as long as it’s okay for the information to be publicly visible to all managers. If Alice starts out in Bob’s department, Bob can be responsible for creating Alice’s initial record and publishing it to the DHT. After that, anyone can update it.