Thoughts: Canadian Regions Strategy

Canada Regional Discussions Inter-regional
29

Repeater Configuration Examples

Examples use region def (firmware v1.16+), which builds the whole hierarchy in a single line.

region def syntax (a — official CLI reference):

  • Tokens are processed left to right; each token becomes a child of the previous one (a linear chain). The cursor starts at the root *.
  • A token written child|ancestor repositions: it places child under the already-defined ancestor, letting one line express branched trees. Each token splits at most once on | — a|b|c is not valid shorthand.
  • Equivalent to the corresponding chain of region put commands; on error, regions placed before the failure remain (like a partial put chain).
  • It does not clear the existing tree: an existing name has its parent updated; region remove unwanted regions first if rebuilding.
  • One serial line, max 160 characters; split larger trees across multiple region def commands (the cursor resets to * between commands, so lead the next command with child|ancestor to reposition).
  • (b) Flood behavior follows region put v1.15+ semantics (flood enabled per defined region); confirm on-device with region dump after configuring.

Fallback: on v1.15.0, use the equivalent region put chain (one line shown per region, put <child> <parent>); on v1.14.x additionally region allowf <name> per region.

Vancouver — Coal Harbour (Metro Vancouver):

region def can bc mvrd
region save

Tags: can,bc,mvrd (12 bytes). Optional PNW/community participation, second line:

region def west pnw swbc|bc salishmesh|bc
region save

Tags become: can,bc,mvrd,west,pnw,swbc,salishmesh (37 bytes — well within the 172-byte budget).

Victoria (Capital RD + South Island community):

region def can bc crd vanisle|bc southisland
region save

Tags: can,bc,crd,vanisle,southisland (31 bytes). vanisle|bc branches back under bc; southisland then chains under vanisle.

Lloydminster (either side):

region def can ab lloyd sk|can
region save

Tags: can,ab,sk,lloyd (16 bytes). The lloyd parent (ab vs sk) is cosmetic; SK-side operators may prefer region def can sk lloyd ab|can.

Ottawa:

region def can on s-on ott ncr|on
region save

Tags: can,on,s-on,ott,ncr (20 bytes).

Gatineau:

region def can qc out ncr|qc
region save

Tags: can,qc,out,ncr (15 bytes).

Toronto:

region def can on s-on tor
region save

Tags: can,on,s-on,tor (16 bytes).

Halifax:

region def can ns hfx
region save

Tags: can,ns,hfx (11 bytes).

Every example above is far under the 160-character line limit; even the longest realistic Canadian config (full BC ancestry plus PNW and community tags) fits in two region def lines.

Scoping Behavior

Scope on message Forwarded by
(none) Unscoped/legacy flood (root * policy)
can Every repeater in Canada carrying can
bc, on, qc, … Provincial/territorial scope
s-on, n-on Ontario halves
mvrd, tor, hfx, … Regional scope
lloyd, ncr Bi-provincial communities, both sides
salishmesh, pnw Cross-border communities, both countries

Budgets stay comfortable: the deepest ancestry in this scheme is five tags (can,on,s-on,ott,ncr = 20 bytes of the 172-byte response budget; max 32 regions per repeater).

Adoption Notes

  • This is a proposal, offered in the same spirit as the PNW strategy: published naming is the coordination mechanism, since transport keys derive from names.
  • Provincial and community groups own their subtrees. Hub-region boundaries in AB/SK/MB/NL/YT are deliberately fuzzy — repeaters self-assign to their natural hub — and locals should adjust names that don’t ring true; just register changes against the Collision Register.
  • BC community tags predate this document and take precedence in their areas; the regional-district tags add systematic coverage, they don’t replace community identity.
  • Coordinate new cross-border tags with the neighbouring scheme’s maintainers before deploying.

Repeater Configuration Examples

Examples use region def (firmware v1.16+), which builds the whole hierarchy in a single line.

region def syntax (a — official CLI reference):

  • Tokens are processed left to right; each token becomes a child of the previous one (a linear chain). The cursor starts at the root *.
  • A token written child|ancestor repositions: it places child under the already-defined ancestor, letting one line express branched trees. Each token splits at most once on | — a|b|c is not valid shorthand.
  • Equivalent to the corresponding chain of region put commands; on error, regions placed before the failure remain (like a partial put chain).
  • It does not clear the existing tree: an existing name has its parent updated; region remove unwanted regions first if rebuilding.
  • One serial line, max 160 characters; split larger trees across multiple region def commands (the cursor resets to * between commands, so lead the next command with child|ancestor to reposition).
  • (b) Flood behavior follows region put v1.15+ semantics (flood enabled per defined region); confirm on-device with region dump after configuring.

Fallback: on v1.15.0, use the equivalent region put chain (one line shown per region, put <child> <parent>); on v1.14.x additionally region allowf <name> per region.

Vancouver — Coal Harbour (Metro Vancouver):

region def can bc mvrd
region save

Tags: can,bc,mvrd (12 bytes). Optional PNW/community participation, second line:

region def west pnw swbc|bc salishmesh|bc
region save

Tags become: can,bc,mvrd,west,pnw,swbc,salishmesh (37 bytes — well within the 172-byte budget).

Victoria (Capital RD + South Island community):

region def can bc crd vanisle|bc southisland
region save

Tags: can,bc,crd,vanisle,southisland (31 bytes). vanisle|bc branches back under bc; southisland then chains under vanisle.

Lloydminster (either side):

region def can ab lloyd sk|can
region save

Tags: can,ab,sk,lloyd (16 bytes). The lloyd parent (ab vs sk) is cosmetic; SK-side operators may prefer region def can sk lloyd ab|can.

Ottawa:

region def can on s-on ott ncr|on
region save

Tags: can,on,s-on,ott,ncr (20 bytes).

Gatineau:

region def can qc out ncr|qc
region save

Tags: can,qc,out,ncr (15 bytes).

Toronto:

region def can on s-on tor
region save

Tags: can,on,s-on,tor (16 bytes).

Halifax:

region def can ns hfx
region save

Tags: can,ns,hfx (11 bytes).

Every example above is far under the 160-character line limit; even the longest realistic Canadian config (full BC ancestry plus PNW and community tags) fits in two region def lines.

Scoping Behavior

Scope on message Forwarded by
(none) Unscoped/legacy flood (root * policy)
can Every repeater in Canada carrying can
bc, on, qc, … Provincial/territorial scope
s-on, n-on Ontario halves
mvrd, tor, hfx, … Regional scope
lloyd, ncr Bi-provincial communities, both sides
salishmesh, pnw Cross-border communities, both countries

Budgets stay comfortable: the deepest ancestry in this scheme is five tags (can,on,s-on,ott,ncr = 20 bytes of the 172-byte response budget; max 32 regions per repeater).

Adoption Notes

  • This is a proposal, offered in the same spirit as the PNW strategy: published naming is the coordination mechanism, since transport keys derive from names.
  • Provincial and community groups own their subtrees. Hub-region boundaries in AB/SK/MB/NL/YT are deliberately fuzzy — repeaters self-assign to their natural hub — and locals should adjust names that don’t ring true; just register changes against the Collision Register.
  • BC community tags predate this document and take precedence in their areas; the regional-district tags add systematic coverage, they don’t replace community identity.
  • Coordinate new cross-border tags with the neighbouring scheme’s maintainers before deploying.

Go for it! That said, why trim anything out? They don’t have to be used today, it’s about full coverage.

1 Like