Version checker and optional analytics #227

New issue

Open

opened 2022-01-30 19:37:07 +00:00 by timokoesters · 4 comments

timokoesters commented

2022-01-30 19:37:07 +00:00

(Migrated from gitlab.com)

When we send those regular request, we could send analytics as well. This could include things like:

local user count
number of rooms
median, average and max members of rooms
conduit uptime
general server information, like OS, machine type (arm/x86), total ram, number of cpus

My idea is that these analytics can be shared to show that conduit is a viable server even on cheap hardware.

What are your thoughts?

When we implement new features, fix bugs or security problems, we want users to quickly update. It should be relatively easy to do with a background task that sends a request to some central server every few hours. When we send those regular request, we could send analytics as well. This could include things like: - local user count - number of rooms - median, average and max members of rooms - conduit uptime - general server information, like OS, machine type (arm/x86), total ram, number of cpus My idea is that these analytics can be shared to show that conduit is a viable server even on cheap hardware. What are your thoughts?

akselmo commented

2022-02-03 10:15:13 +00:00

(Migrated from gitlab.com)

I don't think it should ever be automated. Give users commands that let them to do the tasks.

For example:

In admin channel:

 @conduit checkupdate  

This would return the newest release, but also remind the user that its suggested to use the newest version your distribution provides!

  @conduit sendanalytics   

Sends analytics of your system whenever this command is run.
Alternatively it could just give you a code block you can copy paste somewhere and it has relevant information   . It could be even it's own command to get this codeblock, and it could help with creating somewhat standardized bug reports: Every bug report has the system information laid out similarly.

These commands could be shown in the first message of the admin channel.

When users have to actually type the commands, they make a conscious choice to send the data or update the system, and there will be no "surprise updates."

While I would be personally fine with the automated services, I believe that automation in both cases just annoy most people and even may cause problems with some distributions, since some distributions wait longer time before jumping to the newest version of software.

I don't think it should ever be automated. Give users commands that let them to do the tasks. **For example:** In admin channel: ` @conduit checkupdate  ` This would return the newest release, but *also remind the user that its suggested to use the newest version your distribution provides!* `  @conduit sendanalytics   ` Sends analytics of your system whenever this command is run. Alternatively it could just give you a code block you can copy paste somewhere and it has relevant information   . It could be even it's own command to get this codeblock, and it could help with creating somewhat standardized bug reports: Every bug report has the system information laid out similarly. These commands could be shown in the first message of the admin channel. When users have to actually type the commands, they make a conscious choice to send the data or update the system, and there will be no "surprise updates." While I would be personally fine with the automated services, I believe that automation in both cases just annoy most people and even may cause problems with some distributions, since some distributions wait longer time before jumping to the newest version of software.

timokoesters commented

2022-02-03 10:23:43 +00:00

(Migrated from gitlab.com)

and there will be no "surprise updates."

I don't understand what's bad about being surprised by an update. If there's a security flaw, we want users to quickly update, so I want to push an announcement.

@conduit sendanalytics

I don't want to use these for bug reports. My idea was to get very rough statistics on Conduit instances so I can share them on conduit.rs (compare it to synapse phone home stats: https://www.matrix.org/blog/2018/04/11/synapse-0-27-3-released )

> and there will be no "surprise updates." I don't understand what's bad about being surprised by an update. If there's a security flaw, we want users to quickly update, so I want to push an announcement. > @conduit sendanalytics I don't want to use these for bug reports. My idea was to get very rough statistics on Conduit instances so I can share them on conduit.rs (compare it to synapse phone home stats: https://www.matrix.org/blog/2018/04/11/synapse-0-27-3-released )

jfowl commented

2022-02-20 09:49:35 +00:00

(Migrated from gitlab.com)

mentioned in issue #103

nodiscc commented

2022-12-09 18:37:29 +00:00

(Migrated from gitlab.com)

This should be opt-in if it ever gets implemented, for obvious security/privacy reasons. I suggest 2 separate settings in the configuration file with the following defaults:

# periodically check for updates from https://conduit.rs
# if an update is available a notification message will be sent to the server's admin room
check_updates = false

# periodically send server statistics to https://conduit.rs
# enabling this will send [DETAIL EVERYTHING BEING SET HERE] to conduit developers
send_analytics = false

This should be opt-in if it ever gets implemented, for obvious security/privacy reasons. I suggest 2 separate settings in the configuration file with the following defaults: ```bash # periodically check for updates from https://conduit.rs # if an update is available a notification message will be sent to the server's admin room check_updates = false # periodically send server statistics to https://conduit.rs # enabling this will send [DETAIL EVERYTHING BEING SET HERE] to conduit developers send_analytics = false ```