Add RLV Support

[bennettgoble]

Description

This proposal advocates for integrating support for the Restrained Love Viewer (RLV) API into the official Second Life viewer. RLV is widely used in Second Life to enable enhanced interactive experiences, offering greater flexibility in avatar control, inventory management, and scripted interactions.

Why?

A significant amount of content in Second Life relies on RLV functionality to provide immersive and interactive experiences. Currently, users must rely on third-party viewers to access this functionality. By incorporating RLV support into the official viewer, we can:

• Improve feature parity with popular third-party viewers.
• Reduce fragmentation in the Second Life user experience.
• Enhance support for interactive games, building utilities, and scripted experiences.
• Provide a more consistent and reliable implementation of RLV.

Considerations

• Community Adoption: RLV has a strong user base, but some aspects of its functionality may need refinement or adaptation for inclusion in the official viewer.
• Security & Compliance: RLV allows external scripts to control certain aspects of a user's avatar. Ensuring robust security measures and user consent controls will be crucial.
• Development & Maintenance: Integrating RLV requires ongoing support to keep it aligned with Second Life's evolving platform.

Steps

(Some of these may have already been completed, as we have been working on integrating RLV for some time)

1. Feasibility Study – Assess the technical and security implications of integrating RLV.
2. Community Feedback – Gather input from developers and users who rely on RLV.
3. Development/Integration – Start porting RLV functionality and required features into the upstream repository

Acceptance criteria

• Existing in-world content works with the upstream viewer

References

• RLV-API

---

By adding RLV support to the official viewer, Linden Lab can provide a more feature-rich, unified experience while better serving the needs of the Second Life community.

[canny]

This issue has been linked to a Canny post: Add RLV Support 🎉

[KittyBarnett]

Community Adoption: RLVa has a strong user base, but some aspects of its functionality may need refinement or adaptation for inclusion in the official viewer.
Development & Maintenance: Integrating RLVa requires ongoing support to keep it aligned with Second Life's evolving platform.

One of the biggest questions for me is still: what happens after RLVa's contribution? Will Linden Lab then go solo and unilaterally make changes that impact RLV users and over a decade worth of existing scripted content relying on it?

Right now, all control over RLVa sits with me (and Marine for RLV in her viewer, though we mostly operate independently). Even so, I don't make decisions in a vacuum — I consult with friends and discuss things with people who suggest new features. That said, I recognize that this process is still largely opaque to those who don't know me or aren't aware of what's going on.

To address this, I've started experimenting with RLVa office hours and a more formal RFC process, where proposals can be discussed in real time. The proposal repository has also been picking up. While there's still a long way to go, I already feel it has been beneficial in refining and improving proposals and giving interested people a way to get involved.

To make it more concrete, RLV users generally fall into three distinct categories:

• Casual users – They enable RLV for a specific scripted object (e.g.Wardrobe) but don't want anything else to control their avatar. They want to remain in control at all times.
• Average users (by far the largest group) – They keep RLV enabled at all times but don't want it affecting their regular SL experience when not in active use. They use it for vanilla scripted objects as well as kink/lifestyle content and expect those objects to function as intended, without additional safeguards or restrictions.
• Hardcore RLV users – Some prefer RLVa to be as user-unfriendly as possible because it enhances their experience. They generally want an experience that would be undesirable to the other two groups and want their SL experience to be as locked down as it possibly can be.

Any RLV-related decisions must carefully balance the needs of all three groups. Each group is valid and deserves to have their preferences respected, but their desired experiences often conflict. While I hope to make decision-making more transparent and inclusive — and ideally have more than just myself to rely on for approvals — I don't believe any person or entity who isn't willing to represent all three groups can successfully lead this process.

A major concern is that handing LL control over RLV would dilute the experience for everyone to the point where no one is satisfied. This would then lead TPVs to diverge from LL's implementation in an attempt to meet user complaints, ultimately resulting in two incompatible RLV systems — something that benefits no one.

I don't know what the ideal solution is. It's certainly not just me making all the decisions, but it's also not LL doing it alone. Ideally, LL would commit to participating in the process that's being set up, or a resident-run committee (whatever form that takes) to ensure RLVa remains true to its users and consistent across all supporting viewers.

A practical example: Some casual users want the ability to turn RLV off at will or to have "attachment locking" function as a soft lock, meaning they could still right-click and detach locked items whenever they choose. I completely understand why they'd want this—it would make them feel safer enabling RLVa, knowing they could turn it off immediately if something goes wrong.

