# Farcaster // Contract Accounts Working Group Kickoff

## Agenda

1. Quick (re)introductions — *gm*
2. Objectives (collective and individual) — *what do we want to achieve?*
3. First project(s) — *what should we focus on first?*
4. Next actions — *where/how do we start?*

## Notes

### Attendees
Stephan (opencast), horsefacts (farcaster), Rafael, Nick (hats), Kartik (flink), Spencer (hats), Salman

### Objectives

- **Spencer**: enable DAOs (and other onchain orgs) to more effectively manage their farcaster accounts (eg allowing individuals to cast on their behalf), including with Hats Protocol
- **horsefacts**: enable onchain / contract-based use cases for fids and supporting alternative clients; contracts as (mostly) first-class citizens of the protocol
- also thinking about trust and safety considerations (organizational ownership of accounts may help)
- foster a diverse client ecosystem
- **Stephan**:
- support for broadcasting farcaster messages directly on-chain, eg generated directly by smart contracts
- implementation for clients to authorising a new signer for a smart contract account / shared accounts
- **July**: enable sensors to cast their attestations
- **Rafael**: publishing to farcaster from smart contract with relayer
- **Kartik**: representing organizational ownership of fids in clients
- organizational affiliation
- **Salman**: allow people to post on behalf of an organization, with revocable permissions

### First Project(s)

Some possibilities:
- implementation for clients to authorising a new signer for a smart contract account (shared access)
- working document: https://hackmd.io/8-wqct6jR9i6drkGgIJmMQ
- ...

#### Smart Contract Organization Accounts UX (Client perspective)
- Onboarding: UI to transfer FID from custody wallet to smart contract
- Proposed high level flow:
- Join an organization > generates a keypair, share public key to share with the organization
- Organization 'add a member': create a signer with the given public key

Questions
- UX for authorising public keys of new users for organization
- Example setup/use case within hats protocol
- How can we allow users to create signers based on on-chain logic e.g. Smart contract account has logic which determines that ethereum address A is allowed to create a new signer for the account (e.g. Hats Protocol). User with access to wallet with address A should be able to create a new signer based on that logic
- Addressed in existing spec. Signer can be created by 'hat wearer' because isValidSignature() returns true for the signature by the authorized user
- Need to address revoking signers. Bad UX to delete all casts by that signer on behalf of the organization

#### Support for broadcasting farcaster messages directly on-chain
Proof of concept: listen for events on a smart contract which allows submitting of farcaster messages and relay them to hubs

Example applications
- On-chain voting proposals to change DAO account details
- Community approved casts
- Jokerace style competitions
- Auctions for ad space
- Anonymous posting based on certain zk criteria

#### Projects

1. start with / refine the [existing shared accounts spec](https://hackmd.io/8-wqct6jR9i6drkGgIJmMQ)
- Spencer, Stephan, horsefacts
3. generate a spec for the onchain events => relayer => messages => hubs concept
- Rafael,

### Next Actions