Network architecture #9
Conversation
tg-x
force-pushed
the
tg-x/network-architecture
branch
from
5e69a2b
to
9ee85d2
Compare
tg-x
force-pushed
the
tg-x/network-architecture
branch
from
9ee85d2
to
5810b68
Compare
| - *Anycast*: messages sent to any known member of a domain. | ||
|
|
||
| ## Network architecture | ||
|
|
There was a problem hiding this comment.
Here would be an excellent place to add a diagram that matches the text below.
tg-x/network-architecture.md
Outdated
|
|
||
| ## Node architecture | ||
|
|
||
| The system is based on the *actor model*, |
There was a problem hiding this comment.
Can you add a sentence explaining what the actor model is and why it is important?
There was a problem hiding this comment.
I would say inspired by instead of based on, because we are tweaking things
also---as added benefit---we may hope that reader 's take on the actor model is possibly different w/o causing issues
| This article serves as a brief introduction and high-level overview of the network architecture. | ||
|
|
||
| ## Node architecture | ||
|
|
There was a problem hiding this comment.
Diagram would be great to add here to help the reader understand.
tg-x/network-architecture.md
Outdated
|
|
||
| ## Domains | ||
|
|
||
| The network consists of sovereign domains that enable pluralistic interoperability. |
There was a problem hiding this comment.
Can you explain briefly what you mean by pluralistic interoperability.
| A domain may be instantiated as one or more overlay networks that may or may not be inter-connected, | ||
| depending on the protocols run in the domain. | ||
| This allows both single-instance domains, | ||
| as well as [grassroots](https://arxiv.org/abs/2301.04391) domains |
There was a problem hiding this comment.
Maybe a brief compare contrast b/w grassroots domains and single domains beyond what is stated would be helpful
|
Added diagrams |
tg-x
force-pushed
the
tg-x/network-architecture
branch
from
5810b68
to
3b36a5d
Compare
|
Your diagrams are fantastic! Thank you for expanding on the flagged comments, the only thing to add in the conclusion would be to say Anoma somewhere. Instead of "The Network architecture", use "Anoma's network architecture" or something to that effect. |
There was a problem hiding this comment.
The present draft presents the relevant topics in a succinct way. Extremely useful for me, ʙᴜᴛ ...
... I wonder whether the post could be restructured, to follow the following pattern:
- the question: how to get messages from A to B?
- a first try / highest level of abstraction (nodes and links / overlay network)
- a second try / putting in some detail (intra-node communication)
- what we actually do (inter-node communication)
- what we have not told you (e.g. domains, actor model, etc. here)
conclusion
- seemingly simple question,
- complexity builds up, and we haven't even touched
- incentives
- QoS
- whatever you are doing research on when not writing posts
A different way to reorganize that comes to mind: think of how you would want to explain this to a first year student at university, and then scratch out all the details that you don't need and add a running example
| excerpt: A brief introduction to the network architecture of Anoma. | ||
| --- | ||
|
|
||
| ## Introduction |
There was a problem hiding this comment.
Why should reader read this?
Is it cool, new, amazing, ... (I know, but reader doesn't ...
tg-x/network-architecture.md
Outdated
|
|
||
| ## Node architecture | ||
|
|
||
| The system is based on the *actor model*, |
There was a problem hiding this comment.
I would say inspired by instead of based on, because we are tweaking things
also---as added benefit---we may hope that reader 's take on the actor model is possibly different w/o causing issues
|
|
||
| Each node has a cryptographic identity that uniquely identifies it in the network. | ||
| A node consists of a collection of running engines. | ||
| Local engines communicate with each other directly, |
There was a problem hiding this comment.
directly
→ unencrypted message passing
or do you mean
directly
→ directly (in principle via shared memory)
not sure how to avoid the idea that we suddenly do not do message passing any more
There was a problem hiding this comment.
both, though in this context it refers to direct messages between local engines,
and thus not via the router/transport engines
tg-x/network-architecture.md
Outdated
|
|
||
| - *Unicast*: direct messages between two engines. | ||
| - *Multicast*: few-to-many messages sent to a publish-subscribe topic and delivered to all subscribers. | ||
| - *Anycast*: messages sent to any known member of a domain. |
|
|
||
| <figure> | ||
|
|
||
| ```mermaid |
There was a problem hiding this comment.
in this figure,
ideally we would have two types of edges
- links/connections/direct acquaintances
- message hops
sth. like this
https://excalidraw.com/#json=qcijAZi3QPhjvbSiTntcl,yxzrxo8AKJKJ-E9gJS4_3w
tg-x/network-architecture.md
Outdated
| ## Network Architecture | ||
|
|
||
| The network consists of nodes that may communicate with each other directly, | ||
| and participate in any number of domains. |
| ## Domains | ||
|
|
||
| The network consists of sovereign domains. | ||
| A domain is a sub-network with its own *cryptographic identity*. |
There was a problem hiding this comment.
nodes also have crypto ids
- what's the difference?
- what are the commonalities
I like this frame a lot - @tg-x wdyt / do you think you could organize the content like this? |
A brief introduction to the network architecture of Anoma.
It's a brief, high-level overview, leaving more details to the upcoming ART report.
Github-rendered post