However, allowing that would undermine over a decade of BDSM content and ruin the core experience of RLV for the other two groups. The solution I'm working on isn't to grant that request outright, but to refine the conditions under which RLVa can be disabled and introduce a new 'soft' attachment lock. This new lock would allow attachments to persist through outfit changes while remaining detachable on demand, making it more suitable for vanilla content.

This approach avoids breaking existing content (which would otherwise force TPVs to fork from LL due to user outcry) by saying: "No, you can't have exactly that, BUT here's a solution that works instead."

Similarly, there have been many kink-related feature requests that had to be turned down because they were too niche or would negatively impact other RLV users. Another key consideration is that a significant number of kink RLV residents use scripted RLV relays set to 'auto' allowing non-owned objects to execute RLV commands freely. As much as I'd love to implement certain features, I have to consider the potential impact — such as someone teleporting into a kink space and exploiting auto-accept relays for significant griefing.

Security & Compliance: RLVa allows external scripts to control certain aspects of a user's avatar. Ensuring robust security measures and user consent controls will be crucial.

I actually completely agree with this, though it already highlights one of my concerns—namely, that "while not negatively impacting the existing user base or breaking the spirit of existing content" is missing from that statement.

I'm actively working on introducing additional safety measures for the casual user category in the form of a safe mode, which I believe is crucial to have in place before RLV makes its way into the LL viewer. However, this is being done within the existing framework, ensuring that it doesn’t break the fundamental contract between RLV and scripted objects.

That said, having LL's support could significantly enhance the user experience - an extension to llRequestPermissions, for example, could be invaluable. The key caveat is that we cannot break all existing content, some of which may never be updated. That means the "unsafe way" will still need to be supported, but safe mode users wouldn’t be engaging with those scripts anyway. Meanwhile, vanilla scripters with active products would have a strong incentive to adapt their content to be as appealing as possible. Even so, this kind of change must be done in cooperation with creators, ensuring they have time to prepare rather than being blindsided by broken content.

---

All that said, it's certainly not my intent to be negative in any way. In fact, I’ve been - and still am - incredibly excited that LL is seriously considering this! But I want to make sure that both sides don’t invest a significant amount of work only to end up with a system that TPVs ultimately reject because it’s fundamentally incompatible with what their users want and need.

There’s still so much more to discuss, but ensuring this issue is addressed has been top of my personal list and what's needed to make me feel fully committed to this process. I’m looking forward to continuing this conversation (wherever and however it takes place) and finally moving things forward again! 😊

[0xc0ffea]

One of the key points when Kitty and I discussed this with Vir pror to work starting was that RLVa would be provided in the Linden viewer as shipped in TPVs. No changes, no special new rules, no breakage, no disruption to user expectations or content delivery.

RLVa is very much designed to be all or nothing, and this assumption is baked into every RLV enabled object ever created.

The main upshot of this is RLV scripts do not have to do complicated checking for capability or verifying that commands have been executed or are still in play.

1. Verify RLV is present.
2. Issue the command.
3. Assume it worked.
4. Never look or check.

This is fundamental to the operation of all content that has been made with RLV commands, much in the same way that LSL scripts can assume all LSL commands are included and functional right from the start.

---

Breaking this assumption creates several major problems, some social, some technical.

Content creators will have to retool their products to work with any new permissions or optional nature of certain commands, this presents a choice to the content creator depending on the which segment of the market they are in.

• A utility that uses RLV might remove menu options for commands that aren't available.
• An adult toy may demand that the user provide consent, publicly shame them for opting out, refuse all function.

We have already seen adult toy makers chose to leverage social mechanisms to publicly shame users deemed to be "cheating" with aggressive messaging, bright red hover text that can only be removed by a 3rd party, additional inconvenient commands, black listing users and so on. This kind of social pressure predates RLV entirely, early collars would rat out the wearer should they accidentally detach the object.

Some products go to great lengths to ensure that the "security" of the power play their toy provides is maintained including encoded data baked into the objects, off site databases, requiring the user to purchase a special "unlock device". etc. At face value this might seem anti consumer, however quite the opposite; it is very much a selling point.

This kind of social engineering is far easier than the technical engineering required to provide a toy that functions in an uncertain landscape.

---

There is a massive amount of legacy RLV content that is in constant daily use and will never see an update to a system that doesn't delivery the 'all or nothing' premise RLV was built upon. Many content creators are no longer in Second Life, no longer develop for Second Life, or have passed away.

Some of these items are deeply sentimental and hold special meaning in relationships.

Breaking RLV in old content will result in visceral push back along the lines of "Linden Lab broke my wedding ring."

---

RLVa in the Linden viewer that is not shipped EXACTLY as provided in third party viewers has one outcome.

