Meeting took place 2026-05-06 17:55 to 19:13 UTC.
Next meeting is scheduled for 2026-05-19 17:00 to 18:00 UTC.
Wiki.js was chosen as a wiki/documentation solution, to replace wiki pages on Discourse. This choice will be reevaluated should a potentially better option emerge.
@lunarequest will host our Wiki.js instance.
| Item | USD/year | Note |
|---|---|---|
| Backblaze | <$1.00/year | Depends on usage, low cost right now. |
| bunny.net | ~$1.08/month | Depends on usage, low cost right now. |
| Namecheap | $42.98/year | Could consider switching TLDs, but this would break federation. |
| NearlyFreeSpeech | $3.65/year | Depends on usage, low cost right now. |
| ProtonMail | Replaced with Purelymail. | |
| Purelymail | $10/year | Depends on usage, low cost right now. |
| baddragon | ~$3/month | Freeloading off of a dedicated server. |
| moonlight | $24/month | On-demand pricing with rolling backups. |
| tsuki | $12/month | On-demand pricing with rolling backups. |
| snapshots | $2.31/month | Old emergency backups, potentially unneccessary. |
Discourse costs a significant amount of money to run, due to demanding to act as a Docker orchestrator, and to be run on the container host itself. This is why the tsuki server is provisioned separately just to run Discourse.
The moonlight server, running Forgejo, tuwunel, LiveKit, Cinny, and Out Of Your Element, tends to hover around 10% CPU usage and 40-50% RAM usage, with 33% swap used at the time of checking. It's provisioned with 2 vCPUs and 4 GB of RAM.
@exodrifter had recently made savings of about 74 USD per year by switching from ProtonMail to PurelyMail as our email provider.
We had briefly tested Wiki.js (hosted by @lunarequest) and MediaWiki (hosted by @exodrifter) as potential replacements for Discourse wiki pages. MediaWiki, while a mature and competent option, was deemed to have too tall of a learning curve, not convenient enough, and too cumbersome to maintain (e.g. requiring edits to a php source file in order to change site configuration, user groups or group memberships). It was decided that Wiki.js, despite its shortcomings (no user links or mentions, configuration limitations, development with a bus factor of 1), is our best choice for the time being.
Several other options had been considered, and rejected for various reasons, e.g. user-friendliness, licensing, SSO support, hosting complexity, and LLM involvement, among others.
Notes:
@outfrost had been assigned to draft a threat model for t/suki, but was unable to prepare it for this meeting. This topic was postponed until the next meeting.
We plan to discuss these topics at future meetings.