I’m really interested in experimenting with error reporting in my plugins so I can more easily understand what’s happening for users. Something like Sentry.io
I know any telemetry code like this is not allowed for plugins listed in the plugin repository, but I’m wondering whether I could implement it only in Beta versions that must be installed through BRAT. These versions would include a clear onboarding dialog that lets users know this.
I could then set up a github action to deploy the releases and strip any telemetry code for standard plugin-installable releases - meaning Beta users could help capture bugs to improve the plugin, while standard users won’t have any of that.
Is this approach done by any other plugins?
And is it allowed?
I didn’t receive any responses on here so I posted the same question in the Discord forum. I’ll copy and paste the responses from Obsidian reps below for anyone else who has a similar question.
joethei! 28/12/2024
The plugin you get by cloning the repo and compiling manually, or by installing a release manually should also follow the developer policies
Licat! 29/12/2024
I’m late to the discussion, a few things I had in mind:
First, I definitely agree that telemetry can be useful to the plugin developer. Just stack trace alone can help catch a lot of problems.
I agree that alternate versions of officially distributed plugins downloaded through brat or installed manually are no different than unsubmitted plugins which are not bound by our developer policies. It’s just impossible for us to police distribution outside of the ecosystem.
One major downside of telemetry is accidental/unintentional secret leakage (for example, uploaded logging that contains tokens, secret keys, names or sections of notes).
Some users will freak out when discovering that Obsidian is making network requests to unfamiliar servers.
Consider that by taking on this data you may be bound by legal responsibilities (GDPR, CCPA, etc) to safeguard the data, have a data protection officer, etc. Do you have a privacy policy that the user must agree to prior to using your beta plugin? Do you have data deletion policies, a way for the user to request their data to be deleted?
Consider that the Obsidian team decided not to use any telemetry, setting the standard for the respect of user privacy.
But also consider how the Obsidian team handles things without telemetry: feedback is obtained from users directly via forum and discord. Debugging modals in the app to gather system information.
You could easily add this in your plugin without telemetry: an error reporting modal when the user attempts somethings and ends up with an exception, where the user can copy paste the stack trace and a link to your GitHub issues section to report the bug.
Some of Licat’s point were in response to some followup examples I made if you’re wondering about their context.
Additional suggestion from community:
ClareMacrae — 28/12/2024, 18:36
I would suggest adding optional console logging and telling your users about the Logstravaganza plugin if they want to report any problems.