tetricky

Misago-image updated to 0.39.4 misago-image, see the README.md for configuration notes.

Pre-built images are available through both ghcr.io and docker.io.

I'm not a fan of AI, both from a resource perspective, but also for the same reason as @rafalp. I very much like misago because it's not like discourse.

Clean, reasonably resource friendly, good service stack, easy to manage, self contained, not overly dependent on other services (like email or AI). I've been running a forum since the last century, and clean and simple (relatively) pays off in the long term.

The extensive work being done towards a functional core, with the option of plugins, will give utility to misago for years to come. Personally I'd like to ultimately integrate xmpp to replace email and provide an independent chat function, possibly with auth and xmpp based posting.... But this is personal unachievable dream stuff, and definitely should be plugin only.

Perhaps the only extra thing I'd like to see in core is light/dark theme support.

Full release now as per 0.39.3.

Misago-image updated to 0.39.3 misago-image, see the README.md for configuration notes.

Pre-built images are available through both ghcr.io and docker.io.

The thread Install misago in a podman pod under linux shows how to split the services out and install separately, for custom requirements.

It includes a section on how to apply a custom configuration to the nginx component. You would have to research how to configure that for localhost (which I believe is possible).

You can use a similar procedure for docker, as for the podman example. Just don't put the containers in pods.

I am currently maintaining a misago-image build for those who want to install in a custom environment. The thread Install misago in a podman pod under linux gives an installation procedure for this installation under podman, but can be directly translated to docker...but you may have to publish container ports and consider the container networking implications of your setup.

Also in collaboration with @rafalp and @jamesdelliott from the authelia project we produced instructions for integrating misago with authelia as an authentication provider.

Apologies for the delay, busy times at tricky towers means I was unable to update to this release earlier. Full release now as per 0.39.2.

Misago-image updated to 0.39.2 misago-image, see the README.md for configuration notes.

Pre-built images are available through both ghcr.io and docker.io.

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.

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).

All modern browsers support caching of the client side scripts and data objects. Whether by cookie or web storage/IndexedDB. An application (dynamic) like misago utilises that to use client side code to respond quickly to user interaction. In contrast a static site (for example as generated by hugo) has a 1:1 relationship between link and file and no requirement to interrogate data to build and serve a page.

If client side script is residual development code, and not complete, then you well get that (incorrect) behaviour until the cached storage is replaced with the correct version in the browser.

So not a surprise if you understand what is happening, on both your client and the server, to interrogate the data with client side script, produce the data from the server database, and build the page in your browser to display to you.

Shift+reload can sometimes adequately refresh that stored data on browsers.

The problem with image push to ghcr.io is now resolved, and the image is testing as functioning. Full release now as per 0.39.1.

Misago-image updated to 0.39.1 misago-image, see the README.md for configuration notes.

Pre-built images are available through both ghcr.io and docker.io.

Misago-image updated to v0.39.1 misago-image, see the README.md for configuration notes.

Pre-built images are available through docker.io.

Github actions update as yet unresolved for ghcr.io. So no image there for this release.

This release has been pushed, but not tested.

I like tailwind as a choice. I use the excellent blowfish a hugo theme. That uses Tailwind (Tailwind CSS 3.0).

It makes it more likely that I would be able to assimilate enough accumulated knowledge of it, to be able to do something useful.

There is an alternative, and the one that I use.

I have misago behind caddy2 backed by authelia authentication. Caddy is configured to allow anyone to view the site. Misago is configured with no user enrol allowed, but with Oauth log in enabled. Everything (lldap, authelia, misago) is backed by a single postgres container based database server, with individual databases and database users within the instance.

I have a public contact form* where prospective users (or existing users with technical support queries where they cannot access the forum for whatever reason) can email my forum admin account with the contact form request.

Then if I want to grant them membership of the forum I add their username and email address for authentication details in my ldap backend and add them to the 'misago' group (which I create, and is the group that valid authentication for the forum is checked). I then email them details of how to log in to the authentication frontend, and set their password (and register an authenticator as I require 2FA).

When they register with the authentication frontend, they can then "sign in" to misago using the authentication provided externally, and misago will create a membership based on their provided username and email address.

This also allows for the possibility that you can add or remove people to the 'misago' group in the lldap backend, and also revoke all current logins (clearing the redis cache in the authelia container setup) independent of misago.

Sounds complicated, but it's not when you get it set up. Such is the nature of levels of access and authentication for secure web services!

* I use nocodb to self host my contact form (also utilising the same postgres instance). It's relatively simple and lightweight to host using a container (I use podman) setup that you can also use for misago itself (and authelia and caddy). You might wish to refer to install-misago-in-a-podman-pod-under-linux/ for an example of how to install a customised container environment. Any self hosted or external provider contact form will do though.

I'm travelling for a few days, but generally would be happy to add some devil in the detail if anyone wants to look at this as a possible solution.

The recent changes to notifications handling has made the management of unread threads much easier for the user. Perfectly reasonable to move things on to a sensible schedule for you. I still think there's a value to this.

2023 has been a brilliant year, misago wise. I moved my community to misago in the middle of the year, once oath2 was working. It's a big step forward from where we were. Misago works for us, as is...but the development, and roadmap will definitely make things even better. I see misago as having a definite role as an easy and flexible full function modest resource modern forum.

My thanks to you for what has been a very significant level of work on the codebase...with more to come. Along with thanks, I will aim to support with any bits that I can do (testing, feedback, third party container support, primarily).

Wishing a good 2024 to all.

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.

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.

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.