OSINT tool research: MailAccess → Identity Domain Server capabilities #181

New issue

Open

opened 2026-08-29 10:28:08 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-08-29 10:28:08 +00:00

Owner

Goal

Deeply research KatrielMoses/MailAccess as a source of reusable OSINT capability patterns for StarIntel. Do not clone MailAccess wholesale and do not create one actor per upstream module.

Architecture rule

Map useful behavior into a coherent Identity Domain Server. Existing StarIntel user-hunt / WhatsMyName behavior should become a capability/provider within that domain rather than remain the architectural boundary.

Cross-domain behavior (for example DNS, WHOIS, Shodan-style infrastructure enrichment) should invoke the appropriate domain server instead of being duplicated inside Identity.

Required feature enumeration

Research and verify the upstream implementation/docs for at least:

investigation orchestration and module fan-out
username/account discovery engines and registries
email identity enrichment and alternate-address discovery
identity graph and confidence/correlation behavior
public-profile pivots
breach / credential-exposure sources and normalization
phone and messaging pivots
false-positive controls
provider health, rate limits, timeout, caching, and partial-result behavior
provenance and deduplication semantics
reporting/export/interoperability

The initial internal enumeration is recorded in roam/internal/OSINT-TOOLS-LEDGER.org.

Candidate capability families

These are research hypotheses, not approved design:

identity.enumerateAccounts
identity.enrichEmail
identity.resolveIdentity
identity.findPublicProfiles
identity.checkExposure
identity.pivotContacts

Implementation preference

StarLang
Extend StarLang if a required semantic/runtime primitive is missing
Common Lisp library/adapter
Python only if StarLang + Common Lisp cannot reasonably provide or wrap the dependency

StarLang questions

Determine whether StarLang currently supports or needs extensions for:

bounded concurrent fan-out over a dynamic provider registry
typed partial-result envelopes
deadlines, timeouts, bounded retries, and cancellation
provider health state and automatic demotion
periodic registry refresh
evidence/confidence aggregation
cross-domain calls
provenance-preserving deduplication
durable/resumable investigation state

Output gate

Do not modify or mark an ARARD/ARADR conclusion approved from this issue until explicit human instruction to add research. This issue and the internal ledger are staging material only.

## Goal Deeply research `KatrielMoses/MailAccess` as a source of reusable OSINT capability patterns for StarIntel. Do **not** clone MailAccess wholesale and do **not** create one actor per upstream module. ## Architecture rule Map useful behavior into a coherent **Identity Domain Server**. Existing StarIntel `user-hunt` / WhatsMyName behavior should become a capability/provider within that domain rather than remain the architectural boundary. Cross-domain behavior (for example DNS, WHOIS, Shodan-style infrastructure enrichment) should invoke the appropriate domain server instead of being duplicated inside Identity. ## Required feature enumeration Research and verify the upstream implementation/docs for at least: - investigation orchestration and module fan-out - username/account discovery engines and registries - email identity enrichment and alternate-address discovery - identity graph and confidence/correlation behavior - public-profile pivots - breach / credential-exposure sources and normalization - phone and messaging pivots - false-positive controls - provider health, rate limits, timeout, caching, and partial-result behavior - provenance and deduplication semantics - reporting/export/interoperability The initial internal enumeration is recorded in `roam/internal/OSINT-TOOLS-LEDGER.org`. ## Candidate capability families These are research hypotheses, not approved design: - `identity.enumerateAccounts` - `identity.enrichEmail` - `identity.resolveIdentity` - `identity.findPublicProfiles` - `identity.checkExposure` - `identity.pivotContacts` ## Implementation preference 1. StarLang 2. Extend StarLang if a required semantic/runtime primitive is missing 3. Common Lisp library/adapter 4. Python only if StarLang + Common Lisp cannot reasonably provide or wrap the dependency ## StarLang questions Determine whether StarLang currently supports or needs extensions for: - bounded concurrent fan-out over a dynamic provider registry - typed partial-result envelopes - deadlines, timeouts, bounded retries, and cancellation - provider health state and automatic demotion - periodic registry refresh - evidence/confidence aggregation - cross-domain calls - provenance-preserving deduplication - durable/resumable investigation state ## Output gate Do not modify or mark an ARARD/ARADR conclusion approved from this issue until explicit human instruction to **add research**. This issue and the internal ledger are staging material only.

nsaspy referenced this issue

2026-08-29 10:28:16 +00:00

OSINT cluster research: email-account existence and Google identity pivots #179