Skip to main content

hopClient

Initialize with initializeFromShyConfig — see the Web SDK overview for the common setup pattern.

Purpose

shyhop is a shyware utility module that seals follow-up destination metadata, such as the next-hop destination address and port, using shystore two-list semantics.

The result is:

  • destination metadata is not stored in plaintext in canonical records
  • recovery and lawful reconcile remain available through authority-gated read paths
  • route destination disclosure is separated from public-state observability

Scope and limits

shyhop improves protocol-layer confidentiality for destination metadata. It does not hide first-hop network metadata at the transport layer.

This means shyhop helps with:

  • canonical-state non-linkability for route destination fields
  • reducing application-log leakage of destination metadata

And it does not by itself solve:

  • local neighbor or ISP observation of first-hop traffic
  • global timing-correlation attacks

Manifest requirements

shyhop runs as a shyware utility surface over shystore semantics.

  • store block must be present
  • app.product_type may be shyhop, shystream, shycam, or shyiot
  • shyhop does not require shycam; shystream consumers may compose directly with shyhop
  • anon_layer.black_box_required must be true
  • when store is present, SDK requires one of: anon_layer.shyPayload=true or anon_layer.shyIDV=true
  • when store is present and neither toggle is set, SDK defaults anon_layer.shyPayload=true
  • signing.required must be true
  • required flows must include:
    • hop_route_store
    • hop_route_reveal
    • biometric_rederive

API surface

Main module:

  • shyware/sdk/web/hopClient.js

Primary exports:

  • createHopClient
  • assertHopManifest
  • initializeFromShyConfig
  • formatHopError
  • createHopUtility (alias)
  • initializeFromShywareConfig (alias)

Core operations:

  • sealFollowUpDestination
  • revealFollowUpDestination
  • rotateFollowUpDestination

Route payload schema

The sealed payload written through shystore uses schema shyhop.route.v1 and includes:

  • route_id
  • destination_address (IPv4 or IPv6)
  • destination_port
  • transport
  • ttl_ms
  • policy_tag
  • metadata
  • issued_at

Example

Use initializeFromShyConfig from hopClient.js, then:

  1. create a bucket for hop routes
  2. sealFollowUpDestination to store the next-hop destination metadata
  3. revealFollowUpDestination when an authority-gated workflow requires retrieval
  4. rotateFollowUpDestination for destination change without exposing plaintext history