pinetree_raccoon I never tried running MollySocket with a VAPID key. I'm not sure if ntfy supports that...
Apart from that, is your ntfy user authorized in ntfy for that topic r/w? That's the first thing I would check.

i do not have a ntfy user set up on this container. how can i accomplish this and allow the mollysocket to publish to it?

    pinetree_raccoon just found out, no user auth needed. That only leaves the VAPID key here. Could you try commenting that line out in your docker-compose.yml and rebuilding the container? Just for testing purposes.

    Turn RUST_LOG to debug instead of info.

    pinetree_raccoon alright, seems like the key is configured in systemd-creds (hopefully correctly, if that error message wasn't there before). I think the next step would be to remove the comment (#) and spin up the container again. See if that changes anything (also run that command again that I posted above). If that doesn't help, the next best thing would be to re-register MollyUP again. To do that, change the "Delivery Method" in Molly's notification settings back to WebSocket. This will cut the connection to Mollysocket, allowing the app to attempt a reconnection once you switch to UnifiedPush again.

    MollySocket

    now when i go to molly.mydomain.com i get the below, which is what i had before when it still wasnt working. i did turn rust log to debug as well.

    Scan the folowing QR code to link mollysocket, or enter the following link manually:

    mollysocket://link?vapid=XXXl=https%3A%2F%2Fmolly.mydomain.com%2F&type=webserver

    Wish to use in airgapped mode ?

    Version 1.5.1

    there is a big QR code. i try to scan with molly app linked devices but it says it is invalid.

    but when i use:
    docker compose run mollysocket connection ping c8d44128-5c99-4810-a7d3-71c079891c27

    i get:
    [2024-10-30T02:06:43Z DEBUG mollysocket::cli] env_logger initialized
    C[2024-10-30T02:06:44Z INFO mollysocket::config] No config file supplied
    [2024-10-30T02:06:44Z INFO mollysocket::vapid] VAPID public key: "XXXXXXXXXX"
    [2024-10-30T02:06:44Z DEBUG reqwest::connect] starting new connection: https://ntfy.mydomain.com/
    thread 'main' panicked at src/cli/connection.rs:125:28:
    called Result::unwrap() on an Err value: HTTP status client error (403 Forbidden) for url (https://ntfy.mydomain.com/upqQWEnlwH0yC7?up=1)

    Location:
    src/utils.rs:15:5
    note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

      pinetree_raccoon

      but when i use:
      docker compose run mollysocket connection ping c8d44128-5c99-4810-a7d3-71c079891c27

      you hopefully did replace the c8xxx string with your accountid though.
      The steps you described above is nothing I did, probably because I didn't use VAPID.
      For me, it was just settings the URL of mollysocket in MollyUP, getting the account id, parsing that into the docker-compose.yml, spinning up the container and it was good to go.
      I don't really understand how VAPID is supposed to work, the documentation is basically nonexistent. The ntfy container somehow needs to know the public key and I think there's the problem if you didn't configure it anywhere in ntfy's config, the server can't authenticate and throws a 403...

      yeah, I'm at a loss now. I set up the VAPID stuff on my instance (I don't know if I did that correctly) and it somehow just connected. I have mollysocket as a linked device now in my settings fwiw. I don't understand why the QR code is still being shown though when my website is reached, but that shouldn't matter in terms of security.

      pinetree_raccoon fixed it. F*****G hell, this is the worst piece of software ever designed. Here's what I did:

      • on the server, run: docker exec -it mollysocket sh
      • run: mollysocket vapid generate
      • the newly generated key appears. Copy that to the clipboard
      • exit the sh with exit
      • edit the docker-compose.yml and replace old private key with the one you just copied
      • rebuild container

      now comes the fun part:

      • try to break the connection to the mollysocket. Edit the "server url" in MollyUP UnifiedPush submenu to some random nonsense until it shows "server not found"
      • disable UnifiedPush by setting it to WebSocket
      • now, scan the QR code with your camera. If the text copies to clipboard, open in browser. It should appear as if nothing happened when you hit enter.
      • go to MollyUP. Enable UnifiedPush again and enter your correct domain back in the "Server URL" field.
      • it should try to establish a connection and say "OK"
      • under linked devices there should be a new "MollySocket" device

      I hope this works for you. Seems like the buggiest crap ever created.

      still having some issues. can you link me a sample for your mollysocket compose file and your ntfy compose file and i will start from scratch.

      Here's the compose for my ntfy:

      services:
      ntfy:
      image: binwiederhier/ntfy
      container_name: ntfy
      command:
      - serve
      environment:
      - TZ=UTC # optional: set desired timezone
      - auth_file="/etc/ntfy/auth.db"
      #user: UID:GID # optional: replace with your own user/group or uid/gid
      volumes:
      - /var/cache/ntfy:/var/cache/ntfy
      - /etc/ntfy:/etc/ntfy
      ports:
      - 8413:80
      healthcheck: # optional: remember to adapt the host:port to your environment
      test: ["CMD-SHELL", "wget -q --tries=1 http://localhost:8413/v1/health -O - | grep -Eo '\"healthy\"\s:\strue' || exit 1"]
      interval: 60s
      timeout: 10s
      retries: 3
      start_period: 40s
      restart: always

      and here's the docker compose for Mollysocket:

      services:
      mollysocket:
      image: ghcr.io/mollyim/mollysocket:1
      container_name: mollysocket
      restart: always
      volumes:
      - ./data:/data
      working_dir: /data
      command: server
      environment:
      - MOLLY_DB="/data/mollysocket.db"
      comment-># Do not add space in the array ["http://a.tld","*"]
      - MOLLY_ALLOWED_ENDPOINTS=["https://myntfy.mydomain.com/"]
      - MOLLY_ALLOWED_UUIDS=["uuid-string-here"]
      - MOLLY_HOST=192.168.50.170
      - MOLLY_PORT=8020
      - RUST_LOG=info
      - MOLLY_VAPID_PRIVKEY=VERYSECRETKEYHERE
      ports:
      - "8020:8020"
      network_mode: host

      As for the general setup, there's an nginx reverse proxy configured to handle TLS and a host for the Mollysocket, internal scheme http, port 8020. Ntfy is the same but with port 8413. Both have of course a distinct subdomain. The only difference is, I used to set up users for ntfy but found out that it's not required after all. So I think that's not the problem here.

      Edit: since it might be relevant, this is also the contents of the server.yml in /etc/ntfy:

      #
      # Please refer to the documentation at https://ntfy.sh/docs/config/ for details.
      # All options also support underscores (_) instead of dashes (-) to comply with the YAML spec.
      
      # Public facing base URL of the service (e.g. https://ntfy.sh or https://ntfy.example.com)
      #
      # This setting is required for any of the following features:
      # - attachments (to return a download URL)
      # - e-mail sending (for the topic URL in the email footer)
      # - iOS push notifications for self-hosted servers (to calculate the Firebase poll_request topic)
      # - Matrix Push Gateway (to validate that the pushkey is correct)
      #
      base-url: https://myntfy.mydomain.com
      
      # Listen address for the HTTP & HTTPS web server. If "listen-https" is set, you must also
      # set "key-file" and "cert-file". Format: [<ip>]:<port>, e.g. "1.2.3.4:8080".
      #
      # To listen on all interfaces, you may omit the IP address, e.g. ":443".
      # To disable HTTP, set "listen-http" to "-".
      #
      # listen-http: ":80"
      # listen-https:
      
      # Listen on a Unix socket, e.g. /var/lib/ntfy/ntfy.sock
      # This can be useful to avoid port issues on local systems, and to simplify permissions.
      #
      # listen-unix: <socket-path>
      # listen-unix-mode: <linux permissions, e.g. 0700>
      
      # Path to the private key & cert file for the HTTPS web server. Not used if "listen-https" is not set.
      #
      # key-file: <filename>
      # cert-file: <filename>
      
      # If set, also publish messages to a Firebase Cloud Messaging (FCM) topic for your app.
      # This is optional and only required to save battery when using the Android app.
      #
      # firebase-key-file: <filename>
      
      # If "cache-file" is set, messages are cached in a local SQLite database instead of only in-memory.
      # This allows for service restarts without losing messages in support of the since= parameter.
      #
      # The "cache-duration" parameter defines the duration for which messages will be buffered
      # before they are deleted. This is required to support the "since=..." and "poll=1" parameter.
      # To disable the cache entirely (on-disk/in-memory), set "cache-duration" to 0.
      # The cache file is created automatically, provided that the correct permissions are set.
      #
      # The "cache-startup-queries" parameter allows you to run commands when the database is initialized,
      # e.g. to enable WAL mode (see https://phiresky.github.io/blog/2020/sqlite-performance-tuning/)).
      # Example:
      #    cache-startup-queries: |
      #       pragma journal_mode = WAL;
      #       pragma synchronous = normal;
      #       pragma temp_store = memory;
      #       pragma busy_timeout = 15000;
      #       vacuum;
      #
      # The "cache-batch-size" and "cache-batch-timeout" parameter allow enabling async batch writing
      # of messages. If set, messages will be queued and written to the database in batches of the given
      # size, or after the given timeout. This is only required for high volume servers.
      #
      # Debian/RPM package users:
      #   Use /var/cache/ntfy/cache.db as cache file to avoid permission issues. The package
      #   creates this folder for you.
      #
      # Check your permissions:
      #   If you are running ntfy with systemd, make sure this cache file is owned by the
      #   ntfy user and group by running: chown ntfy.ntfy <filename>.
      #
      cache-file: /var/cache/ntfy/cache.db
      cache-duration: "24h"
      cache-startup-queries:
        pragma journal_mode = WAL;
        pragma synchronous = normal;
        pragma temp_store = memory;
        pragma busy_timeout = 15000;
        vacuum;
      # cache-batch-size: 0
      # cache-batch-timeout: "0ms"
      
      # If set, access to the ntfy server and API can be controlled on a granular level using
      # the 'ntfy user' and 'ntfy access' commands. See the --help pages for details, or check the docs.
      #
      # - auth-file is the SQLite user/access database; it is created automatically if it doesn't already exist
      # - auth-default-access defines the default/fallback access if no access control entry is found; it can be
      #   set to "read-write" (default), "read-only", "write-only" or "deny-all".
      # - auth-startup-queries allows you to run commands when the database is initialized, e.g. to enable
      #   WAL mode. This is similar to cache-startup-queries. See above for details.
      #
      # Debian/RPM package users:
      #   Use /var/lib/ntfy/user.db as user database to avoid permission issues. The package
      #   creates this folder for you.
      #
      # Check your permissions:
      #   If you are running ntfy with systemd, make sure this user database file is owned by the
      #   ntfy user and group by running: chown ntfy.ntfy <filename>.
      #
      auth-file: /var/cache/ntfy/auth.db
      auth-default-access: "read-write"
      auth-startup-queries:
        pragma journal_mode = WAL;
        pragma synchronous = normal;
        pragma temp_store = memory;
        pragma busy_timeout = 15000;
        vacuum;
      # If set, the X-Forwarded-For header is used to determine the visitor IP address
      # instead of the remote address of the connection.
      #
      # WARNING: If you are behind a proxy, you must set this, otherwise all visitors are rate limited
      #          as if they are one.
      #
      behind-proxy: true
      
      # If enabled, clients can attach files to notifications as attachments. Minimum settings to enable attachments
      # are "attachment-cache-dir" and "base-url".
      #
      # - attachment-cache-dir is the cache directory for attached files
      # - attachment-total-size-limit is the limit of the on-disk attachment cache directory (total size)
      # - attachment-file-size-limit is the per-file attachment size limit (e.g. 300k, 2M, 100M)
      # - attachment-expiry-duration is the duration after which uploaded attachments will be deleted (e.g. 3h, 20h)
      #
      # attachment-cache-dir:
      # attachment-total-size-limit: "5G"
      # attachment-file-size-limit: "15M"
      # attachment-expiry-duration: "3h"
      
      # If enabled, allow outgoing e-mail notifications via the 'X-Email' header. If this header is set,
      # messages will additionally be sent out as e-mail using an external SMTP server.
      #
      # As of today, only SMTP servers with plain text auth (or no auth at all), and STARTLS are supported.
      # Please also refer to the rate limiting settings below (visitor-email-limit-burst & visitor-email-limit-burst).
      #
      # - smtp-sender-addr is the hostname:port of the SMTP server
      # - smtp-sender-from is the e-mail address of the sender
      # - smtp-sender-user/smtp-sender-pass are the username and password of the SMTP user (leave blank for no auth)
      #
      # smtp-sender-addr:
      # smtp-sender-from:
      # smtp-sender-user:
      # smtp-sender-pass:
      
      # If enabled, ntfy will launch a lightweight SMTP server for incoming messages. Once configured, users can send
      # emails to a topic e-mail address to publish messages to a topic.
      #
      # - smtp-server-listen defines the IP address and port the SMTP server will listen on, e.g. :25 or 1.2.3.4:25
      # - smtp-server-domain is the e-mail domain, e.g. ntfy.sh
      # - smtp-server-addr-prefix is an optional prefix for the e-mail addresses to prevent spam. If set to "ntfy-",
      #   for instance, only e-mails to ntfy-$topic@ntfy.sh will be accepted. If this is not set, all emails to
      #   $topic@ntfy.sh will be accepted (which may obviously be a spam problem).
      #
      # smtp-server-listen:
      # smtp-server-domain:
      # smtp-server-addr-prefix:
      
      # Web Push support (background notifications for browsers)
      #
      # If enabled, allows ntfy to receive push notifications, even when the ntfy web app is closed. When enabled, users
      # can enable background notifications in the web app. Once enabled, ntfy will forward published messages to the push
      # endpoint, which will then forward it to the browser.
      #
      # You must configure web-push-public/private key, web-push-file, and web-push-email-address below to enable Web Push.
      # Run "ntfy webpush keys" to generate the keys.
      #
      # - web-push-public-key is the generated VAPID public key, e.g. AA1234BBCCddvveekaabcdfqwertyuiopasdfghjklzxcvbnm1234567890
      # - web-push-private-key is the generated VAPID private key, e.g. AA2BB1234567890abcdefzxcvbnm1234567890
      # - web-push-file is a database file to keep track of browser subscription endpoints, e.g. `/var/cache/ntfy/webpush.db`
      # - web-push-email-address is the admin email address send to the push provider, e.g. `sysadmin@example.com`
      # - web-push-startup-queries is an optional list of queries to run on startup`
      #
      # web-push-public-key:
      # web-push-private-key:
      # web-push-file:
      # web-push-email-address:
      # web-push-startup-queries:
      
      # If enabled, ntfy can perform voice calls via Twilio via the "X-Call" header.
      #
      # - twilio-account is the Twilio account SID, e.g. AC12345beefbeef67890beefbeef122586
      # - twilio-auth-token is the Twilio auth token, e.g. affebeef258625862586258625862586
      # - twilio-phone-number is the outgoing phone number you purchased, e.g. +18775132586
      # - twilio-verify-service is the Twilio Verify service SID, e.g. VA12345beefbeef67890beefbeef122586
      #
      # twilio-account:
      # twilio-auth-token:
      # twilio-phone-number:
      # twilio-verify-service:
      
      # Interval in which keepalive messages are sent to the client. This is to prevent
      # intermediaries closing the connection for inactivity.
      #
      # Note that the Android app has a hardcoded timeout at 77s, so it should be less than that.
      #
      keepalive-interval: "60s"
      
      # Interval in which the manager prunes old messages, deletes topics
      # and prints the stats.
      #
      # manager-interval: "1m"
      
      # Defines topic names that are not allowed, because they are otherwise used. There are a few default topics
      # that cannot be used (e.g. app, account, settings, ...). To extend the default list, define them here.
      #
      # Example:
      #   disallowed-topics:
      #     - about
      #     - pricing
      #     - contact
      #
      # disallowed-topics:
      
      # Defines the root path of the web app, or disables the web app entirely.
      #
      # Can be any simple path, e.g. "/", "/app", or "/ntfy". For backwards-compatibility reasons,
      # the values "app" (maps to "/"), "home" (maps to "/app"), or "disable" (maps to "") to disable
      # the web app entirely.
      #
      # web-root: /
      
      # Various feature flags used to control the web app, and API access, mainly around user and
      # account management.
      #
      # - enable-signup allows users to sign up via the web app, or API
      # - enable-login allows users to log in via the web app, or API
      # - enable-reservations allows users to reserve topics (if their tier allows it)
      #
      # enable-signup: false
      # enable-login: false
      # enable-reservations: false
      
      # Server URL of a Firebase/APNS-connected ntfy server (likely "https://ntfy.sh").
      #
      # iOS users:
      #   If you use the iOS ntfy app, you MUST configure this to receive timely notifications. You'll like want this:
      #   upstream-base-url: "https://ntfy.sh"
      #
      # If set, all incoming messages will publish a "poll_request" message to the configured upstream server, containing
      # the message ID of the original message, instructing the iOS app to poll this server for the actual message contents.
      # This is to prevent the upstream server and Firebase/APNS from being able to read the message.
      #
      # - upstream-base-url is the base URL of the upstream server. Should be "https://ntfy.sh".
      # - upstream-access-token is the token used to authenticate with the upstream server. This is only required
      #   if you exceed the upstream rate limits, or the uptream server requires authentication.
      #
      # upstream-base-url:
      # upstream-access-token:
      
      # Rate limiting: Total number of topics before the server rejects new topics.
      #
      global-topic-limit: 50
      
      # Rate limiting: Number of subscriptions per visitor (IP address)
      #
      visitor-subscription-limit: 20
      
      # Rate limiting: Allowed GET/PUT/POST requests per second, per visitor:
      # - visitor-request-limit-burst is the initial bucket of requests each visitor has
      # - visitor-request-limit-replenish is the rate at which the bucket is refilled
      # - visitor-request-limit-exempt-hosts is a comma-separated list of hostnames, IPs or CIDRs to be
      #   exempt from request rate limiting. Hostnames are resolved at the time the server is started.
      #   Example: "1.2.3.4,ntfy.example.com,8.7.6.0/24"
      #
      # visitor-request-limit-burst: 60
      # visitor-request-limit-replenish: "5s"
      # visitor-request-limit-exempt-hosts: ""
      
      # Rate limiting: Hard daily limit of messages per visitor and day. The limit is reset
      # every day at midnight UTC. If the limit is not set (or set to zero), the request
      # limit (see above) governs the upper limit.
      #
      # visitor-message-daily-limit: 0
      
      # Rate limiting: Allowed emails per visitor:
      # - visitor-email-limit-burst is the initial bucket of emails each visitor has
      # - visitor-email-limit-replenish is the rate at which the bucket is refilled
      #
      # visitor-email-limit-burst: 16
      # visitor-email-limit-replenish: "1h"
      
      # Rate limiting: Attachment size and bandwidth limits per visitor:
      # - visitor-attachment-total-size-limit is the total storage limit used for attachments per visitor
      # - visitor-attachment-daily-bandwidth-limit is the total daily attachment download/upload traffic limit per visitor
      #
      visitor-attachment-total-size-limit: "50M"
      visitor-attachment-daily-bandwidth-limit: "100M"
      
      # Rate limiting: Enable subscriber-based rate limiting (mostly used for UnifiedPush)
      #
      # If enabled, subscribers may opt to have published messages counted against their own rate limits, as opposed
      # to the publisher's rate limits. This is especially useful to increase the amount of messages that high-volume
      # publishers (e.g. Matrix/Mastodon servers) are allowed to send.
      #
      # Once enabled, a client may send a "Rate-Topics: <topic1>,<topic2>,..." header when subscribing to topics via
      # HTTP stream, or websockets, thereby registering itself as the "rate visitor", i.e. the visitor whose rate limits
      # to use when publishing on this topic. Note: Setting the rate visitor requires READ-WRITE permission on the topic.
      #
      # UnifiedPush only: If this setting is enabled, publishing to UnifiedPush topics will lead to a HTTP 507 response if
      # no "rate visitor" has been previously registered. This is to avoid burning the publisher's "visitor-message-daily-limit".
      #
      # visitor-subscriber-rate-limiting: false
      
      # Payments integration via Stripe
      #
      # - stripe-secret-key is the key used for the Stripe API communication. Setting this values
      #   enables payments in the ntfy web app (e.g. Upgrade dialog). See https://dashboard.stripe.com/apikeys.
      # - stripe-webhook-key is the key required to validate the authenticity of incoming webhooks from Stripe.
      #   Webhooks are essential up keep the local database in sync with the payment provider. See https://dashboard.stripe.com/webhooks.
      # - billing-contact is an email address or website displayed in the "Upgrade tier" dialog to let people reach
      #   out with billing questions. If unset, nothing will be displayed.
      #
      # stripe-secret-key:
      # stripe-webhook-key:
      # billing-contact:
      
      # Metrics
      #
      # ntfy can expose Prometheus-style metrics via a /metrics endpoint, or on a dedicated listen IP/port.
      # Metrics may be considered sensitive information, so before you enable them, be sure you know what you are
      # doing, and/or secure access to the endpoint in your reverse proxy.
      #
      # - enable-metrics enables the /metrics endpoint for the default ntfy server (i.e. HTTP, HTTPS and/or Unix socket)
      # - metrics-listen-http exposes the metrics endpoint via a dedicated [IP]:port. If set, this option implicitly
      #   enables metrics as well, e.g. "10.0.1.1:9090" or ":9090"
      #
      # enable-metrics: false
      # metrics-listen-http:
      
      # Profiling
      #
      # ntfy can expose Go's net/http/pprof endpoints to support profiling of the ntfy server. If enabled, ntfy will listen
      # on a dedicated listen IP/port, which can be accessed via the web browser on http://<ip>:<port>/debug/pprof/.
      # This can be helpful to expose bottlenecks, and visualize call flows. See https://pkg.go.dev/net/http/pprof for details.
      #
      # profile-listen-http:
      
      # Logging options
      #
      # By default, ntfy logs to the console (stderr), with an "info" log level, and in a human-readable text format.
      # ntfy supports five different log levels, can also write to a file, log as JSON, and even supports granular
      # log level overrides for easier debugging. Some options (log-level and log-level-overrides) can be hot reloaded
      # by calling "kill -HUP $pid" or "systemctl reload ntfy".
      #
      # - log-format defines the output format, can be "text" (default) or "json"
      # - log-file is a filename to write logs to. If this is not set, ntfy logs to stderr.
      # - log-level defines the default log level, can be one of "trace", "debug", "info" (default), "warn" or "error".
      #   Be aware that "debug" (and particularly "trace") can be VERY CHATTY. Only turn them on briefly for debugging purposes.
      # - log-level-overrides lets you override the log level if certain fields match. This is incredibly powerful
      #   for debugging certain parts of the system (e.g. only the account management, or only a certain visitor).
      #   This is an array of strings in the format:
      #      - "field=value -> level" to match a value exactly, e.g. "tag=manager -> trace"
      #      - "field -> level" to match any value, e.g. "time_taken_ms -> debug"
      #   Warning: Using log-level-overrides has a performance penalty. Only use it for temporary debugging.
      #
      # Check your permissions:
      #   If you are running ntfy with systemd, make sure this log file is owned by the
      #   ntfy user and group by running: chown ntfy.ntfy <filename>.
      #
      # Example (good for production):
      #   log-level: info
      #   log-format: json
      #   log-file: /var/log/ntfy.log
      #
      # Example level overrides (for debugging, only use temporarily):
      #   log-level-overrides:
      #      - "tag=manager -> trace"
      #      - "visitor_ip=1.2.3.4 -> debug"
      #      - "time_taken_ms -> debug"
      #
      # log-level: info
      # log-level-overrides:
      # log-format: text
      # log-file:

      okay i am working on setting these up from scratch now. i even spun up a whole new vps...

      i have nginx proxy manager for the reverse proxy. i have a docker network "proxiable" that i had NPM, molly and ntfy all in and was using the internal ip/port for NPM to proxy.

      should i not have them in the same docker network or does that not matter either way?

      for the mollysocker compose:
      for allowed endpoint should i put the external proxied domain "ntfy.mydomain.com?" or should i put the local ip since they are on the same VPS?

      MOLLY_HOST? what should i put for this?

        pinetree_raccoon I also use NPM as my reverse proxy. Don't forget to enable WebSocket support for Ntfy and Mollysocket btw.
        If they are all in the same network, that should be fine. For allowed endpoints I would use the domain as per instructions, I don't think it takes IPs.
        I don't know how your VPS is set up (I've never really used one) so I can't tell you for certain what needs to be set for MOLLY_HOST. What did you enter in NPM as the proxied IP? That's usually an IP in the CIDR of 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. I guess the same one should be used as MOLLY_HOST. You should also be able to retrieve a 172.16.0.0/12 IP from the Docker network specifically for MOLLY_HOST, although you should be careful as these IPs are allocated dynamically and can change on container rebuilds. The example on Github lists localhost IPs (127.0.0.1, 0.0.0.0) as possible options.

        i am completely dumbfounded.
        a couple questions, not sure if they matter.
        the dns provider for my domain is cloudflare. i have the A name root "mydomain.com" pointing at my public IP. i have "molly.mydomain.com" pointing at my root. should proxy status be "proxied" (orange cloud) or "DNS only" (grey cloud).

        there is a environment variable "MOLLY_WEBSERVER", is this necessary to be included, true, false?

        when i run the ping command i am still getting:

        sudo docker compose run mollysocket connection ping XXXXXXXXMY_UUID_FROM_MOLLYXXXXXXXX
        [2024-11-01T21:29:34Z INFO mollysocket::config] No config file supplied
        [2024-11-01T21:29:34Z INFO mollysocket::vapid] VAPID public key: "XXXXXXXVAPID_FROM_COMPOSE_FILEXXXXX"
        thread 'main' panicked at src/cli/connection.rs:125:28:
        called Result::unwrap() on an Err value: HTTP status client error (403 Forbidden) for url (https://ntfy.mydomain.com/upiSUOMu09yU63?up=1)

        when i click on "https://ntfy.mydomain.com/upiSUOMu09yU63?up=1)" from the above i get:
        https://imgur.com/a/mmzv5yU

        so it looks like it works? i dont know.

        i think this is the crux of the issue. although i dont know exactly what that means, haha

          pinetree_raccoon ohhh you're on CF, that makes things unpredictable for me.
          As a general point on DNS records:
          You should have one IP (since you are NPM'ing everything anyway). The A record for the second-level-domain can be whatever you want. You can set an A record for a subdomain or all subdomains with a * that will be the one for NPM.
          I am not quite familiar with the "proxied" or "DNS only" status, usually there shouldn't be proxies or it will fail to connect, so I guess DNS only.
          If you still get that 403 error, it obviously won't work. Check your general setup. Also test if ntfy is working at all, you can do that in the command line via curl. https://docs.ntfy.sh/publish/

          i think i got it!?!?!?!?

          i think it was the cloudflare dns settings. i had seperate CNAME's for each sub domain adn they were proxied with the "orange cloud."

          i removed them all and just have two now... * and root point directly at my IP. not proxied, DNS only (grey cloud).

          restarted all container and i got the unified push test notification!!

          thank you so much for your help, i appreciate it. i will check back later after i have fully tested it. thank you again!!

            pinetree_raccoon yep, always glad to help. Next time (for any such questions regarding hosting) don't forget to mention you're running Cloudflare. They're really not like the others with their DDoS and proxy stuff.