avirn-server 0.1.0

HTTP server and OSINT adapters for Avirn.
Documentation

Avirn

Avirn turns open-source OSINT tools into one understandable, pay-per-investigation report.

Enter what you know: a username, email, phone, profile URL, image, website, or suspicious message. Avirn checks public information across the web, removes false positives, correlates findings, and tells you what it means in plain language.

No setup. No Python. No API keys. No subscription trap.

What you can check

  • A person or account : Is this dating profile, seller, or social account real?
  • A username : Where else does it appear?
  • An image : Has it been stolen, reused, or generated by AI?
  • A website or link : Is it a scam, phishing site, or brand-new domain?
  • An email or message : Is the sender spoofing someone? Is the text AI-generated?
  • Your own exposure : What public information is connected to you?

Inputs

Avirn accepts one or more of these at a time:

  • Username
  • Full name (limited use; usernames and emails are stronger identifiers)
  • Email address
  • Phone number
  • Profile URL
  • Website, listing, or message URL
  • Image or screenshot
  • Raw email file (.eml)
  • Wallet address or ENS name

Outputs

Every report returns the same thing: a confidence-ranked answer, not a dump of raw data.

  • Matching public accounts and profiles
  • Reused images, bios, or listing descriptions
  • Conflicting identity claims
  • Domain and account history
  • Publicly connected websites or contact details
  • Suspicious patterns and scam indicators
  • Confidence labels: confirmed, likely, inconclusive, unrelated
  • Direct links to public evidence
  • Downloadable evidence report

How Avirn works

  1. You enter one identifier.
  2. Avirn dispatches the right set of open-source tools in parallel.
  3. Each tool returns normalized evidence.
  4. Avirn correlates results across tools and removes false positives.
  5. You get a short report in plain language with confidence labels.

Example:

The username jessica_m_92 appears on 14 public platforms. The profile photo appears on a stock-image site and a separate Facebook account under a different name. The linked website was registered 11 days ago. Overall: this profile is likely fake.

Tools Avirn wraps

Tools are organized by the identifier they consume. Avirn runs only public, passive checks. It never logs into another platform as a user.

Username checks

  • Sherlock : fast presence check across ~400 platforms.
  • Maigret : deeper username search with profile metadata extraction.
  • WhatsMyName : community-maintained username enumeration database.

Email checks

  • Holehe : registration checks across platforms via password-reset flows.
  • theHarvester : email and subdomain discovery from public sources.
  • GHunt : Google account metadata pivot (handled carefully; TOS-sensitive).
  • Have I Been Pwned : breach exposure check via k-anonymity API.

Phone checks

  • PhoneInfoga : footprint search and carrier type (often via maintained Apify actors).
  • Public carrier/number validation APIs.

Image checks

  • Google Images, Yandex, Bing, TinEye : reverse image search.
  • Lenso.ai : AI-powered visual match search.
  • AI-generated image detectors : local or API classifiers for synthetic faces.

Domain / URL checks

  • URLScan : safe link inspection.
  • VirusTotal : domain and URL reputation.
  • WHOIS : registration history.
  • crt.sh : SSL certificate transparency logs.
  • Wayback Machine : historical snapshots.

Message and file checks

  • ExifTool : image and document metadata extraction.
  • SPF/DKIM/DMARC validators : email authentication checks.
  • AI text detectors : synthetic message or bio detection.
  • PDF metadata / embedded URL extractors : suspicious document forensics.

All-in-one recon

  • SpiderFoot : orchestrated multi-source reconnaissance.

Crypto / Web3

  • Etherscan, Chainabuse, MistTrack-style APIs : flagged wallet addresses and scam reports.

Core use cases

These are the first problems Avirn solves.

Use case Input Question it answers
Dating profile check Username, photo, profile URL Is this person real or a romance scam?
Marketplace seller check Seller username, listing URL, photo Is this seller or listing legitimate?
Suspicious message check Message text, email headers, link Is this a phishing or scam message?
Username lookup Username Where else does this username appear?
Reverse image check Image Is this photo stolen, reused, or AI-generated?
Website legitimacy check URL Is this site a scam, phishing domain, or brand impersonator?
Self-exposure audit Email, username What public information is connected to me?

