I think the ideal experience considers the different types of connections you make as equivalent: 1 social accounts (twitter, fc) 2 creddd (i.e. via a link to open wherever your wallet is) 3 connect addresses Of the 3, we probably want to lean users most towards 2 and 1, then 3. From an onboarding perspective, I think the first action should be 'choose username' (i.e. no initial creddd) or 'connect fc' or 'connect X.' From there, the default action a user can take is to add additional creddd. Furthermore, maybe there's a deep link to a page for checking for specific creddd on each room that's available so that if a user sees a room they like, they're 1 click away from checking all their wallets against it.

As we get close to launching Traitcaster, I've been reflecting a bit on traits in general and how they relate to Personae's long-term strategy. What is a trait? I think of a trait as a human-understandable label for an anonymity set. relative value of traits Not all anonymity sets have meaningful traits. It's certainly possible to pick a set of public keys that have no cultural relevance. Not all traits are equal in 'value' either. Aside from the purely quantitative value of a trait (i.e anonymity set size), traits vary wildly in their 'usefulness' to Ethereum/Internet users.

Thanks for trying out creddd! creddd is in early alpha, so we really appreciate your willingness to experiment with us. determine the twitter account you'll be attaching cred proofs to(i.e. create new anon or determine existing acct to add cred to) visit https://www.creddd.xyz/, and create a proof associating the 'username' of your twitter profile with each set attach multiple proofs to the same username if you want!

Background Personae Labs is exploring the future of pseudonymity in Ethereum. We launched heyanoun.xyz (prop 150) as an early experiment in allowing private truths to surface. While we fundamentally believe that there's value in allowing controversial opinions to surface, we think heyanoun is far from healthy pseudonymity's final form: it's impossible to engage with a heyanoun opinion pseudonymously it's hard to filter spam/toxicity from actually useful discourse users have no way to accrue 'reputation' to their pseudonymous selves

Notes 2022-02-26 2022-03-19 2022-06-18 2022-07-15 Next paper(s) Flash Boys 2.0 (extra credit) Order-Fairness for Byzantine Consensus

Rob's presentation LS phase 1: sequential setup using local randomness among each user phase 2: randomness beacon to add additional randomness each phase 1 step involves using local entropy to generate private key bunch of operations on two groups (G1, G2) that have a bilinear mapping

Components: circuits that use PrivToPub and do merkle tree check frontend like zkmessage but with pick-able group prove + verify utilize the mm snap enclave work Frontend:

Members Jeff, Veronica, Lakshman Description A set of Ethereum contracts+webapp that allows a user to prove that they were a previous DarkForest winner without revealing their Eth address. If they do so successfully, an NFT is minted saying as much. All verification logic should happen on-chain. Architecture Flow:

bounty directions: better visualize validator/network health live visualization of the attestation pool (i.e. pre-aggregation) better orchestration for staking setups. i.e. k8s, docker, etc. (if HF1 happens before hackathon...) something with light client headers in eth1 contract note: may not be able to do much before bls precompile live slashing visualization/notifications (i.e. slashing website, twitter bot)

Flyer Wishlist Three broad things we're looking for: visualization, i.e. realtime website or dashboard analysis, i.e. analyze some property of the network new tooling for getting/preparing data Some places to get data and things to look at: