# Web discovery and safe secrets notes

This reference captures the practical patterns that worked when building local web-collection apps.

## Search/discovery provider behavior

- Bing RSS was usable from the local Linux machine via:
  - `https://www.bing.com/search?format=rss&q=...`
- In practice, Bing RSS returned structured XML with stable `<item>` entries containing:
  - `<title>`
  - `<link>`
  - `<description>`
- Direct requests to some listing sites often returned challenges or 403s, so search results and snippets were a better discovery layer than raw page scraping.
- DuckDuckGo HTML was less reliable in this environment for structured extraction than Bing RSS.

## Result parsing shape

A simple RSS parser is often enough:
- parse the XML root
- iterate over `./channel/item`
- read title, link, description
- score items with pure functions

## Query construction

Useful query shape for nearby-local searches:
- include a property type phrase like `maison à vendre`
- search the center city and nearby communes separately
- keep a broader catch-all query for the whole area
- avoid overfitting to one listing site if the provider is unstable

## Safe credential pattern

For desktop Linux tools that need secrets:
- prompt locally with `zenity --password` if available
- encrypt the stored payload with `gpg --symmetric --cipher-algo AES256`
- keep the vault under `~/.config/<app>/credentials.gpg`
- ensure directory permissions are `700` and file permissions are `600`
- only decrypt into memory right before connecting

## Verification pattern

- unit test parsers first
- then hit the live search endpoint
- then open the local UI and confirm it renders results
- keep a `/health` endpoint for fast readiness checks