Creative use cases to add later

Avirn can wrap the same primitives in different workflows.

Use case Why it fits
AI-generated photo detection Scammers increasingly use fully synthetic faces.
AI-generated text detection Scripted romance messages and fake seller bios are often AI-written.
Puppy / pet scam check Fake breeder listings use stolen photos and new domains.
Ticket resale scam check Duplicate listings, urgent payment requests, and fresh seller accounts.
Vacation rental scam check Stolen listing photos and host identity mismatches.
Fake invoice / payment scam check PDF metadata, embedded URLs, and sender spoofing.
Real estate rental scam check Duplicate photos across cities and too-good pricing.
Fake recruiter / job scam check Spoofed domains, LinkedIn inconsistencies, AI-written job posts.
Tech support / phishing call check Caller number type and callback URL reputation.
Gift card / recovery scam check Message urgency patterns and payment pressure signals.
QR code safety check Expand short URLs and scan redirect chains.
Email header forensics .eml upload with SPF/DKIM/DMARC and IP geolocation.
Fake LinkedIn / professional profile check Photo reuse, job title consistency, and company existence.
Impersonation / brand protection check Typosquats, fake social accounts, logo reuse.
Influencer / follower fraud check Engagement rate vs follower count and comment authenticity.
Fake charity / crowdfunding check Organizer identity, duplicate campaigns, image reuse.
Personal / family online exposure check Public accounts and image leaks from EXIF metadata.
Crypto scam address check Flagged wallet addresses and contract audit status.
Document forensics check PDF metadata, embedded URLs, creation software.
Wedding vendor / photographer scam check Stolen portfolios, high deposits, and remote-only contact.
Freelance / gig platform scam check Fake client portfolios and escrow tricks.

Competitive landscape

Competitor What they do Where Avirn differs
Social Catfish Reverse-image and dating-profile verification Subscription trap, staged progress bars, limited correlation. Avirn is pay-per-report, transparent, and correlates across sources.
Spokeo U.S. public records / people search Address and court records, not real-time digital footprint correlation.
Pipl Identity resolution Enterprise-only, expensive contracts, no consumer self-serve.
OSINT Industries, UserSearch, Epieos Professional-grade lookups Powerful but technical and API-driven, not packaged for consumers.
PimEyes / FaceCheck.ID / ProFaceFinder Face recognition search Expensive, privacy-sensitive, limited consumer transparency.

Avirn's moat is not inventing scanners. It is combining existing scanners, removing false positives, correlating results, and explaining findings in ordinary language.

Website and SEO structure

