• rcbrk@lemmy.ml
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 months ago

    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.

      • rcbrk@lemmy.ml
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        1 month ago

        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.

        • Kalcifer@sh.itjust.worksOP
          link
          fedilink
          arrow-up
          1
          ·
          30 days ago

          So, in this image, if the application server, the push server, and the distributor app have nothing to do with Unified Push, then where exactly does it come into play? What exactly is it doing? I was of the belief that Unified Push standardized the notification communication protocol with the application server, replacing things like Google Firebase (which, iiuc, is equivalent to the push server in the above diagram, and the distributor app being built into the phone — ie Android). What’s also confusing me in all this is what exactly a push gateway is doing. Ntfy, for example, implemented a Matrix Gateway [1][2], but I’m not exactly sure the point of that if it’s not doing anything with Unified Push (Matrix uses it’s own push API [3])

          References
          1. “Consider Including a Matrix Gateway endpoint as part of ntfy”. MayeulC. binwiederhier/ntfy. GitHub. Published: 2022-06-16T16:55:41Z. Accessed: 2024-11-23T00:25Z. https://github.com/binwiederhier/ntfy/issues/319.
          2. “Matrix gateway” (#326). binwiederhier. binwiederhier/ntfy. GitHub. Published: 2022-06-16T16:55:41Z. Accessed: 2024-11-23T00:25Z. https://github.com/binwiederhier/ntfy/pull/326.
          3. “Push Gateway API”. “Matrix Specification” (Version: 1.12). Matrix. Published: 2024. Accessed: 2024-11-23T00:23Z. https://spec.matrix.org/v1.12/push-gateway-api/.
          • rcbrk@lemmy.ml
            link
            fedilink
            English
            arrow-up
            2
            ·
            29 days ago

            I mean ntfy’s primary purpose is not dependent on UnifiedPush – all UP functionality could be removed and ntfy would still work as intended.

            Ntfy server knows how to be a UP gateway, and relays those messages to the ntfy app, which knows how to be a UP distributor.

            As far as I understand it, a client app using UP to recieve push notifications does perform a registration step with the UP gateway (via the distributor app which communicates with the gateway via its own transport), which sets up and responds with the api endpoint details, which the client app relays to its servers, which can then send UP notifications via the specified gateway.

            • Kalcifer@sh.itjust.worksOP
              link
              fedilink
              arrow-up
              1
              ·
              28 days ago

              As far as I understand it, a client app using UP to recieve push notifications does perform a registration step with the UP gateway (via the distributor app which communicates with the gateway via its own transport), which sets up and responds with the api endpoint details, which the client app relays to its servers, which can then send UP notifications via the specified gateway.

              So, if there was to be encryption done by UP, it would be handled by the gateway? For example, for Matrix, it would then be handled by the Matrix gateway in Ntfy [1]?

              References
              1. “Matrix gateway” (#326). binwiederhier. binwiederhier/ntfy. GitHub. Published: 2022-06-16T16:55:41Z. Accessed: 2024-11-23T00:25Z. https://github.com/binwiederhier/ntfy/pull/326.