Not really. “Use” isn’t a well defined word in this context.
The ntfy server/client and the protocol it uses is merely the conduit for the UnifiedPush protocol. Sort of like how tls or ssl are a conduit for http.
In its typical primary use, ntfy is unrelated to UnifiedPush.
I think a lot of comments have missed that ntfy.sh does not use UnifiedPush, the ntfy server is a UnifiedPush provider and the ntfy app is a UnifiedPush distributor.
Regarding encryption of the push message, from https://unifiedpush.org/developers/spec/android/ :
Push message: This is an array of bytes (ByteArray) sent by the application server to the push server. The distributor sends this message to the end user application. It MUST be the raw POST data received by the push server (or the rewrite proxy if present). The message MUST be an encrypted content that follows RFC8291. Its size is between 1 and 4096 bytes (inclusive).
Something from here, if you want an Android device: https://wiki.lineageos.org/devices/
It’s important that shitty things don’t surprise us out of nowhere, that there’s a history of calling out the red flags on something like this while it was in development; eg: https://lemmy.ml/post/139820
I’m partial to thumbkey. It even has a Lemmy community: !thumbkey@lemmy.ml
Here are the github repository, issues and comments immortalised for posterity in IPFS:
The issues and comments are in github json format – if anyone wants to collate them into a human-readable text or html file, please do so.
Edit: Its immortality of course depends on you to access and pin the content.
It doesn’t matter. Even if the ntfy message was plaintext, that plaintext content would be a UnifiedPush “Push message” which is the RFC8291-encrypted raw POST data.