Support active install for the Cristal extension for Nextcloud

Hello all,

Since a few months, we are maintaining a Cristal extension for Nextcloud.
This extension allows editing page in a wiki UI (Cristal). Pages and attachments are saved in the user’s Nextcloud storage as structured pages and files.
The page content is aligned with the Markdown variant of Nextcloud, allowing pages to be editable outside the Cristal extension.

The issue I’d like to discuss here is that we have no mechanism to track if the extension is actually used. Having this value would help us:

  • Know if the extension is already used.
  • If future improvements and communication efforts have an impact on the number of users.

In summary, having these numbers would help us decide how much effort to put in this extension.

To the best of my knowledge, the Nextcloud store does not provide installation statistics. Therefore, we will have to introduce our own mechanism.

Note: technically, we can use the download statistics from the release page of the repository on GitHub since this is where NextCloud instances are downloading the extension archives. I’me showing a plot below to be exhaustive. But, this download count is a poor proxy for active installs since archives can be downloaded by scrappers, and don’t tell anything about how long since the extension was installed.

In essence, I propose to copy what we are doing for XWiki with the Active Install Application.
The deployed servers ping a central endpoint controlled by the top sponsoring company (namely, XWiki SAS) that would save minimal information:

  • Version of NextCloud
  • Version of the Cristal extension.

Technically, I won’t go into the detail, but the idea is to introduce a new URL under the https://cristal.xwiki.org/ domain.
The aggregated data would be stored in the same database as XWiki’s active install, with a new disambiguation field (e.g., source: “xwiki”|“cristal”).
I won’t go into the details of what we’ll store, but this goal is to not store personal information (e.g., IP addressed).

The main questions are:

  1. Do you agree with the general idea?
  2. In XWiki, sending data to active install is opt-out, do you agree to do the same?
  3. Do you agree with the proposed architecture?

Thanks!

cc @vmassol because you maintain active install, cc @rjakse if you find it interesting to also introduce the XWiki extension for Nextcloud in the scope.

+1

+1

More or less. I would suggest to not do the same mistake as the current XWiki active install client and introduce an XWiki protocol for those data when communicating with extensions.xwiki.org. And then do ElasticSearch communication only on extensions.xwiki.org side. It’s the right occasion to start working on fixing that IMO.

1 Like

Why not? The XWiki-Nextcloud extension could be a way to test the common code in two different extensions as well. If you need we can talk about this. Thanks for the ping.