Concept, help wanted — there is no TrustGraph phone-number binding or ready-made call blocker.
A cooperating calling app could carry signed evidence before ringing, then let the recipient apply a trust policy. Ordinary caller ID supplies a phone number, not a TrustGraph signed object.
A possible application flow
- The calling app delivers a fresh, session-bound challenge and response through its signaling channel.
- The recipient verifies the signing evidence and current membership.
- The recipient queries from their own node and verifies any positive trust path locally.
- The calling app applies its own allow, silence or prompt policy.
This is a proposed composition. The live challenge specification, pre-call delivery and binding to the actual call remain missing pieces. Device platform integration, background execution and timely delivery also require implementation and testing by the calling app.
Design an unknown outcome
A caller without evidence is unknown to this flow. A network error, expired certificate or missing challenge is also unknown. A verified negative path response is a signed report about the selected policy; it is not evidence that the caller is malicious. Your app must make its screening behavior clear to its user.
Does not establish
A displayed number does not establish a persona, a live speaker or key possession. There is no public phone number to persona lookup, and none is planned. Do not claim that the current primitives can screen arbitrary phone-network calls or identify their speakers.Help build the missing pieces
We welcome partners building cooperating calling apps or researching device call-screening integrations. Reach out to discuss the protocol and platform work. Early access includes SDK access and app-origin allowlisting; development happens on staging.
Start with the available signed-message flow to understand membership and proof verification.