A nerfed "Linden RLVa" is about the worst possible outcome and one we were assured in talks with Vir would not be the case. Users will loudly reject the feature entirely and only use TPVs that provide the complete expected experience.

[ChloeConstantine]

As an RLV user and content creator, there are issues that concern me a lot, some of them may be repeating what Kitty has already said, but they bear repeating.

• There are a number of very well-known content creators who are no longer in SL; their products work. If the labs introduced RLV but broke that existing content I wouldn't see anyone switching to the labs' viewer.
• I know we can't expect backwards compatibility forever, but the more things get broken, the more people will stay with the TPVs supporting RLV as is!
• The differences between RLVa and RLV are regrettable. There are people who are willing to go to great lengths to provide similar functionality in both implementations. I am not one of them; having a 3rd choice only makes things worse. I would continue to support whatever system the majority of RLV users are using.
• I'm not happy about the tiered approach, but as an active creator, I think I see a way that I can operate within it even though it means I would need to update my whole product line.
• The open office hours and RFCs that Kitty have provided seem, to me, to be the ideal way to ensure that both RLV continues to evolve (assuming someone is willing to do the implementation and get us out of the opaque nature of new RLV features. Indeed, if the tiered RLV is the wave of the future I have already put in a request for a new RLV feature that will make my life as content creator easier.

I've heard talk about RLV in the labs' viewer and am happy to hear of it, but I also think that if Kitty is willing to commit her time to making it happen that the labs should commit to making it happen as well otherwise the labs are just being abusive to Kitty.

[Anwenn]

One concern I would have, is Linden's long history of trying to sequester what it perceives as Adult Content behind gated access, I'm illustrating that concern here, as Linden potentially limiting the functionality of RLV to (hypothetically) [A] rated regions.

RLV (the standard) is utilized by a lot of scripted tools that have nothing to do with adult content. From photography tools, to scripted outfit changes through tools like Wardrobe, to simple 'force sit' or 'follow me' scripts like you might find in many popular parent/child systems.

I use a child avatar.

I can't claim to know every non-adult tool that utilizes RLV(±a), but I know a number do. I've even made tools for myself that utilize RLV's 'never allow detaching', to make sure I always have a script on me that is monitoring the land rating of the region I'm in.. ready to yank the cord and TP me back to safety at the speed of LSL, if a teleport, landmark, or relog to an infohub accidentally finds me in an [A] rated region, while wearing the child avatar.

I consider this tool crucial to surviving the current rules regarding child avatars, so for me, that RLV 'detach=n' command has to work, on every region, regardless of rating, to keep the attachment from slipping off due to an outfit change or some other accident. This means I can't trust the standard SL viewer to keep me safe.. which leads me into the other concern.

I'm concerned that Linden may attempt to access gate this function, either by viewer class (desktop, mobile, web streaming), or by membership class.

Any situation where RLVa is implemented in desktop, but not mobile, (for this example) creates a scenario where RLVa users will refuse to use mobile because their devices will 'tattle' that they broke out. Any situation where RLVa access was only available to (let's say) Premium Plus users.. would largely create a case where most free users would avoid the Linden Viewer, rendering the effort moot for the number of people it would actually entice to the mainline viewer would be limited (why bother, when Firestorm already has it, and everyone is already on Firestorm?)

This really does feel like a situation, like others have said, where Linden has to either accept the whole thing, as presented and built, AND commit resources to keeping it functional without breaking it (with at least the same care they used for over a decade keeping unintended features(bugs) like invisiprims and deformers working). If LL wants to make changes, or add extra interstitials, permissions grants, constant 'are you sure' nags, etc.. it's just going to annoy people, and convince them to stick with TPVs even more, and to continue encouraging the few new users that do appear, to switch to third party viewers asap.

[beqjanus]

Any decision to make unilateral changes to RLV would be a monumentally short-sighted decision, a complete waste of effort, and for that reason alone, I cannot believe that LL have any plans to do that. Ultimately, it would be just that, a unilateral change as TPVs would not adopt them and service only to make the LL viewer incompatible with all the existing RLV products (which is how it stands today)

However, reading the body of this issue I can see why some worries are arising; it does imply tampering with the security model and other subtle points that are cause enough for concern. Any changes that have impact upon the existing RLV(a) protocol and thus potentially introducing conflicts within existing products would be strongly opposed by the RLV(s) community and as such Firestorm, and I would imagine other TPVs would not follow this path to avoid the ensuing mess that would result. We have managed quite happily for many years now without "improved security models", and making changes at this stage would need a very strong case to be made. As Kitty says, the wording is simply too lose. I don't really see a need for a "safe mode", (just don't enable RLV - simples) however, any such thing would need to be demonstrably backwards compatible with existing content.

I have expressed this position from the very outset of the discussions between Kitty and Vir. We've seen all kinds of madness discussed such as "rewriting" RLV support in LUAU and I hope that all such notions have been kicked into touch.

If the intention in adopting RLV into the Linden Lab viewer is to bring feature parity with TPVs then that is exactly how it needs to be implemented. RLV is a complex platform with a very broad installed user base. We cannot allow it to fork into something that appeals to some concept of "safe" that applies to people that don't use RLV today and probably don't even need it; down that path lies only;y pain and complaints we've been here before we already have a halfway house "safe" solution from a previous broken attempt. We don't need another "experiences" clone.

It is worth asking "why do this" when there are many other things that could be worked on that arguably need attention more than RLV does. In fact one of the reasons cited for why a user likes the LL viewer over and above FS or any TPV is that it has no RLV and they trust LL more than they trust "us". Naturally I don't agree with that perspective, but that's not the point. Users that feel safer on a viewer that has no RLV will be disconcerted by this.

One good reason for doing this is to lift the burden from Kitty and Marine as sole maintainers of RLV(a) today. By having it embedded upstream, and placing the onus on compatibility and regression testing at source, then it secures the future of RLV. The emphasis here though has to be on adoption, regression testing and compatibility.

Towards the future. Extending RLV(a) beyond its current state is technically fine, so long as we adhere to the previous points. New features however, should be led by the community, to ensure that it retains the compatibility, and aligns to the needs and expectations of the community of users who understand the many and varied use cases for RLV across the multitude of sub-cultures within Second Life.

[bennettgoble]

The intention is to pretty much go with RLV APIs as they are now without revising or coming up with new ones. Sorry if that's how the issue read.

(Some of these may have already been completed, as we have been working on integrating RLV for some time)

Re-emphasizing, and I'll edit the issue to be more clear.

[MarineKelley]

Hi! Marine here, creator of the RLV.

First I'd like to precise that RLV is a specification, a document. RLVa is one implementation of this specification, there are others. RLV (the viewer I maintain) and Kokua are the original implementations of it. CoolVL is another. Implementing the specification fully guarantees a script that it can use the documented commands in the way they are specified, without having to know which viewer the script is communicating with. The script should not care whether the user is on RLV, Kokua or Firestorm. If it sends a command to the viewer, then the result must be the same in all cases. There are, however, slight differences between the implementations.

The very first version of the RLV went out in November 2007 and it was an immediate success. People want some of their objects to be capable of controlling some of the aspects of their viewer. And not only for kinky purposes, even if it was the focus at first. 17 years later, it is still popular and still widely used by more scripts than can be counted.

The reason for its success is simple: trust and consistency.

Trust that the viewer won't screw the user over by forcing them to pay for stuff, or deleting their inventory items, or spy on them, or communicate their password, or whatever. Despite all the restrictions the RLV can impose on the user's avatar, controlling payments, IMs, inventory items and passwords are hard limits that the RLV spec never crossed, and hopefully never will. I say "hopefully" because while I'm in control of the spec, if LL takes over that won't be me anymore.

Consistency in the specification means it won't change on a whim, once a command is specified, it is set in stone because one must assume it is already used by hundreds or thousands of scripts. Change one detail in the specification, and you break countless scripts.

Despite its origin, the RLV isn't restricted to adult play at all. It is a middleware that extends a script's capabilities through viewer commands, that's all. It has been used for educational purposes (for disabled users, notably), and for non-kinky commercial purposes (wardrobe management and the like).

I was in contact with Vir Linden and gave him the information he needed to know what the RLV was about, so I'm ready to discuss with Signal as well if he needs pointers.

I'm all for adding RLV functionality to the official SL viewer, and I don't really care who implements them (as long as it's not me), but with conditions if it wants to be qualified as "a RLV" from the script's standpoint. Because if the SL-RLV doesn't do everything the RLV does (that the script can use), then it does not qualify as a RLV. Simple as that.

• Trust and Consistency must remain the first tenets of the RLV (see above). Don't break the user's or the scripter's trust, don't break the consistency of the specification.
• The SL-RLV must implement the RLV specification fully, in a way that the scripts can use the RLV commands without forcing the scripters to look into the RLV code to know how to use them. The specification should be enough for a scripter to know what to expect.
• The SL-RLV must not do what a script can do. The RLV specification is a way for the viewer to extend a script's capabilities, it is a middleware that must play with it, not against it. The moment the RLV does what a script can do, it becomes a competitor with it, breaking the very trust the scripter has in the specification, ruining its very purpose. If a scripter can't trust the RLV as a tool, they simply won't use that tool.

I'm aware that the specification itself is obscure at times. I wasn't the best at writing spec documents back then and it evolved quite a bit so it would benefit a rewrite (in shape, naturally, not in content). I'm available if Signal wants to contact me and obtain all the information he needs.

Marine

[ChorazinAllen]

Hi!

I want to go back to basics for a moment to clean up some ambiguities in the original Issue text.

RLV is a term that has dual meanings. There is the API at https://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI which I will refer to as RLV-API from now on and there is Marine's implementation which I will refer to as RLV from now on. RLVa is Kitty's implementation of RLV-API.

RLV-API and RLV correspond very closely, unsurprisingly.

RLV-API and RLVa also correspond closely but with various intentional differences which scripters need to keep track of to write products that work reliably and seamlessly with both RLV and RLVa.

Here are a few examples to illustrate the point.

• Commands in RLV-API but not in RLVa: @camdrawmin/max (vision spheres, as distinct from @setsphere functionality)
• Commands that operate differently in RLVa compared to RLV-API: @versionnum, @tplocal
• Commands in RLVa but not in RLV-API: @setoverlay, @pay, distance limiting IMs, changing group role
• Other differences: whether negative channels can be used for replies from RLV-API commands; whether some persistent commands use =force or =n; extended parameters on some commands

This is an opportunity to get to alignment and eliminate these differences by either adopting them into the RLV-API (and ideally also to the RLV codebase) or acknowledging and documenting them as optional features that remain implementation specific.

As it stands, it's an oversimplification to say that porting in RLVa to the LL viewer will result in an implementation that matches today's RLV-API.

I am hopeful that this proposal will result in one definitive implementation that aligns exactly with the RLV-API as it then stands. Like other commentators I am fearful that what we might get instead is effectively a third implementation of RLV-API with its own quirks and variations from RLV-API as it stands today.

-- Chorazin

[bennettgoble]

Thanks for the breakdown of implementations and standards, @ChorazinAllen. I will rework the issue in an attempt to be sure it correctly refers to APIs correctly.

---

I also want to be sure the intention is clear: the primary goal is to get existing in-world content working with the official viewer. This includes content in all its forms, adult and otherwise.

[bennettgoble]

There seems to be a lot of bad faith in how LL will adopt the RLV standard. I can understand why there isn't much trust here, after all: it's taken this long to get this this point. I'm not really sure how to counter that other than by executing well.

From a vaguely outsider perspective (both as relatively new manager above the Viewer team in LL, and as a SL resident that has used and built scripts that use RLV) I have viewed RLV as a single "thing." I do not want to create a fractured ecosystem. At the same time, as an engineering manager, I would like to move forward pragmatically with the goal of implementing the majority of the existing API specification, and if there are minor details in behavior, that can be captured in bug reports/issues which can be filed and fixed quickly.

---

I created this issue in a public space for discussion so that any conversations could happen transparently, not sure why they weren't happening in a public forum before, but I would also like to kindle remind folks of this point: https://github.com/secondlife/viewer?tab=coc-ov-file#try-to-be-concise

[KittyBarnett]

There seems to be a lot of bad faith in how LL will adopt the RLV standard. I can understand why there isn't much trust here, after all: it's taken this long to get this this point. I'm not really sure how to counter that other than by executing well.

I can only speak for myself, but I don't feel any bad faith toward LL. My skepticism comes from the sense that there isn't a deep understanding within Linden Lab of what integrating RLV truly means - both for the viewer and the broader impact on developers and support teams. In some ways, it feels like the clock has been reset, and I'm starting from scratch again, but with even fewer opportunities to communicate efficiently and to make quick progress on smaller, manageable steps while the bigger issues are tackled over time.

There's a sense of overeagerness, which I believe comes from a good place, but I also want to temper it. I don't want to invest literally hundreds of hours of my spare time only to reach the end of it and have LL finally grasp the full scope and then say, "Well, actually, thanks, but no thanks."

The measured approach was intentional and agreed upon: to ease things in gradually, giving LL developers time and opportunity to incrementally review the code properly (rather than accept a massive code dump blindly), while meanwhile giving me the opportunity to refactor parts of RLVa that are now ~16 years old o to fix outstanding bugs. This also includes introducing new features that will be needed moving forward. Alongside this, there was also the agreement to provide LL with detailed API documentation, walkthroughs, testing plans, scenarios, and scripts - ensuring a structured and informed integration process.