Today the Call Directory extension works from a static, synced list: a number is only blocked once the device has pulled a blocklist delta containing it. So there is a window between the community scoring a number as spam and any given device acting on it.
Live Caller ID Lookup (iOS 18+) closes that window. It lets the system make a privacy-preserving encrypted query to our server on each incoming call, so blocking reflects the live score with no sync required. Truecaller ships it.
This is the single biggest capability upgrade available to this project.
Why it is substantial
Apple does not let you just expose a REST endpoint. It requires a service implementing Private Information Retrieval with homomorphic encryption, so the server learns nothing about which number was queried. That is the whole point — and it is real cryptographic infrastructure, not a wrapper.
Rough shape:
- a PIR service Apple's framework can query, per Apple's specified protocol
- an encrypted database derived from the blocklist, rebuilt as scores change
com.apple.developer.identitylookup.* entitlements plus an Apple entitlement request- client wiring to register the lookup extension
Worth knowing before starting
It does not give access to the user's contacts — the server cannot know them by construction. So it does not solve #13 ("block everything not in my contacts"); these are complementary, not alternatives.
Also note the architectural fit is unusually good here: GET /api/v1/numbers/{e164} already exists as a single-number reputation lookup, so the semantics are in place. It is the transport and privacy layer that is missing.
Discussion before code, please — the entitlement request and the PIR design should be agreed first.
Today the Call Directory extension works from a static, synced list: a number is only blocked once the device has pulled a blocklist delta containing it. So there is a window between the community scoring a number as spam and any given device acting on it.
Live Caller ID Lookup (iOS 18+) closes that window. It lets the system make a privacy-preserving encrypted query to our server on each incoming call, so blocking reflects the live score with no sync required. Truecaller ships it.
This is the single biggest capability upgrade available to this project.
Why it is substantial
Apple does not let you just expose a REST endpoint. It requires a service implementing Private Information Retrieval with homomorphic encryption, so the server learns nothing about which number was queried. That is the whole point — and it is real cryptographic infrastructure, not a wrapper.
Rough shape:
com.apple.developer.identitylookup.*entitlements plus an Apple entitlement requestWorth knowing before starting
It does not give access to the user's contacts — the server cannot know them by construction. So it does not solve #13 ("block everything not in my contacts"); these are complementary, not alternatives.
Also note the architectural fit is unusually good here:
GET /api/v1/numbers/{e164}already exists as a single-number reputation lookup, so the semantics are in place. It is the transport and privacy layer that is missing.Discussion before code, please — the entitlement request and the PIR design should be agreed first.