Teledildonics, or taking "OwO what's this" to the next level

[kaniini]

Lately, I have been thinking about designing a new virtual world, which uses some parts of IRCv3 as a client transport. However, as has been proven with other virtual worlds like Second Life, Tapestries and the FurNet IRC network, the primary purpose of a virtual world is the consumption and production of smut. And while interaction on a textual basis is nice, I believe we can make the experience more pleasurable for consenting adult participants doing consenting adult things.

Please note that nothing in here is a specification per se, and most likely things in here will have usefulness outside this specific domain. Accordingly, this idea should probably be broken up into multiple specifications.

Consent is critical, especially when involving devices connected to an IRC session and, well, you

A critical aspect of any protocol design in this space must include consent. After all, we are talking about the discovery and manipulation of devices attached to human¹ users.

Use of Object Capabilities (OCAP) as a way to transparently provide consent

Object Capabilities provide a way for two parties to agree on the authorization of granular access to a given object. A good example of an object capability system would be something like OAuth 2.0². Object Capabilities are also occasionally compared to things like car keys, etc. They convey authority to access an object, but do not themselves contain any authentication data.

A theoretical example where a teledildonics OCAP is requested and granted:

@+ocap/req=td/* :bunny!~bunny@example.com PRIVMSG kitty :hewwo
@+ocap/grant=UN3DLWPXQND3RHB55GJQXULPBY :kitty!~kitty@example.org PRIVMSG bunny :hi
@+ocap/authority=UN3DLWPXQND3RHB55GJQXULPBY,+td/cmd=inq :bunny!~bunny@example.com PRIVMSG kitty :*notices ur bulge* OwO what's this

Ironically bad roleplaying aside³, a key thing to note here is that the grant is just an opaque token: only kitty knows what, if any, semantic meaning the token has.

Key Components of a Teledildonics System

Consent

This is covered by the OCAP system I described above. The specific UX for granting authority is left to the reader to implement for themselves.

Discovery

In the example above, I use the tag: +td/cmd=inq. This is intended to mean INQuiry⁴. A user MAY reply with a device list when an inquiry is made:

@+ocap/authority=UN3DLWPXQND3RHB55GJQXULPBY,+td/cmd=inq :bunny!~bunny@example.com PRIVMSG kitty :*notices ur bulge* OwO what's this
@+td/cmd=resp,+td/dc=1,+td/dev/1=RezTranceVibrator,+td/dev/1/type=vibrator,plug :kitty!~kitty@example.org TAGMSG bunny

This TAGMSG describes that kitty has a single device attached to the IRC session: a Rez Trance Vibrator⁵ that is a vibrator and a plug. But what does that mean?

Ontology of Device Types

There should be two basic device types:

• A plug is a device that can be inserted or used on the exterior of the body.

• A socket is a device that is a recepticle for a body part.

Then you have some different kinds of devices, which should be obvious, so I'm not going to bother explaining them⁶.

Interaction⁷

There are at least two other commands needed, and two properties:

• +tc/cmd=on: Turns the device on.

• +tc/cmd=off: Turns the device off.

• +tc/intensity=[0..1]: A floating point value which indicates the requested intensity.

• +tc/dev=target-id: The target ID that is being manipulated.

These commands, like the inquire command should include some form of authority token.

Footnotes

^1. On all levels except physical, I'm a rabbit.

^2. The reason why it is a good example is because it literally is an Object Capability system.

^3. With apologies to all furries everywhere.

^4. This smells like MIDI, doesn't it?

^5. I miss the old SEGA, don't you?

^6. Lets face it, this proposal is already super awkward. There's no reason to make it worse.

^7. I'll spare you the bad roleplay for this part. You're welcome.

[kaniini]

As was mentioned in IRC, even with an OCAP token securing the teledildonics interactions, it is possible for an evil NetAdmin to snoop the entire conversation, acquire the OCAP token and mess with the teledildonics session.

Accordingly, I submit "don't use teledildonics mode on networks operated by incels" as a security consideration for this proposal.

[jwheare]

I think it's safe to say this out of scope for ircv3 and a good candidate for vendor prefixing for anyone that might want to pursue it further outside the working group.

[kaniini]

(that's why i submitted it as an idea)

[kaniini]

with that said, I do believe the OCAP portion is in scope for IRCv3. what are your thoughts on that @jwheare? client-to-client permission negotiation seems very in scope to me.

[jwheare]

Would probably need an in-scope use case that's more likely to gain adoption/implementation.

[awilfox]

OCAP sounds like a thing that could be useful for A/V communication, if that ever gets off the ground. First thing I thought of for "in-scope use case".

[kaniini]

right, for stuff like ICE (no, not the fash kind, the NAT-busting kind)

[dequis]

I thought we banned kaniini

[Mikotochan]

for consenting adult participants doing consenting adult things.

RIP 14 year old furries, you won't be missed

[qdot]

As the developer of teledildonics system for both Second Life and Tapestries, as well as IRC v2 teledildonics as part of the emacs ERC client (https://github.com/qdot/deldo), I'd love to be involved in this development effort. Please check out our protocol work at https://buttplug.io and https://github.com/buttplugio, and feel free to get in touch.

[iv3i53]

Object Capabilities provide a way for two parties to agree on the authorization of granular access to a given object. A good example of an object capability system would be something like OAuth 2.02. Object Capabilities are also occasionally compared to things like car keys, etc. They convey authority to access an object, but do not themselves contain any authentication data.

what's an 'object' in an implementation? the protocol should allow very selective restrictions. not just a whole device. eg a multi-channel e-stim device or an upper bound to intensity being granted.

(full disclosure in case it wasn't goddamn obvious: this is a throwaway account)