How does the GUN ecosystem fit together? Here's an explanation from the chatroom about how HAM, GUN, DAM, SEA, RAD, AXE play into each other while also being independent tools on their own:

Summary

DAM hears network plugins and emits them in to GUN, where wire adapters hook in before DAM merges the data, which then puts it back out. The SEA wire adapter firewalls in messages and cryptographically verifies the data. If RAD is turned on, it takes the puts and inserts them into a radix tree that it saves in chunks to storage plugins. When AXE is enabled, it matches each put with a pub/sub routing list of peers.

Explainer

GUN only does brute force deduplication of messages in its event loop. It acts like it is WiFi router or that its just jamming noisy signals into a room so like, perfect for UDP multicast but other than that, GUN doesn't actually care about the outside world. GUN cares more about taking that noisy data in and merging it with the conflict resolution algorithm (HAM) so that way whenever you access the in-memory graph that is always valid/consistent. Access is usually hidden behind an API so you don't corrupt it, but if you're at the protocol layer you may directly manipulate it.

So GUN it takes data in, merges it (HAM), and emits the resolutions out. That's noisy so DAM comes along and says, "hey, let's optimize the shouting inside a room". DAM hears things, and then feeds it in to GUN. DAM also listens for GUN output to then say things to the external world. DAM is your ears, GUN is the brain. GUN has no plugins - only wire protocol adapters & chain API extensions.

RAD basically only listens to output from GUN and filters for what/when/where it should save of the graph to disk/storage. RAD is your memories. tho like DAM, since GUN has its own protocol semantics, RAD wraps that and exposes a boring interface for storage engines. This enables plugins to basically just read/write key-value pairs because RAD does all the tedious work of converting GUN graphs into disk serializable radix trees*. It also makes sure those "blobs" are consistent and not trashing each other.

*Actually radisk does that, which is the biggest "part" of RAD. RAD has a several parts: (1) radisk (2) GUN wire protocol adapter (3) bunch of storage engine plugins. From a vocabulary standpoint this this is were we say plugins.

DAM is intentionally pretty limited in what it does. AXE is the real kicker, it does build on top of DAM & GUN so it cannot be used without at least DAM. DAM & RAD have plugins, networking transports and storage engines.so back to AXE, it is the first thing that actually builds on top of the others, or needs/assumes the others. AXE is where we go from "shouting in a room locally" to doing efficient global routing - if that fails, it falls back to DAM, if that fails, it falls back to GUN. AXE is the only reason why GUN has scaled as well as it has and will be the thing that is most important to implement in Rust. The chaining API, RAD, etc. are not as important.

SEA has zero knowledge of GUN or DAM or RAD it is a friendly wrapper API for those concepts. There is an adapter for GUN that is default included in SEA, but it's perfectly safe to exclude so relative to GUN ecosystem. SEA has 3 parts: (1) core (2) GUN wire protocol adapter (3) chain API extensions.

RUST SEA in Rust should be outsourced to vetted cryptography crates. However to do the interesting Rust things in AXE, we need DAM/GUN first - which thankfully, is pretty easy to port. AXE is the only reason why GUN has scaled as well as it has and will be the thing that is most important to implement in Rust. The chaining API, RAD, etc. are not as important.