dsh-peer-sessions

Configuration

The thresholds are yours to tune, from the plugin's composition row:

- id: dsh-peer-sessions
  name: dsh-peer-sessions
  config:
    hopLimit: 5
    rateLimit: 60
    rateWindowMs: 60000
    channelBudget: 500
    inboxLimit: 100
    requestMemory: 1000
    pendingGraceMs: 86400000
    hopMemoryMs: 900000
    maxCandidates: 8
    recentTurns: 3
    previewMaxChars: 200

Field	Default	What it bounds
hopLimit	3	How far a chain may be relayed across conversations before it is refused
rateLimit / rateWindowMs	30 / 60000	Deliveries one pair may make inside a fixed window
channelBudget	200	Lifetime deliveries on one channel
hopMemoryMs	900000	How long an inbound message keeps counting as "the one being answered"
inboxLimit	50	Inbox items retained per conversation
requestMemory	500	How many request issuers are remembered for the reply-direction check
pendingGraceMs	86400000	How long an unanswered request keeps being reported
maxCandidates	8	Conversations listed before an ambiguous-title refusal summarises
recentTurns	3	Trailing turns peer_progress summarises
previewMaxChars	200	Cap on one preview line in peer_progress

Two things worth knowing before you edit it:

• A row's config replaces the whole object — it is not merged. Naming one field is fine (the rest come from the schema's declared defaults, and a test pins that), but when layers override the same row, the later config object wins entirely. If you set these from two places, list every field you want to keep in the later one.
• Every field has a default. A field without one would make an omitted config a validation failure, and a plugin that fails validation is a warning at startup, not an error: the profile boots with this plugin silently missing. The defaults are the values in the table above, so omitting config entirely is always safe.