Add RLV Support #3715
Replies: 20 comments 3 replies
-
|
This issue has been linked to a Canny post: Add RLV Support 🎉 |
Beta Was this translation helpful? Give feedback.
-
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:
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.
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! 😊 |
Beta Was this translation helpful? Give feedback.
-
|
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.
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
Re-emphasizing, and I'll edit the issue to be more clear. |
Beta Was this translation helpful? Give feedback.
-
|
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.
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 |
Beta Was this translation helpful? Give feedback.
-
|
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.
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 |
Beta Was this translation helpful? Give feedback.
-
|
Considering that RLVa is mostly extensions and additions, it shouldn't be too much of an issue. Also Also, 90% of SL userbase is in Firestorm, so RLVa is used a lot more. (The 90% figure was mentioned by Philip Linden during one of the CCUG meetings). So it would make sense of using RLVa as the standard for LL. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
https://www.urbandictionary.com/define.php?term=lindened The "Lindened tree" has been well watered. It took this long because it took me several outreach attempts over the course of 2 years to make Linden aware that Catznip (Kitty and I) were interested in submitting RLVa to LL .. I had to harass a few Linden and no one was really interested till some internal guidance was changed, and even then we had trouble getting staff to really appreciate how big project this is and why a giant single pull request wasn't going to work out. This is the single biggest code contribution ever offered and touches almost every part of the viewer. There is a requirement to understand what it does, the intent behind that, the use cases that enables, and commitment to maintain that going forward. |
Beta Was this translation helpful? Give feedback.
-
|
I’m gonna pop in here for a moment to address a few things. The overall theme around communication is one I appreciate. The most I can talk about there in terms of LL’s interactions with @KittyBarnett is people know they happened. That’s literally it. I know that this is an intensely disappointing clarification as to what we’re aware of when it comes to the overall implementation of RLVa, what the plan was, etc. a lot of what I’m reading here is news to me. A lot of that can be chalked up to it simply wasn’t my job to be in the loop on this previously, so I wasn’t aware of the plan. Signal is in a similar situation. This all feeds into @bennettgoble’s point about making this public. Generally, as it pertains to open source efforts, we are reevaluating what really needs to be kept private vs public communication. Previously there was a sense of keeping some things private and closely guarded in ways that just didn’t really seem to make the most sense. Rather than letting that practice continue, we’re making efforts to have generally open source discussion happen, well, in the open. This includes discussion around how we should have different features architected in the viewer- a great part of this discussion has been better understanding what @KittyBarnett’s plan is in terms of getting this upstreamed. Regarding the idea behind RLVa being in the viewer, what our plans are, etc- as Signal has indicated, we’re really just interested in making sure everything is spec compatible as much as possible. The ideal would be RLVa straight up- but we’re really going to let this be an effort directed by the likes of @KittyBarnett and @0xc0ffea as that’s their work. They understand the inner workings of it, and currently maintain it (even for other viewers from time to time) best. RLV, in any capacity, touches a lot of parts of the viewer that can be complicated to maintain long term without careful consideration. We’ll likely be on tap to provide feedback on how to better integrate with different parts of the viewer and overall architectural guidance. Perhaps some nudging of the implementation to better fit into different parts of the viewer - but these should really be functionally the same to the end user given the content surface at play here (which from experience- is absolutely massive). When it comes to overall decision making- we’re not looking to control the RLV specification or making any sort of unilateral changes to the expected behavior of RLV. The way I see it- it’s not our place to start doing that given the wealth of content that we risk breaking in the process. This is a community driven feature, and so decision making should stay with the community. We may, of course, want to discuss the addition of features but that’s something that should be raised for feedback and discussion here. |
Beta Was this translation helpful? Give feedback.
-
|
Given what @Geenz has just said, it seems to me that the hundreds of hours of work @KittyBarnett mentioned are pretty secure. It's really gratifying to see the Lab ready to engage with the community development effort on big undertakings like this. Assuming the Lab really does understand what it's getting into, let's focus on the other sticking point—the Safe Mode proposal, and who it is aimed at. In short, I believe the best way forward is to implement the same RLVa experience as it currently appears in TPVs (cleanup notwithstanding), but to continue working on various iterations of a Safe Mode framework as a subsequent feature release. What if we don't?In particular, we should examine the consequences of not implementing any sort of Safe Mode—who would be harmed by RLVa landing today, without any changes? First, as @beqjanus mentioned, there are people who will not be happy with RLV-API support arriving in the official viewer. There is a lot of history to this—there was once a nasty little thing called XtremeRLV that held users' passwords hostage, for example. Unfortunately these people do exist and will probably balk at the appearance of RLV in the main viewer, even though they aren't being expected to use it. As far as I know, they fall into a few different categories:
Of course, the purpose of Safe Mode isn't to placate these groups; rather, it is for on-boarding new users with no pre-existing opinions, and to realise RLVa's potential as a client scripting API. There is a non-zero occurrence rate of newbies turning on RLVa in Firestorm (because someone told them to), not understanding what it does, and having a bad time as a result. However, these are currently vanishingly rare. In ten years and a little over 13,000 customers, my partner and I have encountered exactly two people in total who have had such a terrible reaction to our RLVa-based products that they wanted a refund—that's 0.015% of the total customer base where the absence of Safe Mode protections could have (verifiably) improved our conversion rate. If anyone else has statistics on instances of confused newbies who would actually benefit from the enhanced safety in the Safe Mode proposal, it would be highly illuminating. I will grant that since our products are specifically targeted at a niche community (we make collar-like products with a humanoid robot theme) the numbers may not be representative of the user base at large, especially when considering those who do not use TPVs. However, since TPV usage is so high, it is probably arguable that SL already has a tendency to retain users who are, if not technically-minded, at least more determined to engage with the technology than the average casual smartphone user. As it stands—although I am a big proponent of Safe Mode in general—it seems to me that it is not as urgent as bringing the official viewer to feature parity with what the major TPVs currently offer. Perhaps it is gauche of me to point it out, but the reason we're having this conversation is that the Lab was caught in a compromising position last year when (among other things) the TPV rollout of PBR went poorly. It caused serious executive-level panic over declining login numbers and economic indicators. The point of this endeavour is to protect SL from anything similar from happening again in the future. With that in mind, and with little evidence existing for the necessity of Safe Mode at this time, I would rather see @KittyBarnett save her (precious, valuable, admirable) energy until a second pass can be made. Designing a low-risk Safe Mode(By "low-risk" I mean "unlikely to cause anyone to get burned.") I believe wholeheartedly that a compromise can be attained that doesn't impact the hardcore users that @0xc0ffea outlined—perhaps as follows:
The key theme here is that the whole process happens gradually, over the course of multiple stages, and it creates a dialogue with the market via an MVP (minimum viable product) version of Safe Mode before effort is sunk into building the accompanying cathedral. |
Beta Was this translation helpful? Give feedback.
-
|
We provide Kokua in three variants for every release
Any variant can be installed over any other so if a FTRLV user wants to log in without RLV they can overwrite the installation with NORLV or the switchable RLV version (or just go to another viewer temporarily that has no RLV or has it turned off). Looking at our downloads, about 1 in 5 is NORLV, another 1 in 5 is FTRLV with the remaining 3 in 5 opting for the RLV switchable version. Given that migrating to a TPV is something that a tech-savvy person would choose I think it's significant that around 20% choose to have no RLV at all rather than have it there and turned off. This may perhaps be a little inflated - it's possible that NORLV attracts some RLV-averse users from other TPVs that only issue a switchable RLV version. On the other hand, we position Kokua as a RLV-friendly viewer so this may cancel out the NORLV factor. |
Beta Was this translation helpful? Give feedback.
-
l'm not outlining hardcore users or focusing on their interests. The premise of the entire platform is that it's either on, or it's not. We have thousands of products developed with this core assumption in mind, the majority while adult, can't be automatically considered "hardcore". Even a simple interstitial "this attachment is wishing to use RLVa, allow yes/no" breaks products. @Version checking is typically done with a time out and once failed, the script will fall over. There is no rechecking as the binary nature of the platform is considered immutable. |
Beta Was this translation helpful? Give feedback.
-
|
And indeed, that checking often happens during login before the viewer logged-in UI is available. Most worn RLV items are usually up and running by the time that the user sees the world view. |
Beta Was this translation helpful? Give feedback.
-
While it wouldn't help existing content; if the labs wanted to make a switchable without relog RLV then, for exactly the reasons, described they could make that work with, say, an addition to the changed event handler with a new constant CHANGED_RLV_STATE or some other way of signalling that things are different. |
Beta Was this translation helpful? Give feedback.
-
|
There is another aspect of RLV which has been barely mentioned so far - RLV relays. A RLV relay consists of script(s) in an attachment which listen to a specified channel for RLV commands intended for the wearer and, subject to some degree of validation, passes them onto the viewer by issuing RLV commands using llOwnerSay. A relay might be a standalone attachment or provided as extra functionality in an item for another purpose. This is necessary because inworld objects or attachments on another avatar cannot use llOwnerSay to send RLV commands since they would go to their owner rather than the intended avatar. The RLV Relay specification is here: https://wiki.secondlife.com/wiki/LSL_Protocol/Restrained_Love_Relay/Specification Most modern relays can broker multiple sessions in parallel. As well as brokering RLV commands the relay also remembers what it has sessions with and after a relog will check if they are still there and prompt them to confirm they still have an interest in the RLV user as well as reapplying the RLV commands that were in effect previously if the presence of the session originator has been reconfirmed (persistent commands only, ie =n - one-shot commands that use =force are not replayed with the exception of restoring the avatar to sitting on an object). Supporting multiple clients has some design challenges that a relay has handle. In general two approaches have been used
Until now relay functionality could not be migrated into the viewer because the viewer does not have the ability to listen on specific channels and the server does not know to give the RLV relay channel any special treatment. There's an opportunity here to implement a relay in the viewer, however there are some gotchas and principles that would need to be followed
|
Beta Was this translation helpful? Give feedback.
-
|
Satomi Ahn and I were, I think, the first people to release relays handling multiple clients. I took the linked prim approach and Satomi, in her first relay took the tally-based approach. Oddly, and I can't remember the specific situation (maybe to do with tp restrictions and @tpto), we had a case where Satomi's relay was out of spec but had desirable behavior and my relay was in spec but less desirable behavior. I'm a fan of the linked prim approach as it allows the viewer to handle all the interactions between different restrictions. I'd be delighted to not have to continue to support a relay but I think your list of principles and gotchas make adding relay functionality into the viewer close to a non-starter. |
Beta Was this translation helpful? Give feedback.
-
|
It's good to see some reassurances from @Geenz that there's no intention to mess around with the spec. Puts OpenCollar Lead Developer hat on Dealing with a few minor implementation differences between RLV and RLVa isn't much of an issue, but any significant variation from what's already there that would require a major refactoring of tens of thousands of lines of open source code maintained by a small handful of people in their spare time, frankly that ain't happening. An RLV implementation that doesn't work with the de facto universal RLV device in SL would be foolish to say the least. That way, Nelson Munce style pointing and laughing at LL happens. On the subject of safe modes etc. I think it's important to understand the role of user education. People who don't use RLV often just don't understand or have been misinformed about the implications, and vastly over-estimate the risks it entails. For example @ChorazinAllen tells us that 1 in 5 downloads of Kokua are the "noRLV" version. Why would anyone bother? RLV is not active by default; you have to chose to switch it on before it does anything at all - I'm sure that the vast majority of that 20% are people who just don't realise that. Likewise there are many people who don't understand that even if you have RLV switched on, only your own objects can actually do anything with it. The function of an RLV relay is to relay commands from another object not owned by you to one that you do own, so that it can issue RLV commands. If you don't wear a relay, an RLV trap will do absolutely nothing to you. @0xc0ffea raises the point that even a permission dialog per object would break a lot of content. I suppose you could get around that with a preference setting to auto-accept that particular permission request, but this feels rather pointless. It's something that can and frequently is done on a device basis anyway. For example OpenCollar has a button to turn RLV functions off if you want to only use the non-RLV features, and typically a relay will have an ask mode that asks you every time a new source attempts to send a command to that relay. While it might have the potential to remove a griefing vector the reality is that most people would just click that auto-accept thing anyway to curtail the annoyance and content-breaking, so it would be of minimal value - and honestly there's very little of that kind of RLV griefing going on because it's of very limited use and extremely easy to circumvent anyway. OpenCollar's support group has a hundred thousand RLV users in it and I honestly cannot remember the last time anyone mentioned coming across a "hostile" RLV device. However it could be an option to provide a safe mode with limited functionality. This could be done without breaking content by simply implementing an "@versionevennewer" command that returns capability as well as versioning info. The issue I'd raise here is that there is no very clear distinction between commands that are "safe" and those that are not. At first thought someone might say that inventory commands for wardrobe management should be classed as safe because that allows for wardrobe functionality, but commands that restrict communications shouldn't. On the other hand that would mean that someone in safe mode can still be stripped naked, while conversely the "AaarrrrLV Talk Like A Pirate Day Pirate Hat" I made that doesn't restrict the wearer in any way but does convert everything they say in local chat into pirate speech wouldn't function in Safe Mode. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
Considerations
Steps
(Some of these may have already been completed, as we have been working on integrating RLV for some time)
Acceptance criteria
References
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.
Beta Was this translation helpful? Give feedback.
All reactions