v0.1.1: UTF-8 handling fix

Patch release fixing UTF-8 handling for NFD property values end-to-end.

Fixes

• Mojibake on non-ASCII property values — The DID Document JSON
  returned by the resolver has always been valid UTF-8, but the HTTP
  Content-Type response header did not declare a charset. Consumers
  that default to Latin-1 or Windows-1252 (including the Universal
  Resolver dev UI) therefore misdecoded multibyte characters. All JSON
  responses now advertise ; charset=utf-8 on the HTTP header while
  keeping the W3C-compliant didResolutionMetadata.contentType /
  dereferencingMetadata.contentType fields bare.

• Latent UTF-8 corruption in the fetch layer — An 8-byte heuristic
  in internal/nfd/fetch.go reinterpreted any property value that was
  exactly 8 bytes and contained a non-printable rune (e.g. zero-width
  joiner, BOM, Unicode format characters) as a big-endian uint64. A
  user-set u.* or v.* string could be silently turned into a
  number. The heuristic is replaced by an explicit whitelist of the
  internal contract keys that actually use this encoding
  (i.timeCreated, i.timeChanged, i.expirationTime, i.sellamt,
  i.asaid). User-defined and verified values are now always treated
  as strings.

Compatibility

• No API or configuration changes.
• Accept-header content negotiation is preserved; clients sending
  application/did+ld+json (with or without an existing charset
  parameter) continue to receive LD-JSON responses.
• The text/uri-list 303 redirect path is unchanged.
• didResolutionMetadata.contentType / dereferencingMetadata.contentType
  in the JSON body remain bare media types per W3C DID Resolution §7.

Tests

• Added regression tests for 8-byte UTF-8 preservation (ZWJ, ASCII,
  leading-null byte) and for continued uint64 decoding of all
  whitelisted internal keys.
• New cmd/did-resolver/main_test.go asserts charset=utf-8 on
  every handler response and confirms the body metadata field stays
  bare.

v0.1.0

did:nfd Resolver v0.1.0

The initial release of the did:nfd DID method resolver — a W3C DID Core v1.0 compliant service that bridges Algorand NFDs (Non-Fungible Domains) into the decentralized identity ecosystem.

Highlights

• W3C DID Core v1.0 compliant — Full resolution of did:nfd:{name}.algo identifiers into standards-compliant DID Documents with proper @context, verification methods, services, and metadata
• Reverse resolution — Resolve did:nfd:{ADDRESS} with a raw Algorand address to discover all associated NFDs via the on-chain registry address index
• DID URL dereferencing — Fragment resolution (#owner, #algo-0, etc.) and ?service= query parameter support with relativeRef endpoint construction
• Cryptographic key pipeline — Algorand addresses are automatically converted to Ed25519 verification methods (multibase base58btc with multicodec prefix) and X25519 key agreement keys for encrypted communication
• Rich DID Documents — Auto-generated services from NFD properties including websites, social profiles, deposit accounts, and linked identities via alsoKnownAs
• Deactivation detection — Correctly identifies expired, for-sale, unowned, and explicitly deactivated NFDs
• Performance — Expirable LRU cache (50k entries, configurable TTL) for both name and address resolution, with parallel blockchain fetching via goroutine work groups
• Universal Resolver compatible — Runs standalone or as a driver for the DIF Universal Resolver, with Docker Compose configuration included
• Multi-architecture Docker images — Published to Docker Hub (txnlab/did-nfd-resolver) for linux/amd64 and linux/arm64
• Comprehensive test suite — Full mock-based test coverage for resolution, dereferencing, reverse resolution, key derivation, caching, and error handling

Documentation

• Full W3C-style method specification
• User guide with curl examples and quick-start instructions
• Universal Resolver driver setup

Quick Start

docker run -p 8080:8080 txnlab/did-nfd-resolver
curl http://localhost:8080/1.0/identifiers/did:nfd:nfdomains.algo