/components/LitShareModal.tsx uses the sample code here, which Lit Protocol wrote
-
As mentioned in the video about Lit Protocol, accessControlConditions (like your address must have own least 1 NFT in this contract) are normally created to protect a specific resourceId (usually a URL)
-
Both are passed into saveSigningCondition(), which ensures that people must satisfy the accessControlConditions to access the resourceId
-
Passing accessControlConditions to getSignedToken() will give you a JSON web token (JWT), which says whether you are satisfactory/verified in encoded form.
-
The JWT is normally stored in the browser as a cookie, and when you visit the resourceId, the page will decode the JWT (verifyJwt()) to see if you are verified.
In this repo, for each access condition specified by the Lit modal, I create an accessControlConditions, resourceId, JWT, and decoded JWT in quick succession.
A typical accessControlConditions looks like this:
const accessControlConditions = [
{
contractAddress: '0x319ba3aab86e04a37053e984bd411b2c63bf229e',
standardContractType: 'ERC721',
chain,
method: 'balanceOf',
parameters: [
':userAddress'
],
returnValueTest: {
comparator: '>',
value: '0'
}
}
]
The important bit is the ':userAddress' in parameters, which checks if you, the user, have >0 NFTs from the specified contract. For each contact you have, I replace ':userAddress' with that contact's address and create a random URL for the resourceId. No joke, the URL is baseUrl followed by the string form of a Math.random() call.
I get a JWT for each contact, which I immediately decode/verify to see if each contact passes the accessControlConditions. From the decoded JWT I grab the 'verified' key, a boolean, and store it in a mapping of contact address => verified boolean, which I use as a mask to filter the conversations that show up in your list on the right.
Lit Protocol is very well suited to protecting resources, but I feel it is an odd choice when the user themselves wants to control what they see. It was also complex to integrate, with XMTP being in Next.js and TypeScript while Lit Share Modal v2 is in React and JSX. With Lit there are many steps to see if an address has certain tokens, and because we don't really need to protect a resource, something like Covalent API is easier to integrate and faster to run.
I'm sure there are many APIs out there like Covalent that retrieve an address's token balances across contracts on a network. Sticking a GET request into a useEffect or a button's onClick can trigger contact filtering, with the same result as using Lit Protocol.
That being said, Lit Protocol is a fantastic product, and I had fun and learned a lot in doing this bounty.
Fork this repo and import into Vercel (tutorial).
This example chat application demonstrates the core concepts and capabilities of the XMTP Client SDK. It is built with React, Next.js, and the xmtp-js client library. The application is capable of sending and receiving messages via the XMTP Labs development network, with no performance guarantees and notable limitations to its functionality.
It is maintained by XMTP Labs and distributed under MIT License for learning about and developing applications that utilize the XMTP decentralized communication protocol.
All wallets and messages are forcibly deleted from the development network on Mondays.
The XMTP protocol is in the early stages of development. This software is being provided for evaluation, feedback, and community contribution. It has not undergone a formal security audit and is not intended for production applications. Significant breaking revisions should be expected.
Add your Infura ID to .env.local in the project's root.
NEXT_PUBLIC_INFURA_ID={YOUR_INFURA_ID}
If you do not have an Infura ID, you can follow these instructions to get one.
This example comes preconfigured with an Infura ID provided for demonstration purposes. If you plan to fork or host it, you must use your own Infura ID as detailed above.
npm installnpm run devOpen http://localhost:3000 with your browser to see the application.
Web3Modal is used to inject a Metamask, Coinbase Wallet, or WalletConnect provider through ethers. Methods for connecting and disconnecting are included in WalletContext alongside the provider, signer, wallet address, and ENS utilities.
In order to use the application's chat functionality, the connected wallet must provide two signatures:
- A one-time signature that is used to generate the wallet's private XMTP identity
- A signature that is used on application start-up to initialize the XMTP client with that identity
The application utilizes the xmtp-js Conversations abstraction to list the available conversations for a connected wallet and to listen for or create new conversations. For each convesation, it gets existing messages and listens for or creates new messages. Conversations and messages are kept in a lightweight store and made available through XmtpContext alongside the client and its methods.
The application's functionality is limited by current work-in-progress on the xmtp-js client.
The client will throw an error when attempting to lookup an address that does not have an identity broadcast on the XMTP network.
This limitation will be mitigated very soon by the example application's UI, and resolved soon via improvements to the xmtp-js library that will allow messages to be created even if the intended recipient has not yet generated its keys.