That’s a bit of a stretch. Bluetooth in itself is local and only local. However, depending on how you consume your videos and scripts it may be local or streaming via Internet or a combination of them. The stroker device manufacturer is not involved, even if you stream the content, while using bluetooth. Bluetooth is therefore not susceptible to stroker device manufacturer server downtime (only content provider downtime unless using local content).
Another issue is that not everybody do what they say in their privacy policy (this is not an accusation against SLR). There have been several studies on apps declaring that they don’t share data with third parties, but when tracking network connections and data packet transmissions researchers can see that large quantities of data are sent to 3rd party IP addresses that don’t belongs to the app manufacturer, CDNs or other acceptable recipients. Given the taboo/stigma around porn in many countries privacy is a concern for many. You don’t want adult ads popping up while browsing due to your sex toys.
I believe that supporting both bluetooth (at least for local content) and wifi using centralized servers (or not) is the best way to go. A public API is also important for a niche community that scripting and software for stroker devices still are. See also the creativity and ideas around interactive games and other apps supporting user interaction that don’t really work well with unpredictable Internet delays. Internet and overloaded servers causes all kind of synchronization issues when sending commands based on user actions. It isn’t just simple timestamps that can be sent at a semi-regular interval while the script is stored in the device.
I didn’t say the movement commands were sent over the internet, but the connection might still require it to connect the player with the haptics app. Depending on how it’s set up.
It’s pretty easy to test which one it is. Unplug your internet connection, see if you can set up the connection between the apps and device(s)
Also this is pretty straight forward. Does the website you use have any 3rd party ads? (content partners are 2nd party.) Are you sent to an external payment gateway before entering your personal information? (You want this! Don’t trust porn or dating sites that require you to fill it in on their own site, Especially don’t give out your address, or any so called ‘age verification’ information. Like a social security number. - Your credit card/debit card, even paypal IS the age verification.
I totally agree, but with one exception. Some sites only collect usage data and sell it without displaying ads as a way to earn money. This is extremely hard to track as a user unless you actually track outgoing network connections from processes on your device. It’s even trickier if the app send data to their own servers and then sell the data at a later point. A good example of this was the infamous Cambridge Analytica a few years ago. They collected user data on facebook and sold the data to third parties. There is a reason for why GDPR came into place as a mean to protect EU citizens. But now I’m off topic. Sorry for that.
I really like the approach of the current wifi enabled tcode devices (OSR2/SR6). They communicate wirelessly over wifi (no bluetooth) and do not require any remote server to operate. There is 0 latency and the connection is incredibly reliable and you can pick any t-code enabled player to play your scripts.
On a consumer device I imagine you would have a companion app that connects to the device over bluetooth to sync some settings (wifi credentials, etc). After that all communication could be done through WIFI.
I believe that requiring the device itself to connect to an external server in order to operate is unnecessary and would offer no advantage to the consumer whatsoever; it only adds an unneccessary dependency on an internet connection and the availability of the service (which is not guaranteed to continue in perpetuity, many older online games can no longer be played for instance).
The advantages for the manufacturer are many as they can 1) prevent/limit interoperability with competitors, 2) increase switching costs for the consumer, 3) control the lifcycle of the product, 4) DRM
I’m talking more about the connected toys… Not SLR’s solution for providing the scripts… I don’t want to have a toy maker to require a phone home system… So I feel that having it be the standard is opening a Pandora’s box… I’m fine with using WiFi but the moment we are required to use the internet for just using our toys as a universal standard (SLR provided scripts or not) is the moment we go down a rabbit hole of many problems… I’m my opinion