Docs: recommend a standard key-file location on Windows

[chirag127]

@

Version

age v1.3.1 (Windows binary).

Problem

On Unix, the community convention is to store the identity file at ~/.age/key.txt (or similar under $XDG_CONFIG_HOME). On Windows there is no analogous guidance in the README or man page, so users invent their own conventions — I have seen %USERPROFILE%\.age\, %APPDATA%\age\, %LOCALAPPDATA%\age\, and ad-hoc paths inside project folders in the wild.

This matters because:

• Third-party tooling (backup scripts, dotfile managers, plugins) cannot assume where the key lives.
• Users often end up putting the identity in a synced folder (OneDrive, Dropbox) by accident because they had no default to reach for.
• Age itself does not consult any default path — every invocation needs -i <path> — so the lack of a documented convention has zero code cost to fix; it is a docs-only ask.

Suggestion

Add a short section to the README (or the age(1) man page) recommending:

• %USERPROFILE%\.age\key.txt as the mirror of the Unix convention, OR
• %APPDATA%\age\key.txt if you prefer the Known Folder route (matches gpg4win, git-credential-manager)

Either is fine — the value is picking one so ecosystem tools can rely on it. If age eventually grows a default-identity lookup (analogous to ssh -i fallbacks), the same path would be the natural default.

Alternatives considered

• Doing nothing and letting each downstream tool pick. This is the status quo and has produced the fragmentation described above.
• Documenting both paths and letting the user pick. Better than nothing but does not solve the "tools cannot assume" half of the problem.

Happy to open a docs PR if the maintainers pick a path.
@

[FiloSottile]

This is intentional. The preferred key management strategy is documented at https://pkg.go.dev/filippo.io/age#hdr-Key_management.

Encryption keys are different from e.g. SSH keys in that there is not much value in having the same key across applications and services, because there is no identity to bind. Encryption keys also can't be rotated (with respect to existing files) so it's important to be able to manage keys with different purposes and lifetimes separately.