Skip to content

Commit b38d7bf

Browse files
committed
Merge commit '05faa111343461ee7a1c3e8248981e87a95504d3'
Fixes #214
2 parents d6a93ca + 05faa11 commit b38d7bf

2 files changed

Lines changed: 254 additions & 1 deletion

File tree

Lines changed: 253 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,253 @@
1+
#+OPTIONS: toc:nil
2+
* Summary
3+
:PROPERTIES:
4+
:EXPORT_FILE_NAME: SUMMARY.md
5+
:END:
6+
7+
#+BEGIN_SRC emacs-lisp :exports results :results value raw replace
8+
(org-build-gitbook-toc)
9+
#+END_SRC
10+
* Introduction
11+
:PROPERTIES:
12+
:EXPORT_FILE_NAME: README.md
13+
:END:
14+
** I Want To Be A Shirt
15+
"I want to be a shirt."
16+
17+
"A what?"
18+
19+
"A shirt."
20+
21+
"Like, you want a shirt with a picture of you on it or something? You can already do that you know."
22+
23+
"No. I want to /be/ a shirt. I want to exist as the piece of clothing. That piece of clothing should be a shirt. I get off on the idea of being a shirt. It has been a dream of mine and we're here for dreams, right?"
24+
25+
Having just spend a non-trivial amount of time lovingly crafting a new type of genitals, with all sorts of bits and bobs and extras, the last thing you want to hear is that your creation is not appreciated. Building something like this that does everything it's supposed to AND communicates across multiple dimensions is not easy, and yet, according to this critic, it has completely missed the mark.
26+
27+
"Why do you want to be a shirt? How would this be better than having some new genitalia? Look, it even vibrates when you poke it like this!"
28+
29+
"Well, yes. That's very good. It even goes all red and bulgy, a nice touch. But... I don't know. It's just always been a thing I've wanted to be. I would much rather fulfill my needs via being a shirt, than to graft on some new body part I'm not even sure I'd be in to."
30+
31+
"And you want people to wear you?"
32+
33+
"That'd be the idea, yes."
34+
35+
Damnit. Damn. It. Everyone was supposed to want one of these new body parts, what with the sounds and the arousals and the thrustings and the juices. Sure the inter-dimensional communication part would be a tough sell due to the learning curve, but once everyone caught on, it'd be a new paradise.
36+
37+
That was the plan, and it'd be awesome, and popular, and there would be much rejoicing. Yet, here we are.
38+
39+
"But you can't be a shirt."
40+
41+
"Why can't I be a shirt?"
42+
43+
"Because that would violate laws. A lot of laws."
44+
45+
"What? It's not illegal to be a shirt anywhere that I know of."
46+
47+
"Not like, legal laws. Physical laws. Laws of existence."
48+
49+
"But don't you control those kind of laws? Or don't some of the others like you have that power?"
50+
51+
DAMN. IT. Note to self: never create worlds that can contain anything capable of making a good point.
52+
53+
"I support we kind of do? But if I change those laws for you, I have to change them for everyone, and I don't think everyone wants to be a shirt. Or pants. Or a shoe. Much less to derive gratification from being any of those."
54+
55+
"Why wouldn't other people want to be shirts? There's so many possibilities. I would be a continual soft hug. I would adorn the wearer and make them look nice. I would absorb their sweat."
56+
57+
"We didn't give you sweat glands. How would you even pull that off?"
58+
59+
"I'd find a way. We've got our own tools down here too, you know. They're just not powerful enough to let me be a shirt."
60+
61+
"Yeah there's a reason for that. What about if you tried to... Ugh, is there even a verb for this? What if you tried to... shirt someone and they didn't know you were a living shirt or whatever it is you're asking for here. Think about the security issues."
62+
63+
"I think it'd be pretty obvious 'cause I'd be talking."
64+
65+
"Oh so you want to be a TALKING shirt? Anything else on this list of demands?"
66+
67+
"Ability to change cloth type? I'd want to stay current with the trends."
68+
69+
"Forget I asked. And besides, not everyon... everyshirt would talk. We already have to deal with enough chaos around here without adding 'Non-consensual shirtings' to our list."
70+
71+
"Hey, you're the one building this world. You wanted feedback on how to do that, and I'm giving it to you."
72+
73+
"You are the worst focus group."
74+
75+
"You randomly asked the first person you saw. Blame fate, not me."
76+
77+
A quiet voice pops up from a few yards, or miles, over. Scale is difficult when you're looking down from above.
78+
79+
"If they get to be a shirt can I be a cube?"
80+
81+
Fuck.
82+
83+
** Why Do I Need You To Tell Me Where My Butt Is
84+
** C'est n'est pas une Buttplug
85+
* Buttplug Ethics
86+
** Wait This Doesn't Sound Technical
87+
** There is No Such Thing As Ethical Buttplugging Under Open Source
88+
** You Must Be This Tall To Code In This Library
89+
* Ok So Here's How You Could Actually Use Buttplug
90+
** Thermonuclear War
91+
** Maybe You Would You Like to Play a Nice Game of Chess?
92+
** Thermonuclear War
93+
* Architecture
94+
:PROPERTIES:
95+
:EXPORT_FILE_NAME: architecture.md
96+
:END:
97+
** Kyle Stop Trying To Be Stunt Rock And Just Write a Fucking Section Name
98+
** Implementation Types
99+
100+
The Buttplug Standard can be implemented in different ways. This
101+
section covers the terms used throughout this document.
102+
103+
** Libraries
104+
105+
Implementing the standard as a library for a certain programming
106+
language allows developers to either build servers on top of the
107+
library in that language, or to integrate the library into their
108+
applications that also use that language (or FFI/bindings to that
109+
language). For instance, the C# implementation of the Buttplug
110+
Standard can be used with a WebSocket implementation on top of it to
111+
be a server that other applications can talk to. It could also be
112+
compiled into a Unity game so that the communication exists only in
113+
the executable itself.
114+
115+
** Servers
116+
117+
As mentioned above, servers are a thin layer on top of a library that
118+
allow other applications to access hardware managed by the server. For
119+
instance, a Web Application may not have the capability to talk to
120+
hardware by itself, but can connect with a Buttplug Server
121+
implementation via HTTP, WebSockets, or other standardized protocols.
122+
Programs like Max/MSP and Pd could communicate with a Buttplug Server
123+
implementation via OSC.
124+
125+
** Applications (aka Clients)
126+
127+
Applications, or clients, refer to programs that in some way interact
128+
with a server to perform some sort of job for the user. A few ideas
129+
for applications:
130+
131+
- A movie player that sends synchronization commands while playing an
132+
encoded video.
133+
- A music player that syncs sex toys with the BPM of the current
134+
track.
135+
- A video game that somehow involves sex toy interaction
136+
137+
All of these would need to talk to a Buttplug server to establish
138+
which devices to use, then communicate with those devices.
139+
140+
141+
* Usage Examples
142+
:PROPERTIES:
143+
:EXPORT_FILE_NAME: usages.md
144+
:END:
145+
*** Usage Examples
146+
147+
To concretize this otherwise theoretical discussion, here are some
148+
in-depth examples of how Buttplug implementations could be architected
149+
in the wild.
150+
151+
**** Library Embedded in a Video Game
152+
153+
First off, a simple example using a single program with an embedded
154+
library.
155+
156+
A developer would like to ship a game on Windows, using the Unity
157+
Engine, that has some sort of interaction with sex toys. Since we want
158+
concrete examples here, let's say it's a version of Tetris that
159+
increases vibrator speeds based on how many lines have been made by
160+
the player.
161+
162+
Due to the nature of games, the developer would want it to have as
163+
little impact on performance as possible. They would also want the
164+
server to exist in the game executable, so that it can be shipped as a
165+
single package.
166+
167+
In this case, the developer could use a Buttplug library
168+
implementation, possibly the C# reference library since this is Unity.
169+
Inside the game, device connection configuration could be part of the
170+
game settings menus, allow devices to be automatically reconnected on
171+
game startup. To communicate with the embedded server during gameplay,
172+
C# message objects could be sent to a thread for handling, so that IO
173+
timing doesn't lag the game loop.
174+
175+
One of the important things lost by direct library integration is the
176+
ability to support new hardware. If a game is simple sending a generic
177+
"Vibrate" command, it is basically future-proofed for all toys that
178+
will support that command in the future, assuming it has a way to send
179+
that message to something that supports the new hardware. If a library
180+
is compiled into the game, there would be no way to add this hardware
181+
support though. There are multiple solutions to this issue, but those
182+
are outside the scope of this example.
183+
184+
**** Web Based Hardware Synced Movie Player
185+
186+
Now, a far more difficult scenario. This example tries to build a
187+
shotgun to hit as many platforms as possible with as little code as
188+
possible.
189+
190+
The goal is to build a web based movie player, that will load movies
191+
with synchronization files, and play them back while controlling
192+
hardware. We will assume we are working with browsers that give us a
193+
minimum of HTML5 Video playback and WebSockets. We want our
194+
application to work on as many platforms as possible. The movie player
195+
should be capable of talking to as many devices as possible on as many
196+
platforms as possible, including desktop and mobile. The main focus
197+
for toy support will be Bluetooth LE toys, with all others considered
198+
nice to have.
199+
200+
At this point, we have to take operating system and browser
201+
capabilities into account.
202+
203+
Operating Systems that have BLE:
204+
205+
- Windows 10 (Version 15063 and later)
206+
- macOS (10.6 or later)
207+
- Linux (with Bluez 5.22 or later)
208+
- Android (version 5 or later)
209+
- iOS (LE support versions unknown)
210+
- ChromeOS (LE support versions unknown)
211+
212+
Web Browsers with WebBluetooth:
213+
214+
- Chrome 56 on Mac, Linux, Android, ChromeOS
215+
216+
This means that if we implement a Buttplug Server in Javascript using
217+
WebBluetooth to access BLE devices, we can target the Chrome web
218+
browser and support 2 major desktop platforms, 1 mobile platform, and
219+
whatever ChromeOS is. We can also ship this server implementation as
220+
part of the movie player application, meaning it will all work as a
221+
unit, similar to the game example above. Future-proofing could
222+
feasibly happen with CDN hosting of the library via semantic
223+
versioning adherence.
224+
225+
Unfortunately, that leaves out Windows and iOS. To maximize ROI on
226+
custom support implementation, we're more likely to see more users via
227+
Windows than iOS, so we'll concentrate on Windows first.
228+
229+
To talk to Bluetooth LE on Windows 10 requires access to UWP APIs, so
230+
following a "When In Rome" philosophy, we can implement a Buttplug
231+
Library in C#. On top of this we can build a server exposed via
232+
WebSockets, to let the browser application talk to the native server.
233+
A native implementation gives us the extra win of USB and Serial, at
234+
least, until WebUSB sex toys become a thing.
235+
236+
Going back to the web application itself, this now means the client
237+
side will need to connect to one of two different styles of servers.
238+
We can use User Agent Detection in the browser to let us know which OS
239+
we're on, and then either select the WebBluetooth path or native
240+
Windows Websocket path.
241+
242+
To hit iOS, we now have the option of going via a Xamarin based C#
243+
app, or a Node.js/Cordova app. There will be some custom
244+
implementation on either side, but most of the heavy lifting will have
245+
been done before this.
246+
247+
An aside for those wondering why this wasn't all done in Node.js. At
248+
the time of this writing, node.js bindings to UWP APIs do exist, but
249+
were still iffy at best. Not only that, distributing a native
250+
application like the Buttplug Server would've required wrapping in
251+
something like nw.js, massively inflating distributable size.
252+
Implementing a C# version of the Buttplug Library also gives us a
253+
platform into Unity integration.

dependencies/buttplug-schema/schema/buttplug-schema.json

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -454,7 +454,7 @@
454454
"type": "object",
455455
"description": "Stops the all actions currently being taken by a device.",
456456
"properties": {
457-
"Id": {"$ref": "#/components/SystemId"},
457+
"Id": {"$ref": "#/components/Id"},
458458
"DeviceIndex": { "$ref" : "#/components/DeviceIndex" }
459459
},
460460
"minProperties": 2,

0 commit comments

Comments
 (0)