What this node moves over the madnetwork, in both directions — every
blob it has bytes for, whether that blob is part of your library or was
fetched from somebody else. This is the transfer view;
what is on the disk and whether it should stay is
Cache, and your own content is curated on
Library.
Loading…
{{/* Who we trade with (mig 042) — all-time per counterparty, the companion
to the member quotas. Collapsed by default: the numbers matter when you
go looking for them, and a list of node names above the file list would
be a second page. This is their ONLY home; /admin/network owns the same
nodes as trust decisions. */}}
Who we trade with
Loading…
{{/* The rate knobs live here and ONLY here (docs/architecture/swarm-admin.md):
the page that shows you the traffic is the page where you throttle it. */}}
Transfer limits
This node's line
These cap what this node's swarm traffic costs your line. They apply to
everyone, friends included — they describe your
pipe, not who deserves what. Leave a field empty to use the value from
madshare.toml; enter 0 for unlimited.
Member budget
The caps above describe your pipe. These describe who may spend it:
they bound what nodes you have not friended — members
of your community, guests, a device carrying a token — may cost you.
Direct friends bypass all four, because a friend is a
decision you made and should not queue behind the ones the graph let in.
Empty means the value from madshare.toml; 0
is unlimited.
What do the member limits do?
A node over its budget is told 429 busy before we even
look up what it asked for — so the refusal says nothing about
whether we hold the file. A healthy fetcher takes that as
“ask another holder” and goes elsewhere; one with no other
holder waits the congestion out. Being unable to serve right now is
honest information, not an error.
The together limits are the ones that actually bound
harm. A per-node limit is what a flood of fresh identities defeats
— each forged key simply buys another quota — while the
class ceiling is one number they all share. The per-node halves are
fairness within that ceiling: one member cannot take the whole
budget.
Concurrency is worth setting even if the rates stay open: a fetching
node opens parallel requests by design, so it is transfers, not
bytes, that one member most easily multiplies.
How big should the rate caps be?
Size them against your uplink, not the download speed
your ISP quotes: KiB/s ≈ Mbit/s × 128. Leaving
about a quarter of the uplink free is a good starting point — so
a 20 Mbit uplink (≈2560 KiB/s) suggests roughly
1900.
Do not set them small. One listener streaming CD-rate
FLAC needs ~125 KiB/s continuously, and every concurrent transfer
shares the same bucket. Below that, this node does not merely get
slower: fetching peers time it out, the swarm de-ranks it and goes
elsewhere, and the bytes you already sent are wasted. If your line
cannot spare ~256 KiB/s, switching seeding off on
Settings is the honest setting rather
than a starvation rate.
The download cap also slows anything you are listening to from
the network, since the player reads from the same transfer.
{{/* Destructive actions are modal, never an inline two-step. */}}