OpenEOS - Open source EOS player

[RemiHiyama]

https://xtoys.app/, pointed out by notSafeForDev here, seemed like it could be a good option, but notSafeForDev appears to have dropped off the radar since.

If you're looking for info/help on it, the XToys dev is pretty active on it's discord.

[fapnip]

If you're looking for info/help on it, the XToys dev is pretty active on it's discord.

Thanks. Unfortunately, not having any of the devices for testing makes it kinda difficult for me to do any development on it.

I'll happily add whatever is needed in oeos if other devs want to create and maintain Xtoys scripts for use with oeos.

[RemiHiyama]

Thanks. Unfortunately, not having any of the devices for testing makes it kinda difficult for me to do any development on it.

Not so! The way Xtoys is set up, you can test almost any device 'virtually', you just add it to your dashboard and you can see what the effects of a script would be without actually connecting it to a physical device. This doesn't work for everything, but I think it'd handle everything you'd need from a testing standpoint.

That being said... if the goal is to have a generic api for this, there is a question of "what things do people want to be able to do?" There are things I'm not sure are possible without per-tease scripting at this point.

There's also two different possible approaches for communication between Xtoys and OEOS. The webhook approach (OES calls a url on the xtoys web server, it passes information to the logged-in user, and if they have a script running that responds to that command, stuff happens), and the webpage monitor approach (browser extension monitors webpage for nodes events, which can then do stuff). Webpage monitor only works in chrome AFAIK, so webhook would be better for overall compatibility, but I don't know if there are other issues.

[fapnip]

Not so! The way Xtoys is set up, you can test almost any device 'virtually', you just add it to your dashboard and you can see what the effects of a script would be without actually connecting it to a physical device. This doesn't work for everything, but I think it'd handle everything you'd need from a testing standpoint.

Nice!

That being said... if the goal is to have a generic api for this, there is a question of "what things do people want to be able to do?" There are things I'm not sure are possible without per-tease scripting at this point.

Yes, it gets complicated quickly.

There's also two different possible approaches for communication between Xtoys and OEOS. The webhook approach (OES calls a url on the xtoys web server, it passes information to the logged-in user, and if they have a script running that responds to that command, stuff happens), and the webpage monitor approach (browser extension monitors webpage for nodes events, which can then do stuff). Webpage monitor only works in chrome AFAIK, so webhook would be better for overall compatibility, but I don't know if there are other issues.

The concern with direct API calls is user privacy, but it would be the best way if possible to do without risking user's privacy. I would image an API key would need to be entered, and should never be exposed to the tease's sandbox. I suppose I could just store that in local/tease storage. (oeos can't currently store to Milovana's user account, and probably never will be able to -- but I did add the ability to download/upload tease storage files.)

[RemiHiyama]

The concern with direct API calls is user privacy, but it would be the best way if possible to do without risking user's privacy. I would image an API key would need to be entered, and should never be exposed to the tease's sandbox.

Yeah, there is a place to generate a 'webhook id' that one hopes and presumes cannot be mapped back to the username. It certainly looks like gibberish, at any rate. And it's just a push of a button to get a new one. Mumble (the dev) could probably tell you more.

Given the sheer number of things it's possible to make a toy do with this kind of framework, I imagine the best thing would be to have a built-in command set that would do some basic functions in conjunction with a script on the Xtoys end, plus the option to send custom commands for people who want to get exotic with things.

... So what's basic? This is what I'm thinking...

-Setting a thruster/stroker toy to a given speed. (Expressed as "percentage of the max set in xtoys". Depth and rhythm are not remotely controllable, and exact position is completely off the table. "Strokes per second" type stuff would probably take some mathing.)
-Setting a vibrator to a given intensity.
-Supporting multiple vibrators that can be controlled independently. I don't know what the real limit is, but having support for a few wouldn't be hard and opens up possibilities. And if someone doesn't have or want to use everything, then it's no problem, they just don't attach anything to those outputs and they just do nothing.
-Basic waves and such for vibrating toys. This isn't currently feasible due to limits in the software (scripts can't pass configuration to patterns, and it takes a pattern to do this well), but Mumble has said this is coming.
-Text to speech? Well, maybe, it doesn't seem to even work for me so I don't know what's going on there. This one seems like it might have potential concerns as well, but the user -must- hook up the TTS block in the app for it to work, there's no way for it to make your computer start talking without you choosing to allow it.

That's all stuff that's relatively device-agnostic. There's other stuff Xtoys supports, but I don't think you're as likely to see people rushing to make teases targeted at rotation or suction devices, for example. "Substitute vibration for thrusting/stroking" would be nice, but it's not an easy problem; I found a solution I like but it uses homebrew hardware.

