Taking a Look at Recent Stacks.js Improvements

New Feature Support: Arbitrary Message Signing

We recently released arbitrary message signing for the Hiro Wallet, which allows users to prove they have control over a wallet address as well as sign the content of any type of message that they authorize for usage elsewhere in the same application or in later downstream on-chain effects. The implementation is based on the SIP-018 proposal, which is in the process of being activated. 

This feature enables developers to create token-gated features that grant access to special privileges, off-chain mechanisms that require later settlement on-chain, and more. In short, arbitrary message signing makes these use cases possible by introducing a way for people to authorize specific actions once specific conditions are met.

To make it easy to implement arbitrary message signing in your application, we have added methods in @stacks/connect. Using this library, you can have this feature up and running in your application with just a few lines of code.

Learn more about arbitrary message signing in Hiro documentation here, and see how Sigle used arbitrary message signing to implement token-gated features in their app here. Support for this feature was added in Stacks.js version 4.3.0.

Network Customization

We added a number of new customizations in Stacks.js to give developers more control with how they interact with their users and with the Stacks network. One less visible, but very useful change came with Stacks.js version 4.1.0, which added more options to inspect, intercept, and modify network requests sent by Stacks.js methods.

Developers can customize currently used network objects with their own middleware, allowing arbitrary actions before and after Stacks.js methods send requests. Use-cases for this could include logging to the console to debug requests, adding fetch Request and Response options, customizing and overriding responses received by the Hiro API, and more.  Learn more here.

For simple things, like adding optional headers to requests, we also added the ability to customize a global parameter to fine-tune how Stacks.js sends network requests. With this change, developers can now customize headers and other default options. For this, the setFetchOptions method was added in version 4.0.1. Calling setFetchOptions lets developers set any valid ResponseInit, which will be merged with previously set fetch options.

import { setFetchOptions } from '@stacks/common';

setFetchOptions({
  headers: [
    ['X-Header', 'Hello header!'],
  ],
});

Removing Username From Authentication Responses

With the release of Stacks.js version 4.0.0, we removed the username from authentication responses. Usernames can be seen as an additional feature (for example, BNS, running in their own smart contract) and aren’t needed in the authentication protocol. This change is also important since anybody can host a registrar (for their own BNS top level domain), and authentication shouldn’t be blocked by a potentially offline registrar.

Depending on the use-case, it may be more secure to lookup the usernames attached to an address separately (potentially even from the backend, using a self-hosted node/API).

If your app was relying on the username being returned, you can switch to looking up a username with the getNamesOwnedByAddress method.

Follow the discussion here for more information.

Streamlining Stacks.js for a Better Experience

Alongside these changes, we’ve made a host of smaller, but still notable, improvements. Importantly, we’ve been removing old/large dependencies and replacing them with smaller, more modern alternatives. For example, we switched from elliptic to @noble/secp256k1. Similarly, we’re also actively reducing the amount of polyfilling needed to account for legacy web browsers.

These changes have allowed us to ship 37% smaller Stacks.js packages to browsers on average (sometimes up to 80% smaller). 📦

Conclusion

As you can see with the improvements above, Hiro is actively working on making Stacks.js a more useful resource for developers. The best part? We have plenty more improvements on the way. If there’s anything in particular you’d like to see, let us know about it by starting an issue on GitHub.