• Jan. 1, 2024, 3:25 p.m.

    There's no roadmap for 4.0 because 4.0 itself is not planned anymore.

    Now that there's a plugin system, notifications will be connected to plugins eventually, and developers will be able to add new and replace existing notification methods with plugins.

    I have no idea when this is going to happen, because there is quite a lot of stuff that ought to happen in 2024. But I want to do it. Also, there is quite a lot other work planned for notifications.

  • Members 155 posts
    Jan. 1, 2024, 3:56 p.m.

    I just received an email notification for this post. Over 20 minutes after I'd read it as a reply on the forum.

    A big reason why I'd like some sort of more timely push based method.

    Thanks for the reply. I shall continue to monitor development, and do what I can to help.

  • Jan. 1, 2024, 3:58 p.m.

    This is odd. I've never had an notification e-mail from this forum arrive late to me.

  • Members 155 posts
    Jan. 1, 2024, 4:50 p.m.

    There are several limitations with email for me.

    One is that my outgoing server has email sending limits, so emails outbound from misago can end up being queued during busy spells. On the other side email delivery is by poll, and not push, so it can be up to 'poll interval' between email arriving.

    Also email tends to have widespread general use. .. so notifications can be missed, filtered, or incorrectly tagged as spam.

    I just don't like email for timely ordered notifications. By comparison I can define a specific channel for xmpp notifications, or specific notification channel in ntfy. If I have them active, notifications are immediate and, crucially, all ordered and filtered as only notifications through that channel, with no requirement for filter setup on different clients.

  • Members 155 posts
    Jan. 1, 2024, 5:06 p.m.

    ntfy has a lot of tooling and widespread project support, and can be consumed in many convenient ways (web client, android client, etc.). It's probably more complicated to impliment requiring a server, notification, user, and password setting.

    xmpp is less popular (for mainstream notifications), but a lot easier. An address is in the same form as an email address, and messages are just sent using sendxmpp instead of sendmail or whatever.

  • Jan. 1, 2024, 5:37 p.m.

    It looks like notification system should be changed so watching for event would not be an off/misago/misago+emails toggle.

    Instead, a notification channels should be introduced, with one being app, other being email. And configuration option for disabling email channel, and plugin support for adding extra channels to the application.

    Subscribing to something would mean enabling a notification channel.

  • Members 155 posts
    Jan. 1, 2024, 5:46 p.m.

    That would be an ideal way of being able to do it, if that can fit with what you have planned. Ideally the user would be able to choose which notifications to enable. Some people like more than one.

  • Nov. 26, 2024, 9:57 p.m.

    Another idea:

    Threads get watch/don't watch toggle.

    You setup it in your account's notifications settings to select if you want to receive email notifications (or any other channel notifications) for new replies in watched thread. You will always get on-forum notifications for watched threads.

    You can mute users you don't like. Muted users never give you notifications.

  • Members 155 posts
    Nov. 27, 2024, 6:48 p.m.

    That sounds ideal. (I may be moving away from xmpp, but the principle remains...it could be mastodon, nostr, discus, whatever. Subject to someone making a suitable plugin).

  • Nov. 27, 2024, 7:42 p.m.

    I guess I could also make difference between followed users and other users, so you could make Misago e-mail you if user you are following replies watched thread, but if its somebody else you only get standard notification on site.

  • Members 155 posts
    Nov. 27, 2024, 7:51 p.m.

    There's a danger it gets overly complex (on the backend, but also for users). I am a great believer in simple sane defaults.

    I think the user should be able to choose what to be notified for (I think I would default to notifications on, and the user can turn it off per thread, muted users not notified by default)
    Notifications to the site should be on by default
    External notification (by plugin) should be off by default...and should follow the site notifications if enabled.

    I probably want to set what I am notified on (on site), and then be able to externally notify (by plugin, and the same notifications) if I enable it. Turning off all notifications is okay...but under that scheme you don't really need ift if you have a clear all (on site) notifications.