[fapnip]

-Supporting multiple vibrators that can be controlled independently. I don't know what the real limit is, but having support for a few wouldn't be hard and opens up possibilities. And if someone doesn't have or want to use everything, then it's no problem, they just don't attach anything to those outputs and they just do nothing.

I'd need to look at the API more to see how complex adding multiple toys would be. Do each have their own ID? Do I just query and get a list of all toys?

Then there's the complication of presenting those to the sandbox, etc. Seeing an example JS implementation would be helpful. Couldn't seem to find one after a quick search.

-Text to speech?

I'd rather not encourage TTS until browsers are good at it natively.

Speech recognition is something I've thought about adding for triggering choices, but is kind of in the same boat as TTS, with even more privacy concerns.

[RemiHiyama]

I'd need to look at the API more to see how complex adding multiple toys would be. Do each have their own ID? Do I just query and get a list of all toys?

Eh, I can't really show you the api, because there isn't one - or rather, it's roll-your-own, you implement commands in your script that you want to be able to use for whatever you're trying to pull off. Like, take the webhook sample as it is now.

Control any connected toy by sending requests to either of these two URLs.

Set percent:

Code: Select all

https://xtoys.app/webhook?id={webhookID}&action=set-intensity&intensity={percent}

Turn on for x seconds:

Code: Select all

https://xtoys.app/webhook?id={webhookID}&action=temporary-on&seconds={seconds}&intensity={percent}

Replace {webhookID} with your Webhook ID generated from https://xtoys.app/me.
Replace {percent} with the percent you want to set the toy to.
Replace {seconds} with how long to turn on the toy for.

It would be fairly trivial to add support for multiple devices, by sticking a device number parameter on the end or something. Though I don't know if I'd use those particular command names, or exactly the form that this takes under the hood. (Why yes, I am volunteering to do implementation for the Xtoys scripting end of things.)

All communication is one-way. The site sends nothing back but a success message, whether the user has a toy hooked up, whether the script is running, whether the command is valid, or even whether the webhook id is valid. Privacy by way of being a complete black box. If the tease wants to know what toys you've got, it's going to have to ask. Or, more probably, it just tells you that it expects device 1 to be one thing, and device 2 to be another thing, and then the user hooks the appropriate toys up to those outputs in Xtoys and it just works. And if the user doesn't have everything that it sends commands for, nothing bad happens.

I'd rather not encourage TTS until browsers are good at it natively.

Fair enough, I'm not too interested anyway, I just thought I'd mention it because hey, it's on the list.

[fapnip]

Code: Select all

https://xtoys.app/webhook?id={webhookID}&action=temporary-on&seconds={seconds}&intensity={percent}

Having a hard time wrapping my head around how webbooks interact with the scripts. Is there a doc that point it out in detail? Can't seem to find that.

Just scratching the surface, and perhaps I'm looking at it wrong, but it seems like a complicated mess for both users and authors to get up and running.

In any case, the only way I could implement something like this relatively safely is to fully abstract interaction, with a configuration dialog in OpenEos that get all information needed for toy configuration, outside of the tease. But there doesn't seem to be any standardized way to interact with the user's devices -- they need to have the correct script installed, and that script apparently needs to be configured for each their devices correctly, etc. etc.

I wouldn't be comfortable letting the tease author send arbitrary data to the xtoys webhook endpoint, since I'd need to fully trust xtoys.app, and all the given scripts running on it, since that's were real privacy issues can pop up, like a tease asking for a user's email address or phone number and firing it off to a remote host. (Allowing img urls to hit imgbb.com and redgif.com's CDNs is bad enough. Doesn't seem to be any way for anyone but the site operators to gather any data on those CDNs, so probably safe?)

Ideally, I'd like to just have a drop-down in OpenEos's toy configuration dialog that allows adding one or more device with settings for; provider (select list: xToys), key (text input: webhookID), type (select list: vibe, etc.), location (select list: cock, pussy, balls, anal, nipple, etc.)

Then a tease could interact with the configured devices with something like...

Code: Select all

var vibes = Toys.getByType('vibe');
var analVibes = vibes.filter(function(toy){return toy.location === 'anal'});
if (!analVibes.length) {
  new Say({label: "Sorry, you need to configure a vibe for your ass to continue."})
} else {
  // run at 50% for 10 seconds, then goto 'my-next-page'.
  analVibes[0]
    .intensity(.5)
    .onComplete(function () {
      pages.goto('my-next-page');
    })
    .run(10000); 
}

