Selective Application

Selectively disclose content. A pull-driven and anonymous process.

What is Selective Application?

Selective Application facilitates the confidential sharing of information with specific recipients, without publicly revealing their identities. The designated recipients can securely access the data by generating a zero-knowledge proof that confirms their group membership, all while maintaining anonymity.

How does it work?

1. Input Parsing

Selective Application has a very simple front-end that takes as input a unique ID. This unique ID should follow some rules, so that both the puller and pusher can interact via the webpage without ever speaking outside of it. Essentialy, the unique ID should be known only to the pusher and whitelisted puller while being very hard to guess.

For now, the unique ID is shown as being a Github username + "@" + Github Org. Nonetheless, these are front-end cosmetics, and there is no such enforcement on the back-end, for reasons that will become obvious shortly.

2. Proof Generation

Proof generation happens on the client-side to retain anonymous properties. As such, the unique ID gets converted to a BigInt and passed as input to the circuit (compiled to WASM) as can be seen below.

The circuit comes with a pre-compiled array of 1000 elements. This array is generated by the pusher and can be seen as a two-dimensional matrix where each row is of length 50. Each target organization is allocated 50 consecutive slots in the array. If fewer than 50 users are specified, the remaining slots will be filled with randomly generated hashes. This approach allows for a more granular group definition and facilitates the dynamic rendering of content based on the specific group output.

Furthermore, since we created this array and hard-coded it into the circuit, there is no need for us to verify data integrity by using merkle inclusion proofs. Even though the complexity of a merkle inclusion proof is about $\mathcal{O}(n\log{}n)$ whereas it stands at $\mathcal{O}(n)$ for traversing our matrix, we're getting rid of the hashing related constraints, thereby reducing the total number of non-linear constraints while making the code more accessible.

3. Proof Verification

Armed with the proof generated in step 2, we use serverless architecture hosted by vercel to verify the proof. Besides being a clear testament to how cheap are groth16 succinct verification, it also makes our life much easier. If the proof is successfully verified, our dedicated content will get served as per specified by the group set number.

Installation

1. Clone the repo
2. Create your puller list
   create and modify username_at_org.txt in src/secrets/ with your whitelist.
3. Install dependencies, build the circuit and build the front-end

npm run full-set-up

TODOs

• Generate protocol with stronger preimage attack resistance;
• Build sybil resistant protocol (potentially leveraging some form of Oath);
• Arrange input button scaling;