Add ejabberd

[TabTwo]

Add ejabberd to the catalog

Packaging of the ejabberd XMPP server as a YunoHost app: https://github.com/TabTwo/ejabberd_ynh

• Category: communication (subtag chat)
• Auth: YunoHost LDAP (PLAIN over TLS, like the other XMPP apps)
• Dependency: coturn (STUN/TURN for A/V calls), auto-installed
• Ships the XMPP Compliance Suite fixes, self-configuring DNS (a custom_dns_rules hook that publishes the _xmpp*/_xmpps* SRV records incl. XEP-0368 direct-TLS), and XEP-0485 via ejabberd-contrib.

Validation

Tested end-to-end on two fresh YunoHost 13 servers on two separate domains (real DNS + Let's Encrypt):

• 100% on the XMPP Compliance Suite on both — server A, server B — from a clean install, no manual fixups.
• Working s2s federation between the two instances (message delivered A→B over TLS).

⚠️ Platform note — please read

This app currently requires YunoHost 13 / Debian 13 (Trixie) — the manifest floor is yunohost >= 13.0. It uses ejabberd 24.12 features (mod_muc_occupantid, mod_stun_disco, mod_http_upload custom CORS headers) that only exist in the ejabberd shipped by Trixie; Bookworm's older ejabberd would fail to start, so Bookworm is deliberately unsupported.

I'm aware this means the CI, on a Bookworm/stable baseline, will likely mark it notworking for now. I'm flagging it openly rather than hiding it — happy to set state to whatever you prefer (inprogress?), hold the merge until Trixie becomes the CI baseline, or point CI at the Trixie/unstable target if that's available. Guidance welcome.

Also glad to transfer the repo to the YunoHost-Apps org per the contributor note.

[ericgaspar]

!invite @TabTwo

[yunohost-bot]

@TabTwo, you have just been invited to the YunoHost-Apps organization.
We suggest that you transfer your repository in the org so that you can take advantage of the automated CI tests and other packagers' help:

1. check your notifications and accept the invitation.
2. transfer your repository to the YunoHost-Apps organization.
3. open a PR from the testing branch to the main branch of your repository
4. add your commits and open a pull request.
5. trigger the CI with !testme in a comment in that PR.

Do not forget to update your repository URL in the catalog.

You can find more information on packaging in our documentation

[Thovi98]

Thanks for your proposal and the work behind this.

I'd wait for the Trixie migration to merge this app as it won't work on Bookworm.

After a quick look on your repo I can see that a LLM has been used to help you. It's okay, but there a leftovers that should be cleaned up before merging (/doc and /docs folders; is the myproject.toml file needed (if yes it should be located in the /conf dir),…)

[TabTwo]

Gentle bump — with a status update rather than just a ping.

Since opening this I've run package_check against a Trixie/unstable base image
(DIST=trixie, YNH_BRANCH=unstable), and the app now passes all four tests:

Package linter:   OK
Install (nourl):  OK
Backup/restore:   OK
Upgrade:          OK

Two fixes came out of that run and are already pushed:

• coturn is now a soft dependency. Previously the install died if yunohost app install coturn
  failed — which is exactly what happens in a CI container with no outbound git. It now warns and
  continues; the app simply doesn't advertise STUN/TURN (XEP-0215) until coturn is added later.
  A short reachability probe keeps a black-holed network from stalling the install on git's TCP
  retries.
• A restore-time permission bug. ynh_restore hands paths back as root:root with no traversal
  bits, which left ejabberd unable to read its own config or enter its mnesia spool, so restore
  failed with status=6/NOTCONFIGURED. The restore script now re-asserts the modes the Debian
  package ships.

The only linter criticals left are This app is not in YunoHost's application catalog and
The application is not flagged as working in YunoHost's apps catalog — i.e. exactly what merging
this PR resolves.

The Trixie-only question from the description is still the open one, and I'm happy with whichever
answer suits you: merge with state set to inprogress/notworking until Trixie is the CI
baseline, hold the PR until then, or point CI at a Trixie/unstable target if that's possible. The
offer to transfer the repo to the YunoHost-Apps org also still stands.

No rush — just didn't want it to go stale.

[TabTwo]

Thanks @Thovi98 — all fair, and thanks @ericgaspar for the invite. Everything is done:

Repository transferred to the org: https://github.com/YunoHost-Apps/ejabberd_ynh, with a testing branch in place. The catalog entry now points there.

added_date removed per your suggestion.

Leftovers cleaned up (YunoHost-Apps/ejabberd_ynh@14f7eec) — you were right, this repo root doubles as my project workspace and some of it rode along:

• docs/ — a bake-off decision doc plus the design spec and implementation plan. Moved out to the project that tracks my XMPP work; none of it belongs in a packaged app.
• myproject.toml — metadata for my own local repo catalogue, meaningless to YunoHost. I did not move it to conf/: that directory is for config templates, and the honest answer is that the file shouldn't be in the app at all.
• README.md — it was a three-line internal stub, typo included. Replaced with a real one in the format readme_generator emits; your tooling can regenerate it now that the repo is in the org.

What's left is exactly the app: manifest.toml, config_panel.toml, tests.toml, LICENSE, README.md, conf/, scripts/, hooks/, doc/.

One thing I kept deliberately: doc/ (ADMIN.md, DESCRIPTION.md, PRE_INSTALL.md) is the standard packaging-v2 documentation directory, not a leftover — I read your comment as flagging the docs//doc/ confusion, which is now gone since only doc/ remains. Happy to be corrected if you meant something else in there.

And yes — on the LLM: I use one as a pair-programming partner, and the leftovers were exactly the kind of thing that produces. Every line has been reviewed and the app is validated on real hardware; but you caught workspace clutter I'd stopped seeing, which is the point of review. Appreciated.

On merge timing: fully agree, no rush. The app needs YunoHost 13/Trixie (the config uses ejabberd 24.12 features Bookworm's package doesn't have, so it would fail to start there — Bookworm is deliberately unsupported, not accidentally broken). Merging when the Trixie migration lands makes sense to me. In the meantime, package_check against a DIST=trixie YNH_BRANCH=unstable base image passes all four tests:

Package linter:   OK
Install (nourl):  OK
Backup/restore:   OK
Upgrade:          OK

Ready for !testme whenever you want CI on it.

[TabTwo]

Belated disclosure, which should have been here from the start.

This packaging work and my comments in this thread were produced with AI assistance — I use Claude Code for investigation and for drafting. The package itself, the package_check runs and the CI analysis came out of that; I run the tests, review the results and push everything myself, and I'm accountable for all of it.

I'm mentioning it because @Thovi98's review points and @ericgaspar's invitation to the org were extended to me as a person, and you were both entitled to know how the work was produced before that happened, not after.

Future contributions from me will carry this note where AI assistance was material. If the YunoHost-Apps org would prefer a different level of disclosure, or none at all, say so and I'll follow that.