...with OpenEos handling all abstraction.

(Even then, I'm uncomfortable with the idea that sensitive data (anything the user told the tease) could be encoded and sent via the numeric options via multiple calls. Guess I really need to figure out if I fully trust xtoys.)

[RemiHiyama]

Having a hard time wrapping my head around how webbooks interact with the scripts. Is there a doc that point it out in detail? Can't seem to find that.

Well, not really. Partly because this thing is still in early days and there aren't a lot of docs yet. But take the one you quoted.

action=temporary-on - All webhook calls have to have an 'action' specified in them. This is what will actually be compared to something in the script to decide whether or not to run a trigger.

Then the other parameters get stuck into variables, which the script then uses to do it's thing. From there nothing special happens because it's a webhook, it's just a script doing script things.

Since scripts are made, shared, and editable by users, what happens from there is essentially arbitrary. You make your own API.

Just scratching the surface, and perhaps I'm looking at it wrong, but it seems like a complicated mess for both users and authors to get up and running.

You aren't wrong. I'm pretty excited about the things that you can do with it after getting frustrated with the limits of the Lovense app, and once you get things going it works quite well. But the learning curve for actually making patterns and scripts is pretty steep. (Using a premade script, isn't that difficult when you get used to the idiom of adding blocks and then connecting your device to your blocks.)

In any case, the only way I could implement something like this relatively safely is to fully abstract interaction, with a configuration dialog in OpenEos that get all information needed for toy configuration, outside of the tease. But there doesn't seem to be any standardized way to interact with the user's devices -- they need to have the correct script installed, and that script apparently needs to be configured for each their devices correctly, etc. etc.

Ehhh, I was assuming you'd be going with full abstraction anyway. But getting the script wouldn't be hard, and the only configuration is attaching each device to the script's output. Which can be named so you know what's supposed to go where. Whether you're naming by body part or by numbers.

I wouldn't be comfortable letting the tease author send arbitrary data to the xtoys webhook endpoint, since I'd need to fully trust xtoys.app, and all the given scripts running on it, since that's were real privacy issues can pop up, like a tease asking for a user's email address or phone number and firing it off to a remote host.

Hmmm. The webpage monitor (If the extension is installed and the block is attached to a script) can post to web forms, but only if the user opens up that page first. Not saying it'd be impossible to send data outside of the app, but it's not obvious to me at any rate.

Ideally, I'd like to just have a drop-down in OpenEos's toy configuration dialog that allows adding one or more device with settings for; provider (select list: xToys), key (text input: webhookID), type (select list: vibe, etc.), location (select list: cock, pussy, balls, anal, nipple, etc.)

Then a tease could interact with the configured devices with something like...

Code: Select all

var vibes = Toys.getByType('vibe');
var analVibes = vibes.filter(function(toy){return toy.location === 'anal'});
if (!analVibes.length) {
  new Say({label: "Sorry, you need to configure a vibe for your ass to continue."})
} else {
  // run at 50% for 10 seconds, then goto 'my-next-page'.
  analVibes[0]
    .intensity(.5)
    .onComplete(function () {
      pages.goto('my-next-page');
    })
    .run(10000); 
}

...with OpenEos handling all abstraction.

As long as it could take whatever abstraction you come up with and turn it into a call to something like

Code: Select all

https://xtoys.app/webhook?id={webhookID}&action=vibrate&location=anal&intensity=0.5

then that seems totally workable.

Though given the absolute inability to tell whether or not there's actually a toy on the other end, maybe a simpler convention? Unless you'd want to have multiples for the same body part that were running at different intensities* for some reason, why not just go

Code: Select all

Toys.vibes.anal.intensity(.5) ((and so forth))

without requiring the other fooling around every time? There's no reason why a tease should have to tell you more than once, at the beginning, what toys it uses, that's obnoxious for everyone.

*If they were always going to be the same, you could just have one output drive both, which I could see being useful for nipples. Although someone might want to run those separately... I could see value of having a left and right location for those, and also having a "nipples" one that drives both. Easy enough to implement.)

[fapnip]

You aren't wrong. I'm pretty excited about the things that you can do with it after getting frustrated with the limits of the Lovense app, and once you get things going it works quite well. But the learning curve for actually making patterns and scripts is pretty steep. (Using a premade script, isn't that difficult when you get used to the idiom of adding blocks and then connecting your device to your blocks.)

If you, or anyone else, wants to write some scripts for xtoys, then provide me with endpoints + parameters, I'll give it a shot.

Ideally, xtoys would have a proper API, but that doesn't seem like it'll happen any time soon. I was pushed to buttplug.io, which looks interesting, but implementation does not look straight forward at all. The documentation certainly isn't, at least not for my use case.

[RemiHiyama]

I've used buttplug for some stuff before, and it is sometimes non-obvious how to do things in it. I could see it being worthwhile to support both, but I think working through Xtoys is probably the easiest way to make that happen right now. I've got some ideas on making buttplug available through the same basic api via a mediating program... but that's gonna take a lot more doing at this point. (When you think about it, this stuff is still very much in the early-adopter-weirdness phase.)

Like I said, I'm willing to do the Xtoys script side of things.

So, you favor calling devices by location. Not what I'd do, but also not hard to do by any means. So far we've got "cock, pussy, balls, anal, nipple" as a location list. Other than the option for separate left and right nipple control, anything else? Well, clit for one. Not much else is coming to mind. Though I find myself thinking "Is it necessary to have four outputs of which any one user will only be using two? Is anyone actually going to code different things for all of them?" Maybe just a primary and secondary genital 'location', and people can arrange things as suits their own anatomy and available devices?

And then the functions. Basic intensity control is a given. Do you think the "temporary on" function has any value in this application? Because I gotta say, unless I'm missing something that's gonna be a real sonofabitch to script in a way that allows OEOS to stop or change it before it's run it's course. (Well, maybe with variable passing, but that isn't in yet.)

I'd like to be able to do some basic (or even not so basic) oscillating patterns, but that's something where it'll be relatively trivial to implement a pretty wide range of behaviors once variable passing is implemented, and in the current state of not having that, it's essentially impossible.

Support for thrusting/stroking toys... uh, I don't know, that brings in a whole new set of problems that I'm not sure how to deal with right now. Start with just getting vibration to work, I think.

Any other ideas on stuff that would be nice to be able to do?

Edit: This is an example of a command that I've actually got working and will do what you'd expect it to (set the primary vibrator to 25%).

Code: Select all

https://xtoys.app/webhook?id={webhookid}&action=vibrate&location=primary&intensity=25

That look okay?

[fapnip]

So, you favor calling devices by location.

I'm assuming some authors will want to be able to address by location. I honestly have no idea. Perhaps just primary/secondary is enough, and authors can tell users where to put it?

So far we've got "cock, pussy, balls, anal, nipple" as a location list. Other than the option for separate left and right nipple control, anything else?

Thinking it over, if there is to be a location, it's probably better to define toy location on OpenEOS side, so the xtoys side of things doesn't need that complication, but will still need some way of supporting multiple devices.

I'm thinking the OpenEOS UI will need, for each toy:
- Toy control provider: (Only "XToys Webhook" ATM)
[xtoys specific]
- webhookId (provided by xtoys)
- toyId (variable in xtoys script?)
[For all toys]
- Toy type: List of supported toy types (filtered by provider) with specific features (The Handy, etc., with available feature definitions hard-coded.), plus some generics (Vibrator, etc.)
- Toy location(s): (Root locations: anal, pussy, cock, nipple, etc.; plus possibly some sub-categories for each root location: clit, vaginal, etc.) Really only used by authors that want it, else they could use things like, all, etc.
- Allow drag/drop to set toy preference (top is primary, then secondary, then aux1, etc.), addressable by authors
- Enabled/Disabled

And then the functions. Basic intensity control is a given. Do you think the "temporary on" function has any value in this application? Because I gotta say, unless I'm missing something that's gonna be a real sonofabitch to script in a way that allows OEOS to stop or change it before it's run it's course. (Well, maybe with variable passing, but that isn't in yet.)

I'd like to be able to do some basic (or even not so basic) oscillating patterns, but that's something where it'll be relatively trivial to implement a pretty wide range of behaviors once variable passing is implemented, and in the current state of not having that, it's essentially impossible.

Moving beyond just vibrator, would there need to be a different script for each toy type? OpenEOS - The Handy; OpenEOS - Vibrator, etc., with each, script allowing multiple toys added to it? (Not sure what's possible. Just want some way to uniformly address toys, to later be able to control as many toy features as is practical (stroke position, etc.,), for authors that want greater control of specific devices, along with more generic controls (intensity, etc.), and, if possible, some pattern presets until variable passing is a thing?)

Support for thrusting/stroking toys... uh, I don't know, that brings in a whole new set of problems that I'm not sure how to deal with right now. Start with just getting vibration to work, I think.

Yeah, probably just intensity to start, although duration (preferably in ms) is kind of needed. Is that possible?
I've received a number of requests for supporting the handy, so it would be nice to be able to support stroke, etc., as well.

Code: Select all

https://xtoys.app/webhook?id={webhookid}&action=vibrate&location=primary&intensity=25

That look okay?

Yeah, though maybe replace location with a toy id / unique name of sorts, leaving OpenEOS UI to define location?

I'm open to ideas.

[RemiHiyama]

I'm assuming some authors will want to be able to address by location. I honestly have no idea. Perhaps just primary/secondary is enough, and authors can tell users where to put it?

Well, I should clarify that when I talk about primary and secondary, those are both still supposed to be "on the genitals" in some way or another, with the general idea being "primary is the location that gives me the most pleasure, and secondary is something that's still good, but not as good". So one guy might have primary for a vibrator on his penis and secondary on balls, but a guy who doesn't like vibration on his balls but finds vibration on the head of his penis vs the base of the shaft to provide different experiences could place things accordingly. And a woman who gets more out of clitoral stimulation than internal vibration can arrange things accordingly, as can one who's more the other way around. (Not that the other way around seems common, but it's not unknown.) Or maybe they have a vibrator with multiple motors in a line (I mean, I've got one, although Xtoys doesn't support it), and attach primary and secondary based on how they feel about vibration from one end vs. the other.

It's not gonna solve every issue, but I think at least this gives a framework where different people can use the same teases and things should at least *usually* work as intended. And if someone wants to write a tease with different expectations, they can put that stuff in intro text.

Anal and nipples would still be their own locations in this framework, because some people get more or less out of them, but they don't have that kind of ambiguity.

Thinking it over, if there is to be a location, it's probably better to define toy location on OpenEOS side, so the xtoys side of things doesn't need that complication, but will still need some way of supporting multiple devices.

That's actually what I thought at first, but I don't think I agree at this point. Because I don't think it actually makes the xtoys side configuration simpler, it just means they have to go back and forth between OpenEOS and xtoys to get everything hooked up properly, and also makes it a bit harder to leverage the saved layout feature so you don't have to do the whole thing again every time you want to use the same set of toys.

(Also, while I found I needed a weird workaround to make a named location rather than a location number work, having done that I think it may be easier to build and maintain the script this way.)

I'm thinking the OpenEOS UI will need, for each toy:
- Toy control provider: (Only "XToys Webhook" ATM)
[xtoys specific]
- webhookId (provided by xtoys)
- toyId (variable in xtoys script?)

It's possible that, given a possible future Buttplug provider, that people would want to control some toys with one provider and some the other, since their support lists don't fully overlap. I'd suggest a list of locations, with each location having a dropdown or radio buttons for provided devices, and a checkbox for the user to say "I've actually got one hooked up". And above or below that is where you can put in your provider configuration stuff (like your webhookid for xtoys).

Moving beyond just vibrator, would there need to be a different script for each toy type? OpenEOS - The Handy; OpenEOS - Vibrator, etc., with each, script allowing multiple toys added to it?

It certainly seems possible to use separate scripts by feature type, and I can see some arguments for doing so. I just did some testing, and two webhook scripts will coexist and function together just fine as long as they have different action names.

Anything with linear motion toys is going to be a pain though, because they don't all allow doing the same stuff. The only thing that's going to *probably* be possible for everything is "automated stroking at a selected speed". But I don't know how the speed shown in xtoys maps to any given device...

if possible, some pattern presets until variable passing is a thing?)

Honestly I'd rather not unless it looks like variable passing won't be coming anytime soon, which I'm hoping will not be the case based on the course of development so far. It would represent a -lot- of extra work.

Yeah, probably just intensity to start, although duration (preferably in ms) is kind of needed. Is that possible?
I've received a number of requests for supporting the handy, so it would be nice to be able to support that.

There's two things that can be done with the handy right now, from my understanding of things.
-Tell it to stroke automatically at a given speed until told to stop. Pretty easy, will probably also work for most other linear devices.
-Have it play a position/time type pattern, probably from an imported funscript, that must be loaded from within xtoys. This is obviously more versatile, but as a "literally infinite possibilities" situation, it's hard to manage. Support for other linear devices is uncertain and definitely not universal.

[RemiHiyama]

I've published a script using my suggested API under the name "OEOS Bridge Script". Currently only basic vibration is supported. I thought I had a workaround to do some pattern stuff, but... it didn't work.

[fapnip]

I've published a script using my suggested API under the name "OEOS Bridge Script". Currently only basic vibration is supported. I thought I had a workaround to do some pattern stuff, but... it didn't work.

Thanks! I'll take a look next time I free up some time to work on OpenEOS.