Collab.Land Proxy Account Signing For Security Reasons [Solana]

[calebcgates]

Story
As a user I am scared of signing collab.land transactions with my cold wallet because there are numerous scams & attack vectors.
I've heard of friends losing assets by signing bad transactions.
While I understand the collab.land website is correct and secure there are many ways that impersonators can hack cookies, incorrect urls, incorrect signatures, etc.
What I want is a way to delegate alternative accounts who can sign on my behalf.
That way if one of these delegator accounts is compromised the hacker will not have the ability to transfer expensive assets from my original account.

In order to securely sign a proxy delegation I would like a github project that I can clone, download, and use to sign a specific message locally. (this project may already exist) I would avoid using an online website to do this signing because then signing a proxy delegation would be open to the same attack vectors as signing for wallet verification.

After signing a proxy delegation I want that signature to be presented to me so I can verify its data & then save it in my local machine/ password manager/ etc. This message could be save on chain however that is completely unnecessary, expensive, and public.

When I login to collab.land I want an option to sign with proxy signature.
Passing the proxy signature and then using the proxy account to sign a time stamped message & passing those messages to collab.land. Collab.land can then verify that the proxy signature is valid & includes address of the account that signed the 2nd collabland specific message. If that validation passes then collab.land can save the address of the Original account & check for it's assets.

Ultimately the proxy account doens't need any funds or NFTs and any bogus signatures taken by hackers would be useless.
One thing to consider is that if a proxy accounts private keys are compromised there should be a way for the original account to invalidate the original signature so that a hacker cant impersonate your assets on discord... since these transactions are off chain that's hard. Alternatively if the signatures are saved in 1 contract then the owner of the original account could delete that signature - this is a lot more overhead and cost & collab.land is proud to be a gasless signing method so on chain transactions are out... maybe the signature data can be saved with a nonce & old signatures will not be validated by collab.land and signatures with a higher nonce will over ride (higher nonce from a new account not the same account - nonce in this terms is something collab.land adds to the proxy signature so that only one proxy account can be used per wallet at a time)

• consider user behavior and if a Whale would want to delegate multiple proxy accounts so they can use multiple accounts on multiple devices. How would this affect the collab.land validation, what data to save in the CollabLand backend and how to invalidate signatures for compromised accounts (1-many problem)

Once proven on Solana this method can be take to other chains.
There is also a similar consideration for multisig contracts however since contracts cannot sign transactions this is a different challenge.
https://github.com/orgs/abridged/discussions/55

Tasks

