Farcaster

I’ve come to the conclusion zk interaction with frames is going to be crucial. Particularly when payments are added to frames.

If the fid is known before a price is quoted, then it’s actually quite easy to charge more based on activity.

Many ways, but I can check onchain spending habits and adjust accordingly.

Hey everyone, I figured out a fairly simple way to achieve ZK frame interaction. IMO, anon frame use will be very important as the protocol scales.

It's also a potential way to break recast to use frame.

See:

Hey everyone, I figured out a fairly simple way to achieve ZK frame interaction. IMO, anon frame use will be very important as the protocol scales.

It's also a potential way to break recast to use frame.

See: https://warpcast.com/eulerlagrange.eth/0xea60f72d

https://github.com/farcasterxyz/protocol/discussions/145

Working on building zkTLS infra/products. A ruthless empiricist and meme connoisseur.

/opacity

and

/eulerlagrange

Can you provide more details about how the Semaphore is used here?  Also, there is only one key for each FID which may become a problem considering that we have a decentralized protocol with a variety of clients. What if we associate a new key with a signer instead of an FID?

Full-time builder. @pimlico | @33bits | @66bits | farcaster-solidity | x.com/potekhin_sergey. Zero-knowledge and asynchronous transactions evangelist.

I’ll write an answer to first question in the morning.

As for the second, each fid can have multiple signers. So associating a semaphore identity to the signer would allow for a fid to have multiple semaphore identities. 

In an anonymous poll, a fid could vote multiple times undetected.

The idea is you want your zkFid to inherit the same Sybil resistance as the fid system.

One semaphore identity per fid is the only way I can think of it.

To recover multiple client support, you can make a new contract that lets a semaphore identity add multiple signers.

I feel like we should start simple though.