Trusted Connections — Generalized Social Graph
Public concept overview of Hussh's privacy-first, directional social graph architecture for agentic trust and recipient-scoped interactions.
TL;DR: Trusted Connections is Hussh's directional, app-wide social graph that allows users to designate trusted contacts for secure location sharing, check-ins, and emergency SOS alerts without storing plaintext coordinates or exposing personal networks to the server.
Status as of 2026-07-10: see body.
Relations
Introduction to Trusted Connections
Trusted Connections is a first-class, platform-wide directional social graph in the Hussh ecosystem. It elevates the concept of contact-trust from a simple, isolated feature (like SOS alerts or location tracking) into an extensible system-level relationship layer.
Unlike traditional social networks that require bidirectional approval, Trusted Connections operates on a directional model ("follow" or "designate"). This design mirrors real-world trust structures: you designate emergency contacts or allow trusted friends to see your status, but their designation of you remains independent.
Privacy by Design
True to Hussh's core zero-knowledge tenets, the Trusted Connections graph is engineered to protect user metadata and personal networks:
- Decoupled Social Map: The network graph does not leak communication history or raw data.
- Recipient-Scoped Credentials: Trust edges authorize the minting of device-to-device capability tokens (HCTs) that govern temporary access.
- No Coordinate Leakage: Location sharing and check-ins that utilize Trusted Connections remain client-encrypted. The server merely acts as a secure, blind post office routing encrypted location envelopes to designated contacts.
Relationship Layer Governance & Scope Capabilities
The central Hussh One agent holds exclusive authority over relationship modifications. Users manage their trust list naturally through natural language chat or voice commands (e.g., "Add Alice to my trusted connections"). The agent resolves identities against the secure platform directory, preventing free-text guessing or raw phone-number exposure, and maintains graph hygiene under strict privacy policies.
In July 2026, Hushh Connect formalized explicit relationship scope capabilities across all connections:
- Explicit Scope Labels: Every requestable scope carries a distinct, human-readable label and user-friendly explanation.
- Recipient Scope Proposal & Modification: Recipients of connection requests can review and selectively modify the requested scope list before accepting, ensuring least-privilege consent boundaries.
- Scope Search & Capability Review: Users can search connected user scopes, while the system enforces mandatory capability review before bilateral data or context access is activated.
Relationship Layer Governance & Scope Capabilities
The central Hussh One agent holds exclusive authority over relationship modifications. Users manage their trust list naturally through natural language chat or voice commands (e.g., "Add Alice to my trusted connections"). The agent resolves identities against the secure platform directory, preventing free-text guessing or raw phone-number exposure, and maintains graph hygiene under strict privacy policies.
In July 2026, Hushh Connect formalized explicit relationship scope capabilities across all connections:
- Explicit Scope Labels: Every requestable scope carries a distinct, human-readable label and user-friendly explanation.
- Recipient Scope Proposal & Modification: Recipients of connection requests can review and selectively modify the requested scope list before accepting, ensuring least-privilege consent boundaries.
- Scope Search & Capability Review: Users can search connected user scopes, while the system enforces mandatory capability review before bilateral data or context access is activated.
The consent lifecycle as a conversation
Status as of 2026-09-11: implemented on the ADK orchestration workstream branch. Not yet merged to the release branch and not deployed to any lane, so this describes branch truth.
Asking someone for their information, declining a request, withdrawing one you sent, and ending a grant you gave are all things One can now do in the conversation where they were asked for. Previously only the asking half existed. The other three were offered, confirmed, and then reached nothing, so the only move left was a link to a screen.
Four properties make doing this from chat safe rather than merely convenient.
The tap authorizes, not the transcript. Every one of the four is authorized by the confirmation card the person taps, bound to the app's directive ledger. A confirmation flag supplied by the agent itself is discarded before the action runs.
The agent never holds an identifier. A request, a grant and a sent bundle are each named to the agent only by an opaque handle. The real scope, token and bundle identifiers stay on the server and are resolved there at dispatch, so the agent cannot widen or retarget a request between the read-back a person agreed to and the request actually sent.
Both ends of the lifecycle are now visible. Ending a grant matches on a scope or the request it came from, and withdrawing a sent request needs its bundle. Nothing could previously produce any of the three, so both actions were reachable in the contract and impossible to aim. Two listings now name what is shared and with whom, and what was asked of whom, in words rather than identifiers.
Asking twice creates one request. The request is keyed to the proposal it came from, so a redelivered instruction resolves to the same bundle rather than creating a second live ask.
Scope review also now reads the way personal memory reads: one level at a time from a domain down to an individual attribute, with the parent named and a trail back, rather than one flat list of every requestable path at once.