# Pkarr Crate Evaluation for did:dht Enhancement

## Summary

**Recommendation: Switch to pkarr when did:dht work resumes.**

Pkarr (v5.0.3, 550K downloads) provides a higher-level abstraction over Mainline DHT specifically for decentralized DNS-like records, which is exactly what did:dht needs.

## Current Implementation

Archy's `core/archipelago/src/network/did_dht.rs` (~211 lines):
- Uses `mainline` crate directly for BEP-44 mutable items
- Stores DID Documents as **JSON** (not DNS packets as spec requires)
- Custom 1-hour in-memory TTL cache
- No relay fallback

## Pkarr Advantages

| Feature | Archy Current | Pkarr |
|---------|---------------|-------|
| BEP-44 signing | Yes (via mainline) | Yes (integrated) |
| DNS packet encoding | No (stores JSON) | Yes (RFC 1035 compliant) |
| Relay fallback | No | Yes |
| Spec compliance | Partial | Full (DNS packets) |
| Caching | Custom 1-hour TTL | Pluggable with built-in cache |

### Key Difference: DNS Packet Encoding

The did:dht spec requires DID Documents to be stored as DNS packets (RFC 1035), not JSON. Our current implementation works for node-to-node resolution (both sides understand our JSON format), but is non-standard. Pkarr handles DNS packet encoding automatically via `SignedPacket` and `SignedPacketBuilder`.

### Relay Fallback

Pkarr includes relay server support for nodes behind restrictive NATs or firewalls. Our current implementation has no fallback when DHT connectivity fails.

## Migration Estimate

- Replace `did_dht.rs` with pkarr API calls
- Add `pkarr = "5.0.3"` to Cargo.toml
- Estimated: 1-2 hours implementation + testing
- No breaking changes to RPC interface

## Decision

Keep current implementation for now (it works). Switch to pkarr when actively developing did:dht features, as it brings spec compliance and relay fallback with less custom code.