# Grapevine Project Spotlight Script

## 1. What is Grapevine
Grapevine is a utility for building private, verifiable social graphs that show distance from a given identity

This is cool because we can build apps that rely on pure social connections to attest in some way to the valididty of an identity

We're going to run through the basics of what is being proven, show off the CLI since it is feature complete, talk about the JS library which does work for proving but is not yet ready for developer use quite yet, and talk about where we see grapevine going

## 3. Flow
We're very quickly going to run through the protocol, you can ask questions for clarity at the end but I'm going to go quick since the demo is like 75% of our time.
Also addresses are just the poseidon hash of the bjj public key

### Relationships
[Relationship Flow](https://raw.githubusercontent.com/Mach-34/Grapevine/staging/docs/diagrams/nullifier_derivation.png)
Before talking about actual proving, lets talk about how relationships function. Each identity is an Eddsa keypair, and we issue auth secrets between users to prove these relationships. For a two way relationship, each user sends the other this auth secret.

1. First is the derivation of the nullifier. We actually do a hash of the sender address with a random trapdoor element. This way, only the keyholder who knows this trapdoor value can emit a nullifier
2. This nullifier is then hashed with the recipient's address. This way we can scope the authorization to use this nullifier to only the recipient
3. Finally, the sender signs this auth secret, and the recipient can then use this to prove they have a direct connection with the sender

### Proving
[Proving Flow](https://raw.githubusercontent.com/Mach-34/Grapevine/staging/docs/diagrams/proving_flow.png)
I'm glossing over a lot for time, but we using Nova-style folding from Nova-Scotia currently which is really nice as it gives you a circom front end for recursively folding proofs together. We're going to be implementing Sonobe in the next month though and I'd encourage you to check that out if you want to play with your own folding stuff.

So Grapevine uses a uniform IVC, meaning every instance is the same circuit. So essentially we multiplex two different cases: the Identity Step and Degree Steps
Every proof is going to pass out a few values:
* The "scope" of the proof (i.e. who we're proving distance from)
* The "relation" of the proof (the prover who is showing their degree from the scope)
* The "degree" of the proof (how many edges there are between the scope node and the relation node in the social graph)
* A list of nullifiers that are checked at any point against a nullifier set to see if a proof is valid (i.e. if a relation has broken the graph)

#### Identity Step
The identity step is really simple, essentially we prove propreitorship of our own address we're asserting

#### Degree Step
So degree steps are where it gets interesting
* Run through inputs

[Proving Flow](https://raw.githubusercontent.com/Mach-34/Grapevine/staging/docs/diagrams/proving_flow.png)

## 4. Run through
Since the JS library is incomplete, we're going to run through the CLI as a driver for the flow. We have the general proving and relationship actions in the JS but its not well formatted, some https is missing, etc. and that will be resolved soon enough

* If you want to play around with this you can use github.com/mach-34/grapevine and run these installation instructions

1. Run the grapevine cli
2. Let's make an account `grapevine account register spotlightAlice`
* Grapevine account is stored at ~/.grapevine/grapevine.key so from the cli you can switch accounts by swapping whatever file is named that
* Obviously in JS it is a bit more open to dev implementation
* Here we're actually running the identity proof step and we're gonna upload it
* Any of our connections will be able to build proofs off of it
3. Now this is purely a social graph library and doesn't make sense to just have one account so to just show the full flow lets make another account
- `mv ~/.grapevine/grapevine.key ~/.grapevine/spotlightAlice.key`
- `grapevine account register spotlightBob`
4. Now lets add our first account as a relationship
- `grapevine relationship add spotlightAlice`
5. Relationships require mutual consent so this does nothing until we add from the first account
- `mv ~/.grapevine/grapevine.key ~/.grapevine/spotlightBob.key && mv ~/.grapevine/spotlightAlice.key ~/.grapevine/grapevine.key`
- btw we can see the relationship pending: `grapevine relationship pending`
- if you want to use the server. You actually don't need to use the server to store encrypted relationships if you want to have stronger privacy, you just need a central place for storing emitted nullifiers at the end of the day
- `grapevine relationship add spotlightBob`
6. Now we have an active relationship
- `grapevine relationship list`
7. So now as Alice, we want to demonstrate we're a degree away from Bob
- `grapevine proof sync`
- The cli is just going to pull all the available proofs you can build degrees from and do it for you, but the JS library will give the developer more granularity into which proofs they want to build, potentially who from if there are multiple routes at the same degree height. But also some applications will want to constantly sync in the background which this is perfect for
8. Okay so now we can show our relation to Bob
- `grapevine proof scope spotlightBob`
9. Okay now lets say we want to build a second degree connection from Charlie to Alice to Bob, we have to set up our simulated environment
- quickly create a new account
- `mv ~/.grapevine/grapevine.key ~/.grapevine/spotlightAlice.key`
- `grapevine account register spotlightCharlie`
- and add Alice as a relation
- `grapevine relationship add spotlightAlice`
- and accept charlie's relationship request from alice
- `mv ~/.grapevine/grapevine.key ~/.grapevine/spotlightCharlie.key && mv ~/.grapevine/spotlightAlice.key ~/.grapevine/grapevine.key`
- `grapevine relationship add spotlightCharlie`
10. Now lets switch back to charlie to build our degree 2 proof
- `mv ~/.grapevine/grapevine.key ~/.grapevine/spotlightAlice.key && mv ~/.grapevine/spotlightCharlie.key ~/.grapevine/grapevine.key`
- `grapevine proof sync`
12. And we can see now a degree 2 connection to Bob, through Alice as our relation
- `grapevine proof scope spotlightBob`
13. Okay but what if Bob decides that Alice isn't cool? Lets nullify our relationship with Alice
- `mv ~/.grapevine/grapevine.key ~/.grapevine/spotlightCharlie.key && mv ~/.grapevine/spotlightBob.key ~/.grapevine/grapevine.key`
- `grapevine relationship remove spotlightAlice`
14. Now we can see that alice doesn't have this connection at degree 1
- `mv ~/.grapevine/grapevine.key ~/.grapevine/spotlightBob.key && mv ~/.grapevine/spotlightAlice.key ~/.grapevine/grapevine.key`
- `grapevine proof scope bob`
15. but also bob doesn't have the connection to bob at degree 2
- `mv ~/.grapevine/grapevine.key ~/.grapevine/spotlightAlice.key && mv ~/.grapevine/spotlightCharlie.key ~/.grapevine/grapevine.key`
- `grapevine proof scope spotlightBob`

### Moving forward

### Where useful
So where is grapevine useful? We think anywhere where you can derive attestations from social consensus. One idea we really like is to build a sort of rival to ENS where instead of having domain squatting, you essentially determine which vitalik is the real vitalik by seeing how strong your social graph is connected to them, kinda like how we do on twitter.

### Other tech to implement
If you know about folding, you probably know you can't just pass folded proofs to untrusted parties as they contain sensitive aggregated witness data. We originally had a chaff step solution which Sora from zkemail team was able to pierce, but the new Hypernova paper actually includes a section on adding zk into the folding step of regular Nova. Pierre who is working on sonobe I think actually already merged in this functionality, so we'll be extending this functionality when we integrate sonobe.

Additionally, there is a problem of the server being able to see all the relations outputted by proofs, so in a future version we'd likely be investigating a TEE-based solution similar to Signal's contact discovery service to provide efficient UX here (yes I know some people don't like TEE's but this isn't securing millions of dollars so the cost of attack should mitigate any threat)

If you'd like to follow up, you can raise issues on the github, or reach out on discord or twitter. ty for having us