What to do with the Strava implementation #64
Replies: 2 comments 1 reply
-
|
I think a lot of people will use the build in health / fitness apps in Android or Apple ecosystem. From a political standpoint I would prefer not to, but that is irrelevant to what is a wise choice for ORM to integrate with. And since these apps from Apple or Android can sync data with a lot of other apps that brings the most versatile options for users. But I don’t know if these apps from Apple nd Android support rowing. |
Beta Was this translation helpful? Give feedback.
-
|
For all interested: the current new-ble-api branch, which will become 0.9.6 in a couple of weeks is functional and will contain the redesigned Strava API (as well as support for intervals.icu and RowsAndAll.com). This will be a breaking change: you will need to authorize the Strava app manually (procedure will be described in detail in the manual, but it will be based on https://gist.github.com/michaellihs/bb262e2c6ee93093485361de282c242d). We will support two types of upload (as for all three services):
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Now that our file creation is reasonably complete, I'm looking at what to do with these files. Lars has created a Strava integration 3 years ago as part of 0.8.2, which I maintained since then. But that remained the only integration, as Strava used to be interesting as a single portal to many other analysis platforms, greatly increasing data portability for users in a single integration.
However, today Strava announced these platforms aren't allowed to analyse data anymore, greatly limiting your use of your own data. RowsAndAll.com is one of the affected parties, which can't do analysis on rowing data obtained via Strava, nor can coaches (which you pay to help you) see your data anymore. This renders Strava useless as a conduit. In all honesty, I have strong issues with their approach, as it goes against OpenRowingMonitor's founding principle that your data must be as free and accessible for you as you want it to be. I think that should be the leading principle for the entire sport metrics ecosystem.
Some things also bother me from a technical perspective, as I see OpenRowingMonitor somehow decides that the user gets a question, and that triggers the Strava upload in a complex interaction between frontend and backend. That implementation doesn't fit well with our new technical architecture, and it will never work on headless units. Given that Strava uses Oauth2 authentication, I have concerns it will ever fit well in a way that Oauth2 is intended while fitting our intended use cases and architecture.
I also see what other (free!) data analysis platforms, Intervals.icu and RowsAndAll being the primary ones, are doing. Automatic uploads are much simpler, their analysis is far superior to Strava's (especially for rowing) and they do respect the user's desire to share and analyse data freely across many platforms. I personally think eliminating Strava's role as a conduit here would benefit users, as it puts users firmly in control of who sees their data, and not a vague social media company that struck gold.
Personally, as a daily rower on EXR, I do post to Strava for social reasons, but I use EXR to connect to Strava as it also uploads nice pictures and virtual geodata. This, combined with Strava's diminished role as (conduit to) a data analysis platform, would make direct Strava integration for OpenRowingMonitor less relevant.
So my key question is if we want to keep Strava integration and how elaborate should it be?
8 votes ·
Beta Was this translation helpful? Give feedback.
All reactions