Avirn's site is organized by the user's problem, not by tool name. It follows the lean-hub pattern used by wide-service consumer sites: the homepage only routes, and each use-case has its own dedicated landing page that carries the detail and ranks for that intent's searches.

  • Homepage (/) is a router, not a catch-all. A single rotating hook, the universal check widget, and six category cards that each link to a landing page. It deliberately does not explain every service.
  • Landing pages (/check/*) are the per-use-case funnels. Each is a complete page (fear-specific hero, tailored sample report, recognition, a tool-specific detail section, how-it-works, privacy, and its own CTA) and is the canonical destination for ads and search. Each also carries its own accent color so it reads as its own tool while sharing one design system. This is the structure the broad tool-collection companies use (Adobe's Acrobat online tools, Smallpdf, iLovePDF, Canva): one domain, one dedicated path per use-case, and no per-tool subdomains.
/                         lean hub: rotating hook + 6 category cards
├── /check/               directory of every check
│   ├── /check/dating-profile
│   ├── /check/marketplace-seller
│   ├── /check/suspicious-message
│   ├── /check/website
│   ├── /check/username
│   ├── /check/reverse-image
│   └── /check/my-exposure
├── /search/             report-generation / loading page (query-driven)
├── /sample-report/      example report
├── /pricing/
├── /blog/
└── /safety/             safety and legal

Use-case landing pages

URL Headline
/check/dating-profile Is this online dating profile real?
/check/marketplace-seller Is this seller or listing legitimate?
/check/suspicious-message Is this message or link a scam?
/check/username Where else does this username appear?
/check/reverse-image Is this image stolen or fake?
/check/website Is this website or business trustworthy?
/check/my-exposure What public information is connected to me?

Website files

Static site source lives in website/. All pages share style.css and avirn.js:

  • website/index.html : lean hub home page. It is a router, not a catch-all: a two-column editorial hero (a rotating "Is this ___ for real?" hook, the universal check widget, and an example .report on the right), six category cards that each link to a landing page, how-it-works, privacy, and a pricing CTA. Detail lives on the landing pages, not here
  • website/check/*/index.html : each check page is its own complete funnel with the same left-aligned two-column layout: a fear-specific hero and check widget, a tailored sample .report, a "sound familiar?" recognition section, a tool-specific detail section (.detail), a "what this check does" checklist, a privacy strip, and its own CTA plus related-check links. Each page sets a tool-<slug> body class that gives it a distinct accent color (defined in style.css), so it reads as its own tool
  • website/style.css : shared two-register design system. Warm consumer shell (system-font sans, soft warm palette, cards and shadows, left-aligned editorial layout, no gradients) for the landing and funnels; a monospace-flavored technical .report component for evidence and confidence chips. Light-first, no build step, no external assets
  • website/avirn.js : tab switching, search loader, live .report rendering (shared reportComponent), the investigation-console controller, and client-side EXIF via WASM
  • website/tools/username/index.html : the username investigation console. A two-panel dashboard, a sticky parameters form (the handle, repeatable aliases, email, real name, location, and data-driven source scopes) with a live coverage meter, and a results panel that streams each source as it is checked and renders the merged, calibrated report. The /check/username/ page hands off to it, carrying ?q=
  • website/check/index.html : use-case directory
  • website/check/dating-profile/index.html : dating profile check
  • website/check/marketplace-seller/index.html : marketplace seller check
  • website/check/reverse-image/index.html : reverse image / AI-generated photo check
  • website/check/suspicious-message/index.html : suspicious message / email check
  • website/check/username/index.html : username lookup
  • website/check/website/index.html : website legitimacy check
  • website/check/my-exposure/index.html : self-exposure audit
  • website/pricing/index.html : pricing page
  • website/safety/index.html : safety and legal page
  • website/search/index.html : report generation / loading page
  • website/sample-report/index.html : example report page
  • website/blog/index.html : blog index
  • website/blog/template.html : modular post template; copy and replace placeholders
  • website/blog/dating-profile-red-flags/index.html : post, spotting a fake dating profile
  • website/blog/verify-facebook-marketplace-seller/index.html : post, verifying a marketplace seller
  • website/blog/reverse-image-search-dating/index.html : post, reverse image searching a photo
  • website/blog/find-public-information-about-me/index.html : post, self-exposure audit
  • website/blog/suspicious-link-check/index.html : post, checking a link safely

New posts are added by copying template.html into a new directory and replacing placeholders. No build step is required.

The frontend is a static shell served by avirn-server. Landing-page search forms submit to /search/ for a quick single-identifier report; the username funnel opens the full investigation console at /tools/username/, which calls the real /api/check and /api/username-sites endpoints. Reports are real and confidence-ranked, produced by the wired backend adapters (github_username, username_sites, http_probe).

Blog content clusters

Cluster Example posts
Dating safety How to spot a fake dating profile; signs of a romance scam
Marketplace fraud How to verify a seller on Facebook Marketplace; Craigslist red flags
Image / catfish How to reverse image search a dating photo; why your photo might be used by a scammer
Username / identity How to find social media accounts from a username
Self-exposure How to find what personal information is public online
Scam education Why scammers ask to move to WhatsApp; how to check a suspicious link safely

Business model

  • Limited free check: one free username or URL check to prove value.
  • Pay per complete investigation: roughly $3–$5 per full report.
  • Optional low-cost subscription: for users who run repeated checks.
  • No API keys. No technical setup.
  • Local processing where practical; server-side only where required.

Client-side inference

Some checks run in the browser when they protect privacy, reduce server load, and do not need cross-origin access.

Check Why client-side works Implementation
Image metadata (EXIF) The file is already on the user's device. No upload needed. WASM or native JS parser.
AI-generated photo detection Face analysis can run locally without sending the image to a server. ONNX / TensorFlow.js model in the browser.
AI-generated text detection Message text is small and safe to analyze locally. Lightweight transformer or heuristic model.
QR code / shortlink expansion The URL can be expanded and checked without revealing the user's intent. Browser fetch with CORS-safe endpoints.
Perceptual hash for reverse image Compute locally, then send only the hash for search. WASM + Web Crypto API.
Public CORS-friendly endpoints Some platforms expose public, unauthenticated APIs that allow browser requests. Direct fetch from the browser when the endpoint is documented and public.

Why most checks still run server-side

Avirn uses only public data and documented endpoints. It does not use private or unofficial APIs. Even so, several factors push most work to the server.

  • Aggregation and correlation. A report combines results from many tools. Doing that correlation client-side would expose every adapter to the browser and leak intermediate findings.
  • Rate limiting and IP rotation. Many public endpoints rate-limit by IP. Running hundreds of checks from each user's IP would get users blocked. A server pool handles throttling and rotation.
  • Platforms without public CORS-friendly endpoints. Twitter/X, Instagram, Facebook, and TikTok do not offer unauthenticated profile lookup APIs with permissive CORS. The server fetches the same public pages a browser would, then parses them.
  • Headless scraping. Sherlock and Maigret target sites that only expose HTML. Those adapters run on the server.
  • Reverse image search engines. Google, Yandex, and Bing image search are not callable from client JavaScript.
  • Sensitive keys for commercial data sources. Some lookups (VirusTotal, URLScan, phone carrier databases, breach APIs) may require keys. Those keys stay on the server. Avirn never uses undocumented or private endpoints.

The UI explains which parts of a report ran locally and which reached the server, but it does not treat client-side processing as a selling point.

Architecture overview

Consumer input
    |
[1] Intent router  (dating? seller? self-audit?)
    |
[2] Parallel job dispatch  (one job per tool adapter)
    |
[3] Adapter layer  (each OSS tool -> normalized JSON)
    |
[4] Correlation engine  (find conflicts and links)
    |
[5] Confidence scorer  (confirmed / likely / inconclusive / unrelated)
    |
[6] Report generator  (plain language + evidence links + PDF)

Design rules

  • Every adapter returns the same shape: source_type, identifier, url, evidence, observed_at, confidence, raw.
  • Tools run sandboxed. Many do headless scraping.
  • A failing tool reports degraded; it never silently falls back to weaker data.
  • No tool logs into another platform as a user.
  • All actions are passive public checks.

Roadmap

Phase Deliverable
MVP Username + reverse image + URL safety report for dating and marketplace checks
Phase 2 .eml header analysis, AI-generated photo/text detection, QR/shortlink expansion, rental scams
Phase 3 Crypto address checks, fake job/recruiter checks, influencer fraud, document forensics
Phase 4 Pet/ticket scams, brand protection, data-broker opt-out prep, wedding/freelance scams

Legal and safety guardrails

  • Avirn is not a consumer reporting agency. It does not perform FCRA-regulated background checks.
  • Avirn is not for employment, housing, credit, or legal decisions.
  • Avirn performs only passive, public checks. It does not log into third-party platforms.
  • Avirn does not notify the person being searched.
  • Results use confidence labels. Avirn never states "this person is a scammer"; it reports public evidence and patterns.
  • Users are responsible for complying with local privacy laws, including GDPR and CCPA, when interpreting and acting on reports.

Brand voice

  • Plain language over jargon. The word "OSINT" never appears to end users.
  • Example-first. Show the report, not the tool names.
  • Honest about limits. "We could not verify" is better than a false connection.
  • No subscription traps. No staged progress bars. No fake urgency.

Contributing

This project is built incrementally. Open a pull request for any of these:

  • New tool adapters
  • New use-case pages
  • Better confidence scoring
  • Report templates
  • Blog posts and SEO content

Rust workspace

Avirn is built in Rust.

  • crates/avirn-core: Input, Finding, Report, Confidence, Adapter trait, and Registry.
  • crates/avirn-server: Axum server, adapters, and static file serving.
  • crates/avirn-wasm: WebAssembly helpers for client-side checks (EXIF extraction).

Current adapters

Adapter Input What it does
github_username Username Calls the public GitHub Users API. Returns profile existence and public metadata (depth).
username_sites Username Searches the username across a catalog of public platforms at once (breadth). See below.
http_probe Url Resolves the host via DNS and runs an HTTP HEAD probe, recording status and redirects.

The username_sites engine

The list of places a username check looks is Tier-B data, not code. It lives in crates/avirn-server/rules/username_sites.json, one entry per platform:

{ "name": "GitHub", "category": "developer", "profile_url": "https://github.com/{}" }

{} is the username placeholder. exists_code/missing_code default to 200/404. For sites that answer 200 even for a missing account (a soft-404), set missing_string (present in the body when the account does not exist) or exists_string (present only when it does); check_url overrides the URL that is fetched when it differs from the human profile URL. Drop more *.json files whose names start with username_sites into AVIRN_RULES_DIR to extend the catalog; they merge on top of the built-in set (last definition of a name wins).

The adapter probes every site concurrently and, crucially, calibrates each one: alongside the real handle it probes a control handle of the same length and character classes that is almost certainly unregistered. If a site reports the control as present, its existence signal is worthless (it answers 200 for any valid-looking name), so the site is marked unreliable and skipped rather than emitting a false positive. Every site that is skipped, blocked, unreachable, or unreliable is named in a loud coverage line in the report, so the search never narrows silently.

GET /api/username-sites returns the catalog grouped by category (with counts); the username tool's "where to look" scopes and platform lists are generated from it, so the UI and the engine can never disagree about what is searched.

Running locally

Build and run the server. It serves the static website/ directory and the JSON API on port 3000.

cargo run --bin avirn-server
# or, with a shared target directory:
/mnt/FlareTraining/santh-archive/cargo-target/debug/avirn-server

Test an investigation:

curl 'http://127.0.0.1:3000/api/check?q=octocat&type=username'
curl 'http://127.0.0.1:3000/api/check?q=https://github.com&type=url'

Environment variables:

Variable Default Purpose
AVIRN_WEBSITE_DIR website Directory of the static site to serve.
AVIRN_RULES_DIR (unset) Directory of extra Tier-B data files. username_sites*.json here extend the platform catalog.
AVIRN_USERNAME_CONCURRENCY 24 Maximum simultaneous site probes for a username check.
AVIRN_USERNAME_TIMEOUT_SECS 8 Per-site probe timeout for a username check.

Build the client-side WASM helper:

wasm-pack build crates/avirn-wasm --target web --out-dir ../../website/pkg

The server does not auto-reload the static site or recompile the WASM. Rebuild either before testing.

Verification

  • cargo check and cargo build pass for the workspace.
  • /api/health returns ok.
  • /api/check?q=octocat&type=username returns a real report: GitHub profile metadata plus a calibrated sweep across the platform catalog, ending in a coverage line.
  • /api/check?q=https://github.com&type=url returns DNS and HTTP probe findings.
  • /api/username-sites returns the platform catalog grouped by category.
  • /search/?q=octocat&type=username renders the report in the browser.
  • The reverse-image page loads website/pkg/avirn_wasm.js and extracts EXIF locally.