The Secret Sharing API allows to share a secret message, that can by default only viewed once and then it is destroyed. However, the number of views as well as TTL are configurable.
The secret text can also be secured by a passphrase. The viewer of the secret text must then insert the passphrase to view the secret.
The good: your code is lucid, direct, and very easy to navigate. That's huge - people struggle with that, and you've done well here. I had no trouble finding what I was interested in, and it's clear how I'd want to reorganize things if this service were to grow new capabilities.
The bad: secret encryption is done in a completely useless way, because the key used to encrypt a secret is stored (in the clear) alongside the secret itself. Anyone with access to the database can trivially and quickly decrypt all secrets. This is mitigated to a degree because secrets are destroyed once read or once they expired, but it's still not good.
My recommendations are:
If the design assumes that users trust the service to hold secret data, remove the encryption entirely, or replace it with a single service-wide key provided by the administrator. If key rotation is a factor, then per-secret keys that are then encrypted with a service-wide key are also an option.
If the design assumes that users don't trust the service to hold secrets at rest, but do trust the service to hold secrets transiently while storing or retrieving them, then derive the per-secret key from the caller-provided password using any standard key derivation function, and don't store it, anywhere. Alternately, generate a key, and store it as a password-protected PKCS #12 document (using the caller-provided password), rather than in the clear.
If the design assumes that users don't trust the service with secrets at all, then have the caller handle encryption and decryption and deal with key distribution. This would substantially reduce the usefulness of this service, but it's a proof of concept anyways, so I don't think that's overly concerning.