feature request

[learner960]

segregating multiple domains into their respective root domains / organisation name for scanning them in concurrency. Currently, for eg - osmedeus treats ui.com and uisp.com as different entity and scans them concurrently which may hit rate limit. a feature where ubiquiti is running in one concurrency and apple.com is running in another concurrency. Essentially running concurrent scans by organisation and not by individual domain names. The only way to achieve this right now is having multiple osmedeus runs with seperate targets.txt file (segregated by organisation name)

[j3ssie]

I'm not sure what is the motivation here but you can run individual scan with single input like -t example.com via the queue with different concurrency since the threads is dynamic via

-B, --tactic string               run tactic: aggressive, default, gently (default "default")
# you can set the tactic threads like this
osmedeus config set scan_tactic.default 20

Or using this simple queue https://github.com/justanhduc/task-spooler to queue your

if you want to store it in a big folder together then you can use -p '{{Workspaces }}=/tmp/something-new/ from this https://docs.osmedeus.org/reference/variables#built-in-variables

[learner960]

Breaking Down the Issue & Response

The Problem Being Raised

The user is requesting organisation-aware concurrency grouping in Osmedeus. The core issue:

• ui.com and uisp.com both belong to Ubiquiti
• apple.com and apple.co.uk both belong to Apple
• Osmedeus currently treats each domain as an independent entity and scans them concurrently across organisations
• This means two Ubiquiti domains may fire requests simultaneously → hitting rate limits or triggering WAF/blocks on Ubiquiti's infrastructure

What the user wants:

Organisation A (Ubiquiti) → [ui.com, uisp.com, unifi.com]  ← scanned sequentially/controlled within group
Organisation B (Apple)    → [apple.com, apple.co.uk]        ← scanned sequentially/controlled within group
Both organisations run concurrently with each other ✓

But domains within the same org are rate-limited together ✓

---

What the Maintainer (j3ssie) Responded

The maintainer's suggestion is essentially a workaround, not a feature implementation:

Suggestion	What it does	Does it solve the issue?
-B --tactic with scan_tactic.default	Controls thread count per scan	❌ Still per-domain, not per-org
task-spooler queue	Queues individual scans one at a time	⚠️ Partially — but serialises everything, no cross-org concurrency
-p '{{Workspaces}}'	Groups output into a shared folder	❌ Only affects storage, not scan logic

The maintainer misunderstood or sidestepped the core ask — the user isn't asking about thread counts, they're asking about grouping targets by org before scheduling.

---

The Only Current Workaround (as the user correctly identified)

bash

# targets_ubiquiti.txt       # targets_apple.txt
ui.com                        apple.com
uisp.com                      apple.co.uk
unifi.com                     icloud.com
Run separately
osmedeus scan -f targets_ubiquiti.txt &

osmedeus scan -f targets_apple.txt &

This achieves the goal but requires manual org segregation and multiple process management outside Osmedeus.

---

What a Proper Implementation Would Look Like

A feature request response could propose something like:

yaml

# targets.yaml  (proposed format)
organisations:
  - name: ubiquiti
    concurrency: 1        # only 1 domain at a time within this org
    domains:
      - ui.com
      - uisp.com
  - name: apple
    concurrency: 2
    domains:
      - apple.com
      - apple.co.uk

Or a simpler flat format with tags:

ui.com #ubiquiti
uisp.com #ubiquiti
apple.com #apple

The scanner would then group by tag → run one goroutine/worker pool per org rather than per domain.

---

Summary

The maintainer's response suggests they see this as a workflow/configuration concern, but the real feature request is about scan scheduling logic — a non-trivial internal change. The workaround of multiple targets.txt files is valid but operationally painful at scale (e.g., 50 orgs in a bug bounty program).