by Joe Wagner

This week the Tableland Studio made its transition to being deployed on Vercel. Studio is built with Next.js. Deploying on Vercel is a natural choice because Next and Vercel were built and are maintained by the same team.

During the initial development of the Studio, we had planned to use Vercel—but upon deployment, we discovered that because Vercel uses serverless functions, our API was going to have problems managing nonces for the Studio's internal wallet.

Some Background on Serverless Functions

Note that Vercel calls both serverless functions and edge functions “Vercel Functions.” Vercel Functions have the very compelling feature of removing the need for server management or resource provisioning. These functions scale automatically with user demand and can interact with APIs, databases, and other resources as part of your project's deployment. In particular, the Studio nonce manager uses the built-in Redis database called Vercel KV.

Some background on Wallet Nonces

If you're unfamiliar with or want a refresher with wallets and nonces in the context of blockchain transactions, here is a nice overview on blog.thirdweb.com.

The TL;DR is that our nonce manager allows a horizontally scaling web server to send blockchain transactions. It does this by enabling the different instances of the server to know the correct nonce value when sharing a wallet address.

Our Solution

To keep the automatic scaling of Vercel Functions while allowing a single wallet to be shared, we decided to implement a singleton nonce manager using Redis.

Luckily, Vercel has an easy-to-integrate Redis hosting tool called Vercel KV. Using Vercel KV and following some of the logic contained in the Ether.js in-memory nonce manager, we built the @tableland/nonce package (here). This package is open source and available on npm and GitHub.

Using it is fairly simple, and you can drop it into any Node.js Ethers application as follows:

import { Wallet, getDefaultProvider } from "ethers"; import { NonceManager } from "@tableland/nonce"; const wallet = new Wallet(process.env.PRIVATE_KEY); const provider = getDefaultProvider(process.env.PROVIDER_URL); const baseSigner = wallet.connect(provider); const signer = new NonceManager(baseSigner); // use `signer` as usual with ether.js and Tableland // on a Vercel deployment that scales automatically...

The only additional configuration required is that you have two env variables available to the Node.js process, KV_REST_API_URL and KV_REST_API_TOKEN.

You can get the values in these variables from the Vercel Storage dashboard under the .env.local tab.

Conclusion

If you find yourself wanting to deploy an application that sends blockchain transactions with Vercel, definitely give @tableland/nonce a try and let us know what you think.

by Dan Buchholz

In last week's post, we discussed using Lit protocol for encrypting table data. We wanted to ensure this guide is accessible and fully flushed out. So, we've published a guide to Lit Protocol encryption on our docs site! It includes the following:

• Setting up a Lit client.

• Helpers to make it easier to work with Lit chains and create a SIWE message.

• Defining access control rules for encryption with Lit.

• Encrypting and decrypting data alongside the Tableland SDK.

Check out the docs here: https://docs.tableland.xyz/playbooks/integrations/lit

For example, after setting up your Lit authorization signatures, access controls, and writing data, your table will store obfuscated information:

// Read from the table—this will have raw, encrypted data const readStmt = `SELECT msg, hash FROM ${tableName}`; const { results } = await db.prepare(readStmt).all(); console.log(results) // [ // { // "id": 1, // "msg": "rSIFVX0rCtKT6OMkWQD1TqKazrNg4B9nigsHUC/7dYkfjfW8erAZgNOHbO697gRoIVaL5Ry8GtsTsTjMyFLDMnNy6W9rmgCzgn5ALzBIUkog0VaI/NMdkCB44lUBr6EIsMdJ/2JhU8oIyLLXNv5mk+MD", // "hash": "3f98b95c16476f0b2fc37e8e664a11312966b635f60537f1f5ed75216fa0c060" // } // ]

Then, if the signer/caller that’s trying to decrypt the data meets the access control rules defined with the data was written, they’ll be able to decrypt the data above:

// Decrypt the data read from the table, using the data read from our table, // the access control conditions, and our authentication signature for (const row of results) { const { msg, hash } = row; const { decryptedData } = await client.decrypt({ accessControlConditions, // Set before writing data authSig, // SIWE signagure chain, // The chain that you're decrypting table dat from ciphertext: msg, // The value from the table above, created once encrypted dataToEncryptHash: hash, // The value from the table above, created once encrypted }); const decrypted = Buffer.from(decryptedData.buffer).toString(); console.log(`Decrypted data: '${decrypted}'`); } // Decrypted data: 'this is a secret message'

by Marla Natoli

If you’ve been following along with our weekly updates, you’ll know that DIMO is a partner of ours and has been pushing full steam ahead on building their network. DIMO is building a decentralized vehicle network that gives users ownership and control over their car data, rewarding contributors to the ecosystem via a native token, and enabling enterprises to offer services to these vehicles and vehicle owners. But, one of the most exciting things about DIMO is how it aligns incentives and creates the tools and services needed to enable developers to actively participate in creating the future of the mobility industry.

Their focus on open tools to empower developers aligns closely with our mission of creating decentralized data tools that enable developers to extract and maximize the value of data created on and by DePINs like DIMO. We have some exciting updates and deep dives into how we’re working together coming soon. In the meantime, be sure to check out the new resources they’re creating for developers interested in building on DIMO.

by Jim Kosem

Part of being a designer at Textile means doing a bit of everything. This means not just the user experience, but also visual design. This is great for me as a user experience designer, because my first degree is actually in graphic design, and that is what it is. We’re working on some web pages and visual explorations explaining just what it is we do here at Textile.

This has been a quickly evolving thing, but now that things are settling and new efforts like Basin are well underway, we can start thinking about how we tell and show the world what we’re doing. This means flexing some muscles you ordinarily don’t, looking at type, color, and rhythm significantly more than you would when you’re designing an interface. But, it still has to work in a browser and deal with many other aspects. And you have to think in terms of Minimum Viable Brand. How much can you express in one go while giving yourself enough room to move in terms of look and feel with other efforts that will develop alongside it?

There’s a lot to think about, especially in classic content terms. What goes where? What will change and what won’t? But that’s also design, so it’s part of the whole experience.

• We just wrapped up the Backdrop hackathon, and we’re amidst the Filecoin Data Economy hackathon (only 6 days left)! If you’re building in either of those, we look forward to seeing your projects and feel free to hop in our Discord for additional support.

Want to dive deeper, ask questions, or just nerd out with us? Jump into our Telegram or Discord—including weekly research office hours or developer office hours. And if you’d like to discuss any of these topics in more detail, comment on the issue over in GitHub!

Are you enjoying Weeknotes? We’d love your feedback—if you fill out a quick survey, we’ll be sure to reach out directly with community initiatives in the future!: Fill out the form here