Hello from the Etherpad maintainers — open to collaboration?

[JohnMcLear]

Hi Jacob,

I'm John, one of the Etherpad maintainers (https://github.com/ether/etherpad). I came across this plugin while doing a survey of where Etherpad shows up across self-hosted platforms (tracking issue: ether/etherpad#7529) and wanted to introduce myself.

A few things I really like about the architectural choices here:

• Single-purpose — no Ethercalc bundling, unlike Ownpad
• Built against the modern Nextcloud viewer APIs rather than the deprecated owncloud-era patterns most prior bridges used
• .pad-as-file model + sharing/trash/restore lifecycle is exactly the shape we'd want
• Clear-eyed about API-key auth and the Ownpad coexistence question

From where we sit, the Nextcloud ↔ Etherpad picture today is:

• Ownpad is functional but architecturally stuck — code commits have basically stopped, recent activity is mostly Transifex translation bots
• Nextcloud Talk closed the door on a bundled Etherpad integration in 2020 (nextcloud/spreed#3174)
• Nextcloud Text covers the simple markdown-with-collab case but doesn't have author colours, plugins, public guest pads, or custom skins — all things Etherpad is genuinely good at.. It also doesn't have CLI/MCP/Terminal Editor/Mobile Apps.. Again, things users want...

That makes your plugin the most viable path for a real "Etherpad in Nextcloud" today.

Some open-ended offers, no pressure on any of them:

1. Adoption / co-maintenance under ether/ — if you'd like the project to live under the Etherpad organisation while you stay as primary maintainer, we can do that with full attribution. Or we keep it under your name and just cross-link from etherpad.org.
2. Help getting it on the Nextcloud App Store — we can contribute a CI workflow, an icon (from upstream's src/static/img/brand.svg), and co-sign the submission if useful.
3. Etherpad-side improvements — if there's anything in the Etherpad API / auth / embed surface that's painful for this plugin, file it on ether/etherpad and we'll prioritise it.
4. License — noticed there's no LICENSE file yet; that's likely a prerequisite for App Store submission and for any org adoption. Apache-2.0 would match upstream Etherpad if you don't have a preference.

What's your rough roadmap, and where (if anywhere) could we be useful? Equally happy if the answer is "thanks, I've got it" — just wanted to put the offer on the table so we're not duplicating work.

[Jaggob]

Hi John,

Thanks for the kind note and the survey work – much appreciated, and good to hear the architectural shape resonates with where you sit.

Roadmap All features I personally cared about have landed; no big new feature work planned. Last missing feature was ownpad migration, which was added yesterday. The focus shifts to hardening the existing surface and shipping a stable 1.1.0. Anything coming after the release will most likely be NC-side compatibility work (new NC majors, deprecations, NC file type filter) rather than big new features. The issues with the "1.1.0 release" milestone capture what's left: CI, app-store submission, translations, and a contribution/security policy. https://github.com/Jaggob/etherpad-integration-for-nextcloud/milestone/5

One thing where outside eyes would genuinely help is code review. This is my first larger software project, and so far the codebase has only been reviewed by Copilot and Claude Code. Having actual humans look at the architecture and the trickier flows would be valuable. If anyone on your side has bandwidth for that, even partial passes are welcome.

On your four offers:

• Adoption under ether/: definitely interested – sounds like a good long-term home for the project. My proposal would be to first wrap up the release-relevant items above (broader testing, the translation question, the one known cosmetic bug), and then do the transfer once 1.1.0 is final. So as a last step before App Store Push? That said, fully open to other timing if there's a reason to do it sooner from your side – let me know what you think.
• App Store help: yes please. CI workflow, co-sign, and the upstream icon would all be useful.
• Etherpad-side improvements: I've kept a list of the concrete pain points the plugin work surfaced: Track Etherpad-side improvements to upstream at ether/etherpad #79. Nothing urgent though – most entries are pretty niche or could be handled by an additional Etherpad-side plugin. The bigger remaining improvements on my list would actually need NC-side changes rather than Etherpad-side ones, and even those aren't acute. honestly, I wouldn't have given this any thought without your asking.
• License: I already added AGPL-3.0 in the SPDX headers to have it matching to the NC license. Just added the matching LICENSE in the repo root to make that clear. But I'm open to a different choice.

One question back, also because of adoption to ether/: for translations of this plugin, do you / ether/etherpad have a preference between Transifex (NC ecosystem default) and translatewiki.net (where Etherpad already is)? The platform decision now is in [#77].

Thanks again, will keep you in the loop as 1.1.0 progresses.

[JohnMcLear]

Hi Jacob,

TLDR;

1. Shift to ether/ - Perfect.
2. App store help: Yea, all good, I'll shoot them over either later today or tomorrow.
3. Etherpad features: Create issues on ether/etherpad - I commented on each :)
4. License - AGPL3 is totally fine.
5. Translate - Prefer Translatewiki but either is fine.

Longer winded;

Sounds good — your sequencing makes sense. Locking in 1.1.0 first and transferring to ether/ as the last step before App Store submission keeps the release history and CI cleanly yours, and means the org takes on something stable rather than mid-stream.

1. Code review. Happy to organise this. I'll do an architectural pass on the trickier surfaces (NC viewer integration, the .pad lifecycle, session/cookie embed flow) over the next week or two and file findings as individual issues against the 1.1.0 milestone, rather than one wall-of-text PR. If there are specific files or flows you're least confident about, point me at them and I'll start there. I'd also like to bring in a second pair of eyes from the Etherpad side specifically for the embed/auth path — that's where the cross-site cookie nasties live and a second opinion helps.

2. App Store: CI + icon + co-sign. Confirmed on all three. The icon at src/static/img/brand.svg upstream is yours to use; I'll prep a NC-friendly PNG bundle in the sizes apps.nextcloud.com expects and PR it once 1.1.0 RC is cut. For CI I'd model on the workflow NC uses for first-party apps, happy to draft against your existing GH Actions setup whenever you're ready.

3. Etherpad-side pain points (Track Etherpad-side improvements to upstream at ether/etherpad #79). Thanks for keeping that list, I commented on it.

Please mirror these as issues on ether/etherpad and link back here so we can watch progress.

4. License. AGPL-3.0 is fine, matching NC is the right call for an NC-side plugin. ether/ already holds projects under several licenses (core is Apache-2.0, some plugins MIT or AGPL), so adoption doesn't force any relicensing.

5. Transifex vs translatewiki.net. Honest take: if the destination is ether/ post-1.1.0, translatewiki.net is the cleaner long-term home. Etherpad's existing 115-locale community there is the closest match to who'll actually use this plugin — they already know our string format and workflow, and would pick up the NC plugin strings as part of their existing rotation. Transifex would mean asking NC translators to onboard a new project from scratch, and the overlap between NC-translator-active and NC-Etherpad-user is smaller than you'd expect. That said, translate is easy to drive with AI now so the platform is becoming less consequential.

The counter-argument is discovery: if you want apps.nextcloud.com submission tooling and NC translator workflows to pick this up automatically, Transifex wins on that axis. Net: I'd lean translatewiki post-transfer, but it's a soft preference, not worth blocking on.

The de → 100% sub-task in #77 is platform-agnostic, so no need to wait on the decision there.

Ownpad migration. Nice work landing that — probably the single biggest practical blocker for anyone moving over. Worth highlighting in the 1.1.0 release notes.

I'll watch the 1.1.0 milestone and pick up the code-review thread this week.

Cheers,
John

[Jaggob]

Hi John,

Thanks again for the tests and the images! much appreciated!

Quick update from my side: I've reworked the source strings for translations, so once we've moved we can hook up translatewiki for proper community translations. I've also added a batch of tests and done some refactoring along the way. So from my side we're good to go ahead with the move to the Ether org.
Two developer and DevOps friends are giving the plugin a once-over at the moment, but if things come up there, we can also fold them in later.

A few things around the move:

• Transfer: if I understand the GitHub docs correctly, I have to initiate the transfer myself, which means I need permission to create a repository in the Ether org. Could you grant me that or is there another way?
• README & Third Party: the README had a small disclaimer that the project isn't affiliated with Etherpad – that no longer fits once it's in the org, so I'll dropp it. I will also remove the THIRD_PARTY_NOTICES.md file I'd added when first creating the repo (it stated this isn't an official Etherpad product), since that no longer applies either. The Etherpad icon assets stay under Apache-2.0, just referenced via the license file directly.
• Security policy: there's no SECURITY.md yet. To make sure vulnerability reports don't land only with me, it probably makes most sense to fold this into Etherpad's existing process – i.e. point reports to contact@etherpad.org like the other Etherpad repos do, and enable GitHub's private vulnerability reporting on the repo. Does that work, or is there a separate channel you'd prefer for the plugin?
• Credit: I've added you as an author in the app metadata. Beyond that, like the other Etherpad repos, I wouldn't add a separate AUTHORS file – the GitHub contribution graph covers it once you're committing through the repo. Is that fine with you, or do you have another suggestion for the credits?

I've opened a PR with the README, third-party and SECURITY.md changes, you can take a look here: #139

Best,
Jacob

[JohnMcLear]

Transfer: if I understand the GitHub docs correctly, I have to initiate the transfer myself, which means I need permission to create a repository in the Ether org. Could you grant me that or is there another way? <-- correct, invite sent.

README & Third Party: the README had a small disclaimer that the project isn't affiliated with Etherpad – that no longer fits once it's in the org, so I'll dropp it. I will also remove the THIRD_PARTY_NOTICES.md file I'd added when first creating the repo (it stated this isn't an official Etherpad product), since that no longer applies either. The Etherpad icon assets stay under Apache-2.0, just referenced via the license file directly. <-- ack

Security policy: there's no SECURITY.md yet. To make sure vulnerability reports don't land only with me, it probably makes most sense to fold this into Etherpad's existing process – i.e. point reports to contact@etherpad.org like the other Etherpad repos do, and enable GitHub's private vulnerability reporting on the repo. Does that work, or is there a separate channel you'd prefer for the plugin? <-- that works

Credit: I've added you as an author in the app metadata. Beyond that, like the other Etherpad repos, I wouldn't add a separate AUTHORS file – the GitHub contribution graph covers it once you're committing through the repo. Is that fine with you, or do you have another suggestion for the credits? <-- fine with me

[Jaggob]

great! invite accepted, but can't transfer yet, it says "insufficient permission", guess i need permission to create a repo?

[JohnMcLear]

Should be sorted now, indeed the perm was missing.

[Jaggob]

Perfect, transfer done 🎉

The transfer removed my admin access to this repo. I still need to activate GitHub private vulnerability reporting and branch protection on main. Could you grant me admin here, or flip those on?

A few Dependabot PRs and security warnings also came up here and in the last days. I'm a bit busy at the moment, so I'll look at it in two weeks. Feel free to change stuff in the meantime if you want to and have the time.

A possible next step would be translations #98 , if anyone on the Ether team fancies picking that up, very welcome. otherwise I'll dig into it myself next month.

[JohnMcLear]

Yep I'll get to it.

[JohnMcLear]

Perfect, transfer done 🎉

The transfer removed my admin access to this repo. I still need to activate GitHub private vulnerability reporting and branch protection on main. Could you grant me admin here, or flip those on?

A few Dependabot PRs and security warnings also came up here and in the last days. I'm a bit busy at the moment, so I'll look at it in two weeks. Feel free to change stuff in the meantime if you want to and have the time.

A possible next step would be translations #98 , if anyone on the Ether team fancies picking that up, very welcome. otherwise I'll dig into it myself next month.

Role: Admin set. Let me know if it doesn't work :)