zm zm

Users start with a Polygon ID wallet. They create ZK-shielded verifiable credentials (VC's). zm zm users can see the VC that another user signed up to the app with and initiate a chat with them.

First, users scan a QR code with their Polygon ID wallet to verify their credential on zm zm.

This verification is processed by our verifier, which is based on the Polygon ID verifier docs, with our own improvements which include a a newer query request type and database interactions to store the Polygon ID.

The verifier communicates with zm zm using websockets. If the response is valid, meaning the user's credential was verified, the user can log in with their wallet and send a direct message to any other user who are on the network and contain the verifiable credential.

zm zm uses the Polygon wallet to create a DID document with VC's. We forked the verifier docs to add a few features, and created our own VC verifier servers.

For the front end we used XMTP's chat interface, and implemented a TypeScript library to generate a QR code for verifying users' credentials, after trying to integrate several in React.

We mapped Polygon IDs to Ethereum addresses for compatibility with XMTP, since XMTP is address-to-address communication.

These mappings were stored in our supabase database, after many unsuccessful hours of troubleshooting on Ceramic Network.

Our biggest hurdle was debugging polygon query requests & networking issues such as CORS, which came up twice and took ~ 3 hours.

Also, we attempted to integrate Ceramic Network to store Ethereum address: PolygonID mappings, but the docs are cluttered and outdated - 5/12 of the cli commands are deprecated, and it took hours just to parse all of the jargon.

We were impressed with how much we got done, given how often our architecture changed.

We are most proud of getting a product done with so many different pieces - we were unfamiliar with Polygon ID and XMTP, with neither of us having experience.