Add ntfy.sh support

[gorkem-bwl]

Ntfy.sh is a library that helps send push notifications to your phone or desktop via scripts from any computer, and/or using a REST API.

When integrated with BlueWave Uptime, it can send incidents to a smartphone running the ntfy application.

One advantage is that it's faster than email notifications.

[aryanp-86]

Hello @gorkem-bwl
Seems interesting, this issue would be fun to work on. I would like to work on this issue.

[gorkem-bwl]

Hello @gorkem-bwl Seems interesting, this issue would be fun to work on. I would like to work on this issue.

That’s a great addition indeed, and definitely worth addressing. Could you draft an implementation plan for this? You might also want to take a look at how Uptime Kuma handles it for some inspiration.

[aryanp-86]

Hey, @gorkem-bwl
Here is the Implementation Plan for ntfy Integration

I have reviewed the email notification provider in Bluewave Uptime and the ntfy notification integration in Uptime Kuma to explore how we can integrate ntfy notifications into Bluewave Uptime. Here's a summary of my findings and proposed approach:

1. Understanding Uptime Kuma’s Notification Architecture

   • Uptime Kuma uses an abstract class called NotificationProvider.
   • Any new notification service must extend this class and implement key methods like title(), send(), and message(). This design provides a modular approach, allowing different providers to be plugged in easily.

2. How Bluewave Uptime Manages Notifications

   • In Bluewave Uptime, users configure email notifications while creating a monitor. A checkbox is provided to enable or disable sending emails to the default user email configured at login.

3. Proposal for ntfy Integration

   • We can enhance the existing monitor creation form by adding an option for ntfy notifications.
   • Users will provide:
     • Topic
     • Friendly Name (optional display name for the service)
     • Server URL (default: https://ntfy.sh), etc.

4. Route Handling for ntfy notifications

   • On form submission, we will to manage the ntfy notification logic via a route handler at the server side. This handler will send messages using the provided configuration.
   • This ensures that notifications are sent seamlessly whenever the monitor status changes.

---

This approach aligns with the existing architecture of Bluewave Uptime while drawing inspiration from Uptime Kuma's modularity. Let me know if further refinements are needed!

[gorkem-bwl]

Thanks for pulling things together. However, please ensure that all the details are fully outlined in the implementation document. Using AI for the documentation is good, but this task requires a more committed approach. For instance, I don't see any mention of the UI options for ntfy.sh. What are other user inputs? (eg how do you handle authentication?). How do you plan to develop back-end related tasks? You can also remove "How Bluewave Uptime Manages Notifications" as it's not related to this task.

Let me know your thoughts!

[aryanp-86]

Thanks for the feedback. I will rewrite the draft in a more detailed manner by tomorrow.

[gorkem-bwl]

Thank you.

[gorkem-bwl]

@aryanp-86 just wanted to check back here to see if there is any progress on your end. Thanks!

[aryanp-86]

Still working on it. Will update you soon.

[aryanp-86]

Hey @gorkem-bwl
Here is the detailed implementation draft.

1. User Interface

• On the UI side, we will show a checkbox of "Notify via ntfy.sh" in the incidents section which on enabling will request users to enter required fields like friendly name, topic, server url, priority and authentication mode.

• Taking inspiration from Uptime Kuma's design, I have also added three auth modes. By default it will be set to no auth( which is the easiest way for the user to test ntfy.sh). The other options being username-password and access token for secured ntfy.sh servers.

• Users can test the ntfy.sh connection using the test button which runs a axios request using the config provided. On saving, the ntfy config is added to the monitor state's notification array.

2. Notification model:

• The notification model needs to be updated to support the ntfy options.

const NotificationSchema = mongoose.Schema(
	{
		monitorId: {
			type: mongoose.Schema.Types.ObjectId,
			ref: "Monitor",
			immutable: true,
		},
		type: {
			type: String,
			enum: ["email", "sms", "ntfy"],
		},
		ntfyConfig: {
			type: Object,
		},
		address: {
			type: String,
		},
		phone: {
			type: String,
		},
	},
	{
		timestamps: true,
	}
);
export default mongoose.model("Notification", NotificationSchema);

3. Backend

• At the backend side, we need to update the handleNotification method in networkService.js to incorporate Ntfy.sh message sending.

for (const notification of notifications) {
    if (notification.type === "email") {
        await this.emailService.buildAndSendEmail(
            template,
            { monitorName: monitor.name, monitorUrl: monitor.url },
            notification.address,
            `Monitor ${monitor.name} is ${status}`
        );
    } else if (notification.type === "ntfy") {
        console.log("ntfy reached");
        await this.sendNtfyNotification(monitor, isAlive);
    }
}

• We also need to add a custom sendNtfyNotification method that will send the incident message based upon monitor status.

async sendNtfyNotification(monitor, isAlive) {
    try {
        const status = isAlive ? "up" : "down";
        const message = `Monitor ${monitor.name} is ${status}`;

        // Send the Ntfy notification using the configuration from the notification object
        const ntfyConfig = monitor.notifications.find((n) => n.type === "ntfy")?.ntfyConfig;
        console.log(ntfyConfig)
        await this.axios.post(`${ntfyConfig.serverUrl}/${ntfyConfig.topic}`, {
            title: `Monitor ${status}`,
            message: message,
            priority: isAlive ? 5 : 1,
        });
    } catch (error) {
        this.logger.error(`Failed to send Ntfy notification: ${error.message}`, {
            method: "sendNtfyNotification",
            service: this.SERVICE_NAME,
            monitorId: monitor._id,
        });
    }
}

Let me know if further refinements are needed!

[gorkem-bwl]

Looks good. Thanks for the detailed implementation plan. Let's move forward with this!

[ajhollid]

@aryanp-86 I'm working on cleaning up the notification process and network service at the moment, so if you could start from the front end that would be great!

We can work out the back end implementation once the refactoring is done 👍

[aryanp-86]

Ok great. Actually, I am almost ready with the frontend code. Would you please ping me once the refactoring is done?

[ajhollid]

Ok great. Actually, I am almost ready with the frontend code. Would you please ping me once the refactoring is done?

Hi @aryanp-86 ,

Backend refactoring is mostly done, you should find it much easier to work with now hopefully.

There's a couple open PRs that will make some changes, but they're mostly minor and shouldn't cause conflict with what you're working on.

They'll likely be merged within 24 hours anyways.

[aryanp-86]

Ok great 👍

[gorkem-bwl]

Just wanted to check back here guys :)

[aryanp-86]

Sorry for the delay. The backend code has been refactored in recent pr's. I will modify my code to the changes in a day or two.

[gorkem-bwl]

Thanks for the update! @aryanp-86

[aryanp-86]

Hello @gorkem-bwl @ajhollid
I have raised a PR with the changes. Will you please review it once. Thanks.

[ajhollid]

Hello @gorkem-bwl @ajhollid
I have raised a PR with the changes. Will you please review it once. Thanks.

Great, thank you for your contribution. We will review as soon as possible!