Hashavatar 0.10.0

hashavatar 0.10.0

0.10.0 introduces the visual layer model while keeping the existing
AvatarOptions rendering path stable.

Added

• AvatarAccessory with none, glasses, hat, headphones, crown,
  bowtie, eyepatch, scarf, halo, and horns.
• AvatarColor with default, neon-mint, pastel-pink, crimson, gold,
  and deep-sea-blue.
• AvatarExpression with default, happy, grumpy, surprised, sleepy,
  winking, cool, and crying.
• AvatarShape with square, circle, squircle, hexagon, and octagon.
• AvatarStyleOptions for explicit kind, background, accessory, color,
  expression, and frame-shape selection.
• Style-aware raster, SVG, and encode APIs:
  • render_avatar_style_for_id
  • render_avatar_svg_style_for_id
  • encode_avatar_style_for_id
  • namespace and identity-options variants for each
• Automatic style APIs:
  • render_avatar_auto_for_id
  • render_avatar_svg_auto_for_id
  • encode_avatar_auto_for_id
  • namespace and identity-options variants for each
• Public digest-byte constants for automatic style derivation.
• Family-aware face anchors for accessory and expression placement.
• README option catalog covering all public enum values and the difference
  between AvatarOptions and AvatarStyleOptions.

Compatibility

Existing AvatarOptions output is unchanged. Legacy options map to
accessory = none, color = default, expression = default, and
shape = square.

Automatic style rendering is opt-in. It derives kind, background, accessory,
color, expression, and shape from distinct identity digest bytes using each
enum's ALL list.

Accessories and expressions are deterministic no-ops for non-face avatar
families where the layer cannot be placed sensibly. For example, paws with an
eyepatch renders the baseline paws avatar rather than placing a patch at an
arbitrary canvas position.

Security And Testing

• README security guidance now includes explicit caller-side zeroization and
  service-side render-concurrency examples for high-assurance deployments.
• Fuzz coverage now exercises the style-aware render and encode APIs.
• Golden fingerprints cover representative layered avatars and automatic style
  output.
• Tests enforce parser/display round trips, enum ALL drift protection,
  distinct automatic digest offsets, manual layer selection, and raster/SVG
  support for all baseline layer variants.
• Tests enforce deterministic no-op behavior for unsupported family/layer
  combinations.

Hashavatar 0.9.0

hashavatar 0.9.0

hashavatar 0.9.0 keeps the project as a single image-generation crate.

Highlights

• Bumped the crate to 0.9.0.
• Kept the public package as hashavatar only.
• Removed the near-term separate-core-crate direction from the roadmap.
• Kept deterministic identity hashing, public options, raster rendering, SVG
  rendering, and encoders together in the main crate.

Compatibility

• Raster/SVG output is intended to stay stable from 0.8.0.
• Existing render, SVG, encode, identity, and optional hash APIs are unchanged.
• There is no hashavatar-core crate to publish for this release.

Rationale

The project goal is avatar image generation. A separate public no_std + alloc
core crate would add release and API surface without serving that primary use
case. Lower-level planning boundaries can remain internal unless a future
image-generation feature needs them.

Hashavatar 0.8.0

hashavatar 0.8.0

hashavatar 0.8.0 prepares the crate for future core-boundary work without
adding new runtime dependencies or promising no_std support yet.

Highlights

• Bumped the crate to 0.8.0.
• Added an internal render plan used by raster, SVG, and encode paths.
• Changed public enum ALL lists from manually sized arrays to slices.
• Added from_byte helpers for deterministic enum selection:
  • AvatarHashAlgorithm::from_byte
  • AvatarKind::from_byte
  • AvatarBackground::from_byte
  • AvatarOutputFormat::from_byte
• Added tests that protect public enum parser/display behavior.
• Documented which dependencies belong outside a future no_std + alloc core.
• Added raw RGBA buffer budget constants and AvatarSpec helpers for callers
  that need service-level memory/concurrency controls.
• Hardened internal antialiasing channel blending against invalid weights.
• Zeroized temporary owned raster buffers after encode APIs finish encoding.
• Added a fixed-minimum-latency API wrapper example for callers that need to
  reduce render-time side-channel observability.

Compatibility

• Avatar rendering output is intended to stay stable from 0.7.0.
• Public enum ALL associated constants now have slice type
  &'static [Self] instead of fixed-size array types.
• Existing render, SVG, and encode entry points keep the same behavior.
• no_std is still only a future direction, not a supported public contract.

Security And Quality

• The dependency graph remains no larger than 0.7.0.
• Enum byte derivation uses ALL.len() rather than duplicated modulo counts.
• Tests cover parser/display round trips, documented enum label order, and
  byte-to-enum derivation.
• The internal render plan keeps deterministic avatar decisions separate from
  output encoding concerns.
• Rendering remains variable-time by design and should not be used as a
  secret-preserving timing boundary.
• Returned encoded bytes and images returned by render APIs are caller-owned;
  high-assurance callers should clear those buffers after use.
• Floating-point geometry remains a known future hardening target before the
  project claims formal bit-identical raster output across all platforms.

Hashavatar 0.7.0

