Blind Attempt: Nillion Secret Manager

By Anton Pyrogovskyi • 6 minutes read •

Table of Contents

After my recent experience building the Nillion Wordle game, it was about time to build something with more practical utility. Enter Nillion Secret Manager , a web app to store and manage secrets on the Nillion testnet! The goal of the Secret Manager is to provide users with a secure and user-friendly platform to store secrets on the Nillion testnet, inspect, update and delete them and grant and revoke access to other users.

Unlike Wordle, this does not use any Nada programs. We can get the functionality we need by just using the React hooks provided by the Nillion JS SDK (specifically, @nillion/client-react-hooks). Also unlike Wordle which is pretty much client-only, this is much more backend-heavy. We need the backend to store the data that is required for the user to always come back to the secrets they added previously. We also need a reliable method to authenticate the user and ensure that something like peeking at another user’s list of stored secrets is not possible. The Secret Manager itself does not store any secret data though, only metadata.

Other than providing a classic CRUD interface with some rounded corners, it helps the user keep an overview of their current secrets by providing controls to:

… and of course it validates the inputs to ensure that if you can add the secret, you will also be able to use it later on.

As such, it currently provides a more user-friendly way to manage secrets than using the SDK utilities such as the nillion CLI directly. That said, it is compatible with pre-existing Nillion tools and you can easily get a secret’s store ID by viewing it so you can use it as an input anywhere you need.

Nillion Secret Manager uses:

For more details you can inspect the source in the GitHub repo .

Research and Development

According to my (brief) research, it did not seem like anything resembling the Secret Manager existed for Nillion yet.

During development of the Secret Manager, there were a couple of minor issues I ran into. Since they seem to apply to the SDK in general, I hope that this information will be useful for other Nillion app builders.

Mixed Content Violation

“Mixed content” is when a page that is loaded via HTTPS wants to load HTTP resources over an insecure connection. This is undesirable and Chrome for example will simply block the resource from being loaded and log a console error. Because of the default testnet JSON RPC URL being http://, it triggered a mixed content violation in Chrome.

While this is not an issue when testing locally as you would be accessing the page through HTTP anyway (no mixed content there), this came up as soon as the Manager was deployed. I am not sure why this did not seem to be a problem before as the http:// URL has always been used.

Anyhow, it was fixed by commit 04d18fa , specifying the network parameters manually and using a https:// URL for the JSON RPC as that seems to work just as well while resolving the mixed content warning.

Debugging with SDK v0.7.0

Another thing to note was related to debugging occasional failures which has changed in Nillion JS SDK v0.7.0. Specifically, errors messages generated by the effect library are no longer automatically visible in the devtools console. This causes errors from inside the Nillion SDK libraries which are actually specific and well-defined to present as a generic Fiber Failure: Unknown Error when logged to the devtools console.

1.png

Which, of course, is not at all helpful for debugging and can result in spending a lot of time on head scratching… In fact, there doesn’t seem to be anything you can do to this error to get its underlying cause.

However, it turns out there is a workaround to read the underlying error:

  1. Install React Dev Tools. If you open the devtools console on a React-powered website like the Secret Manager it will give you a link to do that anyhow.

  2. Use console.log to print out the entire object returned by the Nillion React hook itself (e.g. useNilStoreValues). While odd, it is important that you console.log the entire object and not just the .error field which will just always give you the generic unhelpful message. Doing this shows the error field inside the object which can then be inspected for the real cause of the failure which is stored under the properties starting with Effect/!

Sometimes you might also need to traverse a few levels of indirection there…

2.png

But you do get the actual cause of the error, which here is “Request rejected”, ie. the user clicked “cancel” on the confirmation dialog for the transaction. This seems to work for figuring out all Nillion SDK errors I have ran into so far.

From what I have heard, the dev team is aware of the issue and working to fix it in the next release. Fingers crossed! 🤞

Conclusion

Since the Nillion Secret Manager follows the basic CRUD pattern quite closely, it was a fairly simple idea to plan and execute.

But of course, the devil is in the details. I have probably spent about 50/50 time between the backend and the frontend here, even though the volume of the backend code is a lot less. Exactly how to store data in the backend and how to ensure that the app is secure required some planning and testing. However, I am quite happy with how it turned out and how the server-side database is structured now.

Thanks for reading and stay tuned for more Nillion dev projects! Great things are coming. ✌️