If you have a secret (text) that you want to communicate to someone then submit your text to One Time Link and it will give you a link to send to them (by secure means).
Make sure you communicate that link to someone via a secure means (like Signal, WhatsApp). If you send the link to someone using a non-secure means like email then you are exposed to a man-in-the-middle attack in that someone else can intercept the link, view it, then create another link to forward to the receiving party. Neither the sender nor the receiving part are aware of the leaking of the secret.
If the receiver of the link cannot view the secret then it is possible that the secret has been compromised by a third party. This is really only possible if the transport mechanism you use has been compromised (like non-TLS email). In this situation the original secret should be changed and resent (perhaps by another transport method!).
Version: 1.0.23, git commit cf92b43
Full source code for this version's implementation is here.
The critical part of this implementation is coming up with an easy cheap way of guaranteeing exactly-once delivery. Yes you could achieve this using a database that supports transactions but there is another much simpler and cheaper way:
create one new FIFO SQS queue per message which is disposed of on message view.
AWS Lambda is a great cheap solution to run the backend serverless but occasionally a user may encounter a six second delay while a new backend server is provisioned ("cold start"). Not a big deal every now and then.
Notes:
There's nothing that guarantees that every message is read so we also need to perform a cleanup to deal with unread messages building up in storage and queues. Every 12 hours an AWS Lambda function iterates the S3 data bucket objects, inspects the expiry time metadata and every message that has expired is removed (and its associated queue deleted).