hashavatar 0.7.0

hashavatar 0.7.0 starts the post-0.6 roadmap by making identity hashing explicit and extensible while keeping SHA-512 as the conservative default.

Highlights

• Added AvatarHashAlgorithm
• Added AvatarIdentityOptions
• Kept SHA-512 as the default identity hash
• Preserved the default SHA-512 identity preimage for existing callers
• Added optional BLAKE3 identity derivation behind the blake3 Cargo feature
• Added optional XXH3-128 identity derivation behind the xxh3 Cargo feature
• Added domain separation for non-default hash algorithms
• Added render, encode, and SVG entry points that accept identity hash options
• Added feature-gated tests for BLAKE3 and XXH3-128 rendering
• Hardened JPEG alpha flattening with wider arithmetic intermediates
• Hardened anti-aliased zero-length line drawing against NaN gradient propagation
• Added zeroize cleanup for derived identity digests and temporary identity hash preimage buffers
• Changed procedural cat RNG seeding to use 256 bits from the second half of the identity digest
• Added constant-time equality for AvatarIdentity
• Documented that rendering itself is not constant-time

Compatibility

• Existing callers that use AvatarIdentity::new, AvatarIdentity::new_with_namespace, render_avatar_for_id, render_avatar_for_namespace, render_avatar_svg_for_id, render_avatar_svg_for_namespace, encode_avatar_for_id, or encode_avatar_for_namespace continue to use SHA-512.
• Default SHA-512 rendering output is intended to remain stable from 0.6.0.
• BLAKE3 and XXH3-128 output is intentionally different from SHA-512 output.
• AvatarHashAlgorithm::Blake3 exists only when the blake3 feature is enabled.
• AvatarHashAlgorithm::Xxh3_128 exists only when the xxh3 feature is enabled.
• Cat-family output intentionally changes in 0.7.0 because procedural RNG
  seeding now uses a separate 256-bit digest slice instead of the low 64 bits
  that are also used by direct visual parameters.

Security And Quality

• SHA-512 remains the default for adversarial settings.
• BLAKE3 is provided by the upstream blake3 crate and uses dependency-provided acceleration where available.
• XXH3-128 is non-cryptographic and should only be used for non-adversarial identity distribution. Do not use it for adversarial or user-controlled identifiers unless the application first maps those identifiers through its own cryptographic boundary.
• All hash input components remain length-prefixed.
• Non-default algorithms include an explicit algorithm domain component.
• Oversized identity and namespace inputs are rejected before hashing for every enabled algorithm.
• Procedural RNG seeding uses 256 bits from the second half of the identity
  digest, separate from lower digest bytes used for direct visual parameters.
• Derived identity digests and temporary identity hash preimage buffers are zeroized when dropped.
• AvatarIdentity equality uses constant-time digest comparison.
• Rendering and encoding are intentionally variable-time operations. Shape
  counts, geometry, encoded size, and SVG length can vary with identity digest
  bytes, so callers should not treat rendering timing or output size as
  secret-preserving side channels.
• Tests cover parser round-trips, algorithm separation, optional feature paths, oversized input rejection, zero-length line drawing, JPEG alpha flattening, and zeroize trait coverage.

Hashavatar 0.6.0

hashavatar 0.6.0

hashavatar 0.6.0 narrows the crate back to its core purpose: reusable deterministic avatar rendering.

Highlights

• Removed the bundled Axum demo web server from the crate package
• Removed mandatory axum and tokio dependencies
• Removed the bundled hashavatar-cli binary so the package is a pure library crate
• Pointed web/API usage to the separate hashavatar-api project
• Added crate-focused security policy checks and release gates
• Added a fuzz harness for arbitrary avatar identities, families, backgrounds, SVG rendering, and PNG encoding
• Changed AvatarSpec::new to validate dimensions at construction and made spec fields private
• Added enforced identity and namespace byte-length limits with typed errors
• Changed public render APIs to return Result<_, AvatarSpecError> for invalid dimensions instead of panicking
• Removed public path-writing export helpers; callers should write encoded bytes or SVG strings through their own storage boundary
• Changed namespace identity hashing to length-prefix components, preventing separator ambiguity from embedded NUL bytes
• Hardened internal polygon and ellipse rasterization against edge-case panics and large-radius precision loss
• Added post-0.6 version planning for pluggable hashing, no-std preparation, visual layers, variant expansion, and 1.0 stabilization
• Documented maintenance rules for dependency freshness, security review, GitHub CodeQL default setup, and self-testing expectations

Why This Changed

The public HTTP API and demo website already live in hashavatar-api. Keeping a second demo server inside the library crate made the package heavier and pulled web-server dependencies into users that only need avatar rendering.

Compatibility

• This is a breaking API release for callers constructing AvatarSpec, constructing AvatarIdentity/AvatarNamespace, using direct render functions, using custom AvatarRenderer implementations, or relying on the removed path-writing export helpers.
• AvatarSpec::new(...) now returns Result<AvatarSpec, AvatarSpecError>.
• AvatarIdentity::new(...), AvatarIdentity::new_with_namespace(...), and AvatarNamespace::new(...) now return Result.
• Namespace-based identities intentionally produce new deterministic fingerprints because the hash input format was hardened.
• Existing deterministic fingerprints remain covered by updated golden regression tests.
• Users embedding the library should only see a smaller dependency graph.
• Users relying on cargo run for the bundled demo should use hashavatar-api instead.
• Users relying on cargo run --bin hashavatar-cli should call the library API directly or build a separate CLI wrapper.

