What is the difference between a sealed box and a normal box in libsodium?
The premise of boxes is that Alice and Bob know each other and write to each other.  Alice can use a box to send a message to Bob.  On receipt of the box, Bob knows (a) it came from Alice, and (b) nobody else could have read or tampered with it.

The premise of sealed boxes is that Bob has an anonymous dropbox.  Alice can use a sealed box to send a message to Bob.  On receipt of the box, Bob knows nobody but the sender could have read or tampered with it.  But he knows nothing about who the sender was—it could have been Alice, or Charlie, or Dominique.

The nonce is only required to be distinct for each message Alice sends to Bob, and vice versa.  For example, Alice might count the number of messages she has sent so far, and use that number as a nonce.  If the nonce is large enough, say ≥192, as it is in crypto_box_curve25519xsalsa20poly1305 (but not crypto_box_nistp256aes256gcm where it is 96), it can safely be chosen uniformly at random for each message and affixed to the ciphertext.  The nonce need not be secret.

Neither boxes nor sealed boxes enables a third party to verify the authenticity of a message.  For that, you need digital signatures.

If Bob's private key is ever compromised, whether for boxes or for sealed boxes, or if Alice's private key for boxes is ever compromised, then any message Alice has sent to Bob can be decrypted.  To avoid this, protocols like Signal (a) regularly generate new keys and promptly erase the old keys for things like boxes,* and (b) use long-term key pairs only for digital signatures to assert what the user's current box public key is, so that compromising the long-term private keys doesn't enable retroactive decryption.



* A protocol that prescribes when to promptly erase keys is sometimes said to have ‘forward secrecy’, a term I prefer to avoid because in its glibness it obscures when the keys can be erased—which obscurity may serve to conceal lurking vulnerabilities like TLS session resumption even in sessions that use ‘forward secrecy’ cipher suites with ephemeral Diffie–Hellman key agreement.