Trustful Network

In order to continue to implement the trustfull network, we need to do the following:

2 Likes

It’s hard to remove docker for the core because we sandbox the communication between services and core using a docker networks (mesg-shared). Also the only reason now to remove docker is just to run multiple instances but this can easily be done with docker (just need to add the docker service name as a configuration and that’s it).

Right now I don’t think we have any real reason to remove docker and it will complicate things a lot for the development. Let’s just make sure that we can be flexible and fast on the development and we can improve this later if we need to.

What do you think ?

2 Likes

I agree with you.
Until we have a really good working network and really want to bundle Core in a binary, we should keep core in docker.

lets create a flow diagram for trustful network. this will make it easier to understand and we can put its improved version to docs in future.

1 Like

Really good idea to document that through schemas.

I see 2 kind of schema that can help

Sequence diagram https://en.wikipedia.org/wiki/Sequence_diagram

This one shows the communication between the different actors, here the application, the multiple core and the different resolvers

Activity diagram https://en.m.wikipedia.org/wiki/Activity_diagram

This one is more about the logic for the process. If we don’t have the service then we call the resolver then we delegate to the core returned by the resolver etc…

1 Like

I started working on diagrams. I’m thinking that we can have 4 different diagrams to show different aspects of trustful network.

Diagram Ideas

  • demonstrate task executions.
  • demonstrate task execution with =>3 core in the network.
  • demonstrate feeding resolvers with peers.
  • demonstrate validating task results.

I’m currently working on demonstrate task executions diagram, it’s still in progress. Please check it out to give some early feedbacks. :slight_smile:

26

1 Like

@Anthony So maybe, we can use flowcharts in the website to give a more visual view in the higher level and use UML diagrams in the technical docs to provide a much more explanatory view. What are your thoughts?

@ilgooz 100% agree to put some schemas on the documentation, that will be really helpful for people to understand I think. I’m not sure this one is so necessary for the user but we could have a technical documentation for the developers and put that on the wiki or in the docs folder but not display it on the website. That would be really nice to have more documentation and not only for user but also for the core developers.

I worked on an activity diagram to explain the process when we execute a task that goes through the core then if the core doesn’t run the service, call the resolver to find the core where we need to delegate the task and then call the task on the other core then send back the result to the application.

Core%20resolver
schema source

1 Like

It may be useful to have a look to this https://github.com/hashicorp/consul (https://www.consul.io/) or this https://github.com/stvp/dht

Just putting some network lib links:


1 Like

MESG now runs on its own network based on tendermint