Security And Quality

• src/lib.rs now forbids unsafe code.
• AvatarSpec dimensions are validated before a spec value can be constructed through the public API.
• Identity inputs are capped at 1024 bytes, and namespace tenant/style-version components are capped at 128 bytes.
• The crate no longer writes to caller-provided filesystem paths.
• Public render APIs reject invalid dimensions without panicking.
• Namespace identity hashing is no longer delimiter-ambiguous when tenant or style version strings contain embedded NUL bytes.
• Rectangle helpers use saturating and clamping arithmetic.
• Polygon scanline rasterization skips incomplete intersection pairs instead of indexing blindly.
• Ellipse rasterization now uses f64 intermediates for high-magnitude geometry calculations.
• scripts/checks.sh now validates release metadata, package contents, dependency scope, unsafe boundaries, reviewed panic-like sites, docs, fuzz harness compilation, dependency licenses, and RustSec advisories.
• scripts/stable_release_gate.sh adds publish dry-run, reproducibility, and optional SBOM generation for release validation.

Hashavatar 0.5.0

hashavatar 0.5.0

hashavatar 0.5.0 prepares the crate for dual permissive licensing and hardens the bundled demo server without changing the deterministic avatar rendering contract.

Highlights

• Starting with 0.5.0, the project is licensed as MIT OR Apache-2.0
• Added LICENSE-MIT and LICENSE-APACHE
• Removed the previous EUPL license files from the current source tree
• Added Fluxheim-style local and GitHub CI checks through scripts/checks.sh
• Added Dependabot configuration for Cargo and GitHub Actions updates
• Pinned GitHub Actions to immutable commit SHAs for CodeQL-friendly workflow hardening

Security And Quality

• Moved demo-server WebP rendering and encoding onto Tokio's blocking task pool to avoid starving async worker threads
• Added defense-in-depth HTTP security headers to demo HTML, image, and error responses
• Added regression coverage for the demo response security headers
• Updated tokio to 1.52.3
• Verified with scripts/checks.sh, including formatting, build, clippy, tests, CLI smoke exports, cargo deny check, and cargo audit

Compatibility

• No avatar rendering behavior changes are intended in this release.
• Existing deterministic fingerprints remain covered by the golden regression tests.
• Published 0.4.x and older versions retain their original release licensing. The MIT OR Apache-2.0 license applies starting with 0.5.0.

Hashavatar 0.4.2

hashavatar 0.4.2

hashavatar 0.4.2 is a repository metadata release for the move to GitHub.

Highlights

• Public repository metadata now points to https://github.com/valkyoth/hashavatar
• Crate documentation continues to point to https://docs.rs/hashavatar/latest/hashavatar/
• Added GitHub contributor, security, issue, pull request, and CI files
• Keeps the 0.4.1 dependency refresh, including rand 0.10 and sha2 0.11

Compatibility

• No avatar rendering behavior changes are intended in this release.
• Existing 0.4.x integrations can update normally.

Hashavatar 0.4.1

• Move hashavatar to rand 0.10 and sha2 0.11
• Refresh direct dependencies across hashavatar and hashavatar-api
• Point hashavatar-api at crates.io hashavatar 0.4.1
• Update docs and changelog for the dependency/security refresh
• Keep audit, license, clippy, check, and test validation clean

Hashavatar 0.4.0

• Added 11 new avatar families: planet, rocket, mushroom, cactus, frog, panda, cupcake, pizza, icecream, octopus, and knight
• Added new background modes: transparent, black, dark, and light
• Added JPEG/JPG and GIF raster export support
• Improved visual variation for ghost, slime, wizard, and skull
• Added stricter image dimension validation for safer public avatar endpoints
• Removed a vulnerable transitive dependency path while keeping rendering asset-free
• Replaced external drawing dependency usage with local geometric drawing primitives
• Updated CLI and demo site support for all new avatar families and background modes
• Updated README examples, crate metadata, and docs.rs documentation link
• Added expanded visual regression coverage for the new avatar families
• Verified with cargo check, cargo test, cargo clippy, cargo audit, cargo deny, and cargo publish --dry-run

Hashavatar 0.3.0

• Added namespace-aware identity hashing through AvatarNamespace
• Declared AVATAR_STYLE_VERSION for stable visual contract tracking
• Added new avatar families: ghost, slime, bird, wizard, and skull
• Added golden visual regression fixtures for stable raster fingerprints
• Added stricter SVG regression coverage for determinism and minimal output
• Expanded the public API site with docs, metrics, SEO metadata, JSON-LD, sitemap, robots, favicon, and manifest support
• Added origin-side rate limiting, timeout handling, metrics, and object-storage deduplication in the API service
• Added OG/social preview image support
• Added a playful paws avatar family with variable cat paw colors and pad shapes