Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Digital Signature Comments Block for Ark UI

A contract review thread where Sign and post opens a dialog for a typed name, an optional drawn mark and consent, then stamps the comment with a SHA-256 hash that Verify can check.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Sign a comment so you can tell later whether it changed, with this signed comment for React with Ark UI. A compact header names the review and holds the real trigger, Sign and post, which opens a Dialog. The page shows the dialog open in place over the thread for the preview; the thread has two earlier comments, your own comment in a Textarea and a stamp box. The dialog asks for a full name in an Input, a Signature Pad for a drawn mark that is optional because drawing needs a pointer, and a consent tick; the one primary, a Shine Button, says what it is waiting for until the name and the tick are there. Signing fills the stamp: the mark or the typed name, Signed in this demo, and the first 16 hex characters of the SHA-256 of the comment, worked out in the page with the browser's own crypto. Verify works it out again and says Hash matches, or No longer matches once the text was edited. It is built from Dialog, Input, Signature Pad, Textarea, Shine Button, Button, Badge and Guides. For contract review, approvals and any thread where wording must not drift.

FAQ

What is the hash?

The SHA-256 of the comment text, worked out with the browser's crypto.subtle, shown as its first 16 hex characters. Verify hashes the text again and compares. Edit one letter and it no longer matches. The page needs a secure context (https or localhost); without one the stamp says Hashing needs a secure page.

What is the preview and what is real?

On load the dialog is drawn in place, a non-modal copy over the thread, so nothing is trapped or focused. Sign and post opens the real dialog with its focus trap, Escape and focus return, sharing the same fields and state; the in-place copy stays closed until a reload. In your app keep the Dialog and delete the in-place copy.

What stays local?

The name, the mark, the text and the hash. Nothing is stored or sent. To make it real, send the text, the name, the mark and a server timestamp to your server, store the hash there and compute it again on the server when someone verifies, because a browser can be changed by anyone who has it open.

Is it accessible?

Drawing needs a pointer, so the mark is optional and the typed name is what counts: a keyboard user can sign. Every field has a visible label, the primary says what it is waiting for, and a missing name is reported and focused. The stamp is real text, the hash is left to right, and the polite status line speaks each result.

How does it look on a phone?

The in-place dialog docks to the foot of the stage with its actions pinned, and the real dialog keeps the catalog's phone layout. The stamp stacks the mark above its details and the stage scrolls inside itself.