• Create the signing website github project that can be downloaded and run locally (similar to bip39)
  • Website should support Solflare & Phantom wallet
    • Task: Design what the web interface should look like / what buttons / errors outputs
    • Task: Copy the Solona Hello world application from the day 1 tutorial at launch house
    • Task: Find the branch that supports login with Phantom wallet
    • Task: Run the project locally & link your phantom wallet
    • Task: Learn how to sing transactions (does logging in sign a transaction?) - learn how to sign a custom message
    • Task: Determine what message needs to get signed
    • Task: Dry out the project and create a readme that helps users run it locally
    • Task: Allow the project to be deployed locally by any users (How can we make this extensible so it eventually can run the local version of the collab.land wallet connect page so that any wallet can be used to sign a transaction
    • Task: Have a zip of the code and an MD5 hash (or another hash) so that people can verifiy that they are downloading the correct code. this is slighly less necesary becasue they are downloading and siging a transation locally so they don't need to worry about bad code unless that code has network hooks that could get bad signatures. Either way it is helpful to have verified MD5 hash and to do everything to build trust.
    • Task: Host the code somewhere & the hashs (our github, our website, our twitter) they should be updated as new versions of the project are released
  • Understanding signatures
    • Task: Have configuration fields for the Proxy wallet address & the Nonce
      • Task: Decide what data should be in the signature
    • Task: Have a way to decode previous signatures so you can check their nonces (edge case only needed if proxy account keys are compromised - can probably be a future feature to record and not act on yet)
  • Task: Output the signature so that it can be saved - Where does the website output this signature - does the UX tell you to save is somewhere?

Changes to Collab.Land Login Website

• Task: Update collab.land login page to include "sign in with proxy signature"
  • Can be a drop down
  • If too complicated for the hackathon simply edit the API controller to include an extra field called "proxy_signature"

Changes to Collab.Land backend Logic / Jobs Server

• Task: Edit the validation logic on the collab.land side to check for a proxy signature, decode the proxy signature, check for any DB object that includes that account & if you saved a signature with a lesser nonce (this could also be V2 if it adds to much complexity - so long as you define what the ideal operation should look like) - if the APIs work then we can add the edge case validation & data saving & can also add to the front end if I can't figure that out
  • Feature: If all validation passes then proceed as normal

3rd Party Onboarding

• Task: Get 3rd party devs access to the Collab.Land monorepo
• Task: Document the process
• Task: Teach them how to stand up Terraform instance. They'll need their own AWS account? Where will their terraform be built? I still don't understand that.
  • Task: Document the process
• Task: Help them set up their own discord bots & bot tokens & discord servers, and create some roles & invite their own development bot to their server & copy all the bot keys and guild id, and user ids as needed into a .env file
  • Task: Document the process
• Task: Get the jobs servers running locally & the login page
  • Task: Document the process
• Task: Help them start writing small changes to the jobs server for the signature validation
  • Task: Find the correct documentation to get them up to speed
  • Task: Help them write unit tests, find the correct documentation
  • Task: Document the process / organize other existing documentation
• Task: Locally validate end to end discord connect, click link, choose proxy signature, sign with proxy wallet, & be assigned the role
  • Task: Document the process

Acceptance Criteria

• user can download the github signature page
• user can run the signature page locally, construct, and save their proxy signature
• user can submit a proxy signature with their account linking when joining a collab.land channel
• the signature is validated & when it succeeds links the original address because the user has proven ownership of the 2nd account
• once the original address is linked then asset validation continues as normal.

[calebcgates]

Acceptance criteria

• Proof of concept documented
• Loom video for progress completed during the hackathon
  • https://www.loom.com/share/01b0401312a641efb00bcd6d6836af6c
  • https://www.loom.com/share/7ce3cf9a4f7049ce9fc4ed29ecd0e24f
• tied with a bow so that the same 3rd party or a different 3rd party can create a proposal for the DAO to finish and take this work into production

[calebcgates]

So embarrassingly enough I deleted some of my code while rebasing. Fortunately I took a screen shot so the code can be typed back into the correct file.

• type this code back into the monorepo and commit it to a branch
• commit the code to a branch for the front end
• create a loom video describing where everything is and potential next steps
• wrap this up with a bow so that a future dev could pick it up and create a compelling proposal to add this feature that can be submitted to the DAO

[calebcgates]

Front end code pushed to branch 'origin/509-Solana-Proxy' in the collab-connect project
Back end code was retyped and pushed to branch 'origin/509-Solana-Proxy' in the collabland-monorepo project
Simple unofficial proxy signing website available here: https://github.com/byronbenharris/collabland-proxy

• Download the code
• Run the react app
• use the web app at localhost:3000 to create a proxy signature for another account. do on local host to ensure no scammers are having you sign a bad transaction
• you can then take that signature to the internet anywhere a proxy signature is accepted. This proposal is that collab.land will accept a proxy signature & if valid will check the assets of the root account not the proxy hot wallet account

[calebcgates]

Final Thoughts:

Signing the signatures on local host is a very tech heavy ask but the point is to allow those who are paranoid and knowledgable to protect their assets. Obviously a website that lets you create a proxy like epsproxy.com is more convenient however it faces the challenge that if it were to become more popular scammers would start to duplicate their website and then those creating a proxy would face the same challenge of trying to understand who to trust.

Some future upgrades include the idea that any service which is read only could adopt a proxy signature but only if we come up with an accepted standard format. Is there one? What services accept epsproxy.com? Also since collab.land is all gas less signing the thought of having to pay 0.005 ETH to delegate a proxy seems limited as well as annoying because it would be chain specific authorization.

The big vision pitch is that wallets like metamask could automatically create proxy accounts for every single user so that for read only operations only proxy accounts are ever used so that it becomes quite clear that a user is or is not intending to transfer funds or interact with a smart contract. This wallet specific integration would be a huge win but is also contingent on services honoring the proxy relationship.

The solana team asked after the hackathon if we would consider any wallet specific integrations on Solana to help with security. If phantom were to generate a proxy account for every account created and tell the user when they are signing a message vs enacting a transaction that would be super helpful.

• Todo: For all of crypto we should spitball what this upgrade would look like. Sounds like Block Wallet has a similar interest/ idea from my chat with them.

[calebcgates]

Current status: MVP proved out the process & it's quite simple. What would be next is researching a proxy signing standard, comparing ours to epsproxy.com, spitballing in wallet proxy generation, and implementing the MVP of proxy signature acceptance in Collab.Land (current code does not communicate well from the front end to the back end, unit tests on the back end for decoding would be super valuable to add as well)

[raymondfeng]

It's a similar concept as https://support.argent.xyz/hc/en-us/articles/360022631992-About-guardians.

[raymondfeng]

We can use Verifiable Credential as the standard to represent the authorized proxy address.

• A user owns an address (1) that holds assets
• The user uses the private key for address 1 to issue a VC to another address (2) as the proxy
• Collab.Land asks for the VC and have address 2 to sign a message