#4 - Proposal for allowing specific conditions in which RLVa can be toggled while already logged in #4
Conversation
…toggled while already logged in
KittyBarnett
changed the title
KittyBarnett
changed the title
|
I for one strongly support exploration in this direction! Alchemy has already made the effort to allow freely toggling RLVa functionality at any time without restriction, and while this has caused a very small number of users voicing concern on behalf of certain communities, I have seen it do a far greater deal of good work in dispelling fear and apprehension with RLVa adoption. Some examples include:
It's my belief that adding a parachute ripcord to the RLVa system for all users to freely leverage provides a greater user experience in control of their consent with respect to inworld object control, increases user confidence, improves the developer experience, and shields users from malfunctioning or abusive objects. Edit to add: Since adding the ability to disable RLVa without any obstacle, viewer support resolution time for issues related to RLVa and RLVa integrated items has sharply fallen. End users don't need to stop what they're doing or restart their viewers to troubleshoot their issue they're coming to support with. |
|
@DarlCat - just letting you know that I did read your comment (and thank you for that!), and I actually wrote out a response but upon rereading it felt like I wasn't fairly considering your points so I want to let them soak for a bit longer before I try a response again 🙂 . |
|
Considering the "Full Time RLV" viewers that are out there (where you have to use a different viewer to avoid RLV), there's is an important balance between convenience and functionality. SL being just an application already provides you with an option to revoke consent at any time just by closing the viewer. So I think it is a balance of viewer functionality, convenience and your own willpower and dedication to the roleplay, that together form immersive environment, and I feel like making RLV too easy to disable might be decremental to the level of immersion. A good example would be RLV relays - they tend to have safeword features and also ask/auto modes, that allow the user to decide for themselves on how strict their want their RLV experience to be - by setting their relays to auto or disabling safeword etc. An immediate RLV toggle button basically shortcuts that, by making "safeword" always there. In short, I think Darl raised some good points, but I feel like there are many valid points from the opposite point of view too, and I feel like this is a very very subjective topic. |
|
I'm really not sure that this feature is needed. I like the conditions you're suggesting - specifically that if an attachment has issued an RLV command then you won't be able to use the toggle. But that pretty well precludes ever being able to use the toggle. Scenario 1: user logs in with RLV turned on: Almost every RLV attachment I know issues @Version at a minimum, even if nothing else is issued then they're blocked. Yes, if they detach the item they could turn off RLV but, that'd be (in my case) a whole lot of detaching! Finally, to @DarlCat's point, yes screwing up a script is hugely annoying, but if the script issued RLV commands you'd still have to do the relog. I don't think that this helps with the fear of RLV either - anyone who knows enough to find the toggle would be able to find the preference - if you really want to make RLV less scary add the toggle to the RLVa menu on the tool bar with the "you need to relog" popup |
|
After reading the newer replies here and speaking with several people to help me better reflect on my initial ideas, I now recognize that there are valid arguments against my suggested approach. However, these counterarguments simply offer an alternative perspective rather than invalidating my own. I believe my points stand equal to the opposition, and that there's room for compromise. I envision a middle ground that I believe can satisfy both camps: those who favor the current restart-enforced behavior and those who, like me, prefer having complete control over consent within RLVa. Consider real-life BDSM spaces where responsible play is practiced. When someone signals to stop, the action ceases immediately without inconvenience or delays. In contrast, under the current RLVa setup, revoking consent is subject to various criteria and in some cases may not be entirely within the user's control without shutting down the software. While I realize that some might enjoy that restraint, I find it totally unreasonable. To address these two camps, I propose that RLVa introduce a third mode between "On" and "Off." This new mode, which could be called "Casual" or "Dev mode," would function more in line with the ideal I envision. Moreover, it should be detectable by the API so that creators of hardcore content or games, where strict RLVa enforcement is necessary, can steer users toward the more stringent setting if desired. In this mode, the end user should be able to freely toggle the API and its restrictions off and back on to this "casual" mode without hindrance. While a significant group views RLVa first and foremost as a submission enforcement system, its potential goes far beyond that single use. I believe that supporting the ideals of users who want full control over their experience without the confines of strict consent parameters is a worthy goal. Ultimately the most direct route toward making RLVa less intimidating is allowing everyone to set boundaries that match their comfort levels. I now realize that my earlier stance, insisting on universally stricter consent measures, was too rigid, especially for those who prefer a tighter leash. I believe this third proposed mode offers a clear and balanced solution that could make everyone happy. This might be worthy of its own RFC at this point, I am open to writing one or providing input. I'm also happy to discuss this inworld or elsewhere if not here. |
|
Reposting this post made by Luna on Alchemy Discord, which describes the view of someone who wants a "hardcore" RLVa experience:
Hey, thanks for taking the time to listen to this! I appreciate it. I completely understand the importance of consent, especially in real BDSM relationships. However, this is a virtual world, and many of us explore aspects of BDSM that are much darker or simply not possible in real life. But for some of us, absolute full immersion is what we seek. People using full-time RLV viewers prepare for this. They either:
Login credentials are NOT shared, as that would violate LL TOS. But because* part of the password* is missing, the person cannot escape RLV mode on their own. A fresh installation of the viewer does NOT allow escape. Yes, there is always a risk that this system could be misused.
Why this matters: But once I discovered that RLV can be disabled at any time, everything changed. That’s why I truly believe that Alchemy should have a true Full-Time RLV mode.
But for those of us who want absolute immersion, this would be a game-changer! So my question is: Would it be possible to implement a Full-Time RLV mode that locks RLV permanently once activated? I’d love to hear your thoughts! Thanks again for your time.
As I've mentioned in my previous post, it is a very subjective subjective topic. |
|
It's funny, Darl and Kristy have posted almost completely the opposite of each other. My comments come, largely, from a scripter's viewpoint. For attachments (and this includes the relay), the triggering event that enables all of RLV to work is typically the attach event handler (some may use on_rez, but I think that isn't as valid an event). Any toggling of RLV that doesn't trigger one of these events will break existing content. Or, if not break, make behave unpredictably. An alternative would be to include an @notify trigger, so that a script could detect the change in state of RLV, but that would still be a problem for older products. From a purely selfish, self-interested perspective, I could argue that such behavior might drive people to purchase newer products that can react better to changes in RLV in which case you bet I'd make sure that everything I make would be updated. Bottom line: to avoid unexpected behaviors, if RLV can be toggled mid-session, then there has to be a way to let scripts know. Oh, as I think about it, there could be a new constant: CHANGED_RLV, and then the changed event handler could be used. |
I agree for real-life, as you could be restrained and unable to move away, while with SL you always have an option to just get up and walk away from your PC... or just click the [X] on your viewer window. With options like that being there, and people's physical health not being a factor, I feel like the "inconveniences and delays" replicate some of the factors physical restraints. Also, in those scenarios, in SL, you would expect your sub to actually say (( no )) or (( safeword )) first, and not go for the turn off/relog option. And with disable any time option, it could happen without the dom even knowing, while a relog is quite an obvious indicator of that happening.
I'd rather it was a separate command. Maybe
I could see it working, especially for new items, but there are some annoying things to figure out: backwards compatibility and clear terminology with explanation of the differences between modes - as not to spread the "RLV is scary" confusion.
I'd consider myself somewhere in the middle of the strict vs relaxed. But with the way SL community works, I don't think many people will be looking on github for discussions about this, so we as active participants should make sure to include as many valid views as we can :) And yeah, most products expect that users can log out at any point and attaching to happen while RLVa is either on or off, none of them expect it to change at the time in between. |
Excellent point, I accept that.
To these I've got to ask, what's any different here than if the viewer disconnects? Those scripts keep running but until the agent is destroyed by the simulator, the scripts not getting any RLVa responses nor are their commands being acted upon. If the user makes the choice to disable RLVa during a session, those items becoming powerless and not having further API connectivity is what the target user of this mode would expect. A disclaimer on the middle ground mode when being enabled the first time warning that RLVa enabled inworld content may behave unexpectedly when RLVa is disengaged would cover those bases in my opinion. If a user enables this mode, sees that warning, and proceeds to disable RLVa mid-session and sees their content behaving unexpectedly then they would be more likely to know why. A short wiki article linked on the disclaimer or even the a notification toast that appears any time RLVa is disengaged from this mode could suggest the user re-attach their item(s) with RLVa enabled once again to restore their intended functionality as that would mimic a fresh login with RLVa. My perspective in all of this comes from a few places; providing viewer support, having made scripted items using RLVa in the past, and being a daily user of RLVa for automation purposes. I'm also a tester and collaborator for RLVa based items being made commercially and that work is made much easier with an easily accessible RLVa escape hatch in Alchemy. My personal involvement with kink centered RLVa usage is admittedly near zero. While it's probably not come across the entire time, that is something I do have a respect for and do not want to harm with my suggestions. I appreciate the information that has been shared to better shape my own perspective of the needs and wants of those groups. |
If the viewer disconnects, then any subsequent commands issues by the script will disappear into nothingness as there's no viewer available to receive those commands. No big deal there.
I'd expect, in this case, that the user would receive, in clear, all the RLV commands the item is issuing. Now, that shouldn't be a big deal but some things I use (didn't make) are very noisy and issue a lot of commands, drowning out a lot of what's in chat. In my own case, I try hard to not annoy a user with RLV commands other than the initial commands to test for the existence of RLV.
I'm focused, primarily as a developer of RLV items with a focus on customer usability. |
|
I came to comment on another proposal, but I'll drive by and drop in with my 2 cents here! I strongly agree with DarlCat's idea of a middle casual/debug state for RLVa, in between on and off, that allows turning it off without a relog. Personally I'd use such a mode for development/debugging, and I also see the utility for people who want to "dip their toes in", as it were. Or for people who want RLVa for outfit changers and such, rather than kink purposes. I don't feel strongly about the idea of a notify RLVa command to notify scripts when RLVa is turned off. I personally think it's not worth it, and I don't love the idea of an arms race for RLV products to support new features like that... I think it makes the most sense for users to accept that some RLV products might behave weirdly in this situation. (In almost all cases, simply detaching and reattaching said products would clear the issue, since they'd re-query for RLVa) I do want to note for Chloe that (correct me if I'm wrong...) it's not possible to add a new CHANGED_ event on the viewer side, since scripts are executed serverside. I'm not so sure how I feel about Krsity's idea of being able to permanently lock RLVa to on. I agree that this isn't inherently a security issue, but I feel less comfortable with the implications of how users might manage their passwords to take advantage of such a feature. I think it's a reasonably good idea, with the understanding that it can be circumvented by deleting some file in the viewer's %APPDATA%, and is only a feature to prevent casually turning RLVa off... but I can't endorse users losing control of their own SL password. |
Just to clarity, not my idea, I've just posted on someone else's behalf because they don't use Github: the very fist sentence of that post is:
|
|
Without a signal to the scripts that RLV has been turned off then how could a script that counts online RLV time work? I'm happy to adjust the script to handle such signals, but I need that signal. Otherwise, the following scenario happens. An av logs in with RLV turned on and so the counter detects RLV and starts ticking, then the av turns off RLV - the clock keeps ticking without some form of signal. If I lose a product, it's no big deal to me, but mine can't be the only thing out there counting online RLV time. |
|
I dont understand the fuzz about toggling freely. Whats the difference between end users (AKA us, relogging to reset scripts or remvoe stuff we didnt want such as tf's). Second Life is a social pltform. if you sincerely think its 'cheating' then you by default are in the wrong. Just my two cents. I voted to enable free toggling. It might actually make me see TF sims. Relogging to detach stuff was just annoying. |
|
I'll just add my thoughts here: Changing the functionality of how RLVa is turned off and on will damage some of the existing scripts which will not understand RLV being toggled on/off without the relog. I know many of my scripts would be very spammy and confused if you logged in with RLV on, allowing my scripts to detect RLV is enabled, then if it got shut off, they're going to blast out ownersay's that would not be seen by RLV, nor would the scripts have any way of knowing RLV was ever turned off. I think maintaining the status quo is preferable, especially considering how EASY it is to just toggle a checkbox and restart your viewer. It gives people a short pause 'do I really need to change this?' And that brings me to part two of my issue with changing the status quo: Nearly all scripts I know of do their RLV detecting during login of the user. Once that point is passed and the script fails to get a reply from the viewer's RLV, it will determine RLV is off and won't try again. So as a user, you would STILL need to relog to toggle RLV awareness of scripts. And also it would break tattle-tale features when RLV is turned off unexpectedly and a script wants know that happened, if it's happening real-time, script has no way to see, and tattle on the user. So in summary: It's a bad idea. Many scripts expect RLV detection only at login and would require a relog anyway. There is little to be gained from this change, and much to be broken. |
|
I've been avoiding dealing with this one but here goes...
That can be mitigated in different ways, the safe mode option I'm exploring asks the user for consent (similar to llRequestPermissions) before executing any RLV command for instance. This ensures that if someone wants/needs to enable RLVa for a single use-case they can knowing they'll be prompted for everything else.
You can rez the prim and work on it that way; if you get yourself in a bind then session derender the prim until the restrictions garbage collect and then rerender it again. Or put a touch script in the attachment that issues
If someone feels threatened to the point where safewording or discussion with their (play) partner is no longer an option, having to remove themself from the situation/person involved by logging off isn't the biggest problem and likely just the healthy thing to do. I'd also argue to 'know yourself': use a relay that allows safewording, remain an owner on your own collar and buy restraints that allow you to break out if needed.
See above, if you're in an abusive situation then log off and stay logged off until you emotionally recover. Then log back in with RLV disabled and reset the scripts of everything that need resetting. There's ultimately a 'suspension of disbelief' line as well and historically for RLV that has been set at relog because it's enough of a hurdle to make kink use still feel like a loss of control while still being firmly in control. There is a crowd of people who would prefer never being able to turn RLV off (or to the point of not even being able to use another viewer like we had with XtremRLV) but like the ability to toggle at will that's a step too far in the other extreme. I can see and understand all three sides (loosen it, leave it as-is and tighten it) but at the end of the day that status quo is the original contract that existed and there's no compelling reason to change it for minority use cases. Loosening when RLVa can be enabled/disabled without affecting a script doesn't change that contract in any way, nor would adding a 'safe mode' since scripts still have the option to the shaming thing of hover text and sending object IMs to the keyholder if someone enables that (without needing to be rescripted to know of "safe mode"'s existence) |
At least this "extreme" is grounded in the ethical practice of ongoing consent and doesn't violate any terms of service. I hardly appreciate my ideals being compared to such practices even loosely. I will continue respectfully advocating for change on this front, and speaking with the backing of quite a few people as I came to find out, through the help of a kink-centered community leader's outreach to run a poll this morning. https://strawpoll.com/LVyK26YBQZ0/results I'll be honest and say that as an end user I want to decide how my experience works, not somebody else. If my attachments spam my ownersays if I do so, then so be it. If I have to re-attach them to make them behave again, so be it. Viewers that enable this sort of toggling will continue to exist despite any final decision on this proposal, with or without the support of an enshrined safe-mode option, but without some codified way to signal behavior to scripts in these situations, the overall community experience will be worse. That is why I wanted to reach a compromise but I am disappointed at the lack of consensus here. I appreciate all sides in this matter, I just wish I felt like I also had a seat at the table, something I feel is denied to me due to a difference in how I want to use this API. I see two legitimate sides in this tug-of-war; those that want this change, and those that don't. There are a subset within the ones that don't that want things to go other way, but we know where that discussion goes, thanks to XtremRLV so that's not worth addressing at this moment. I've come as close to my opposing side as I can, granted every concession and covered every potential pitfall possible with my suggestion to reach a compromise short of just giving up and not having an opinion counter to the established norm. I do not want to change the experience for anyone that is happy now, I just want another kind of experience to be possible in parallel. I've talked to everyone who disagrees with me who will listen to me, discussed it with them to the extent of annoying them, but since I've started making compromise and meeting others in the middle nobody has given me a solid reason why it's a bad thing for this to be a parallel type of experience and have some form of support in the specification. |
|
Howdy. im not a coder or anyone of great influence, outside of the RLVa communities i administrate directly, indirectly,and participate in. I've been taking a vote for the last 3 hours. you can find this vote and results here: https://strawpoll.com/LVyK26YBQZ0 the vote is worded simply. my take on the matter is that a previous few, a vocal minority you might say, believe in keeping the relog, out of some sense of "induced sensations" . (trying to keep it pg here aye?) the community of combat users that is steadily growing accustomed to RLVa for use with their gaming systems would also like a shout out on the topic, in favor of a simple painless toggle that doesn't cause undue lag every time someone decided to "stop fighting". likewise the pony users of various unions would like a shout out in favor of the painless toggle. specifically to reduce the lag such that they can carry on with their very time/space/movements sensitive pony games. likewise the administration of rubber kingdom (this one's me) 👋 would like to shout out that the relogging of cheaters has not been impacted by the alchemy viewer's default state of already having it be painless. a few coders of open collar have also expressed a desire for an easier time coding around RLVa. not requiring a relog would help push that ideal along. as of the time of this post, the vote cast at 9:00AM in the eastcoast of the US. these are the results. |
|
And @KittyBarnett - Please don't let yourself feel like you should or even need to avoid this. By all appearances we're both pretty firmly set about this matter, but we both care about making things better in our own way and that's a good thing. I'd be more than happy to chat on the side, and am making this its own comment to keep this olive branch separate from more frustrated tones I expressed in my previous remarks. Those are directed at the situation alone and no individual participant in this discussion. I'd be happy to discuss the supporting reasons we both have for the positions we hold, and would frankly love the opportunity to learn about this "other side" from someone I see and respect as a prominent authority on the topic. If there's the possibly that we come up with ideas together that allow for a compromise along the way that meets the needs and at least most of the wants of everyone then it's all the better in my eyes. All my contact points are on my profile, and if you're interested I encourage use of them; I won't impose myself on your private communications uninvited though as I know life is all too hectic without frustrated people banging on the doors of your IMs. I'm equally happy to keep things here and open if that pleases everybody. |
|
on a Complete and Total Individualistic sidenote.... some of the most powerful bdsm experiences i've lived, have involved tissue paper as the shackles. yea having my will taken is great and all.... but its so much more..... intense... when it's given instead. the easy toggle existing, so easily, kinda felt like that to me. i approve~ |
|
I would suggest three things. First, add preferences that upon enabling RLV in the viewer allow you to choose a disabling policy. If wanting to change this preference to a less restrictive policy, it should follow the same policy as disabling RLV.
Secondly, both for the purpose of user experience, and for better working with newer RLV items: notify RLV items of the change of RLV state. And thirdly: to deal with current scripts out there: if the conditions are met (see above) to disable RLV mid-session, offer the user to detach all attachments that has made use of RLV calls during the session (*), and that are still attached. Better yet, also offer to automatically reattach the items after the disabling of RLV has been completed. This should have a similar effect on the scripts as a relog, and the items coming back on and finding out that RLV is not enabled. (*) Just because a RLV item is not having any restraints currently enabled doesn't mean it's not there for other functionality and expect the RLV functionality to be on throughout its lifetime of being attached, hence the viewer need to keep track of all items that has issued a RLV command of any kind not just base it on active restraints. If an item has changed, for example has had their scripts removed, doesn't really matter, it could still be offered to be reattached by the viewer upon disabling RLV. The above suggestions will not change anything for those that want to keep things as they are, only offer new ways for those that want things to be different for them. I will also add these off-topic but somewhat related suggestions, although not necessarily RLV features as such:
|
|
For those who argue in favour of an "whenever you want" toggle, some follow-up questions:
|
Analogies never really help a discussion along IMO: you're right about responsible play, but communication is actually even easier in SL because even when gagged you can OOC and communicate in an unobstructued way with your play partner. And just like RL, if someothing happens and you're tied down/up, it's up to them to then immediately release you. So by your reasoning, RL play can never be responsible because you certainly cannot unilaterly decide to silently withdraw consent and as a result immediately have your cuffs/bonds magically dissapear and prevent your partner from interacting with you in any way?
It is, and I agree, with the understanding that those users have no interest in the kink uses of RLVa and therefor any use of RLV for that purpose does not need to be supported in that mode to prevent it from just turning into a big cheat mode. |
Ironically, I'm actually one of the people who always refuses to accept an experience popup when visting places. That's my decision and I accept that comes with the tradeoff that I won't be able to visit there if I'm not willing to accept their experience. Why are experiences acceptable to you but RLV isn't? (Edited to add that you could also simply wear a relay that doesn't actually forward commands to the viewer today already and you'd be fine) |
People keep telling me, even in this thread, that if I want casual RLVa-like experiences without the restrictions, that I should just "make my own", but that's missing the point. I don't want to effectively copy and paste RLVa and change a few lines of code, create fragmentation in implementation and expectations, or honestly even harm anybody's fun by advocating for new or different things. I just want to have fun along with everyone else without the extra baggage that doesn't fit my exact use case, and I don't want to create any issues for anyone else in turn. That's why I'm so willing in making this proposed mode a royal PITA to use, being more laborious than just toggling RLVa in the first place at least the first time, before using it freely. If it's about making it hard, and keeping expectations, I don't care if I have to edit settings.xml to edit a hidden from editor value to a magic number just to have this.
Because I can leave an experience at any time with just a click or two, it's relatively painless as they're quite limited in feature scope (sadly)
I cannot communicate with a random RLVa scripted item on the mainland I found while exploring and got too close to when it captures me via my open relay which I can escape from and then attaches TF items to my avatar that impose restrictions I can't escape from. A good 70% of my kink related RLVa experiences go like this, with varying levels of enjoyment and frustration. It's something I don't mind, and can even enjoy, with that escape hatch to leave when I'm through with whatever minigame someone coded up and decided should take at least ten minutes of keymashing to escape from.
I'm not sure what the implication is here, but I don't think I am a big fan if I understand anywhere near correctly. There's a difference between wanting to share control and wanting to give up control yes, but if you draw lines in the sand on individual types of functionality within the API you begin to limit the usefulness and alienate non-kink uses of subsets of the API you deem solely kink. I think that the best way to grant something like this is just flag this kind of mode with the version string so that scripts are aware and can adjust their features accordingly, and notifications of state toggles so that scripts are able to accommodate the change in preference of the user. Adapting to this mode or honoring these notifications would be optional of course, as it's likely the overwhelming majority of content will not be updated if this is enacted, but it's something that game masters and hardcore kink users of RLVa can implement into their creations to address any concerns of "cheating" in any type of play. Even if all content cannot be updated to support these proposed notification mechanisms, the broadcast can still be heard by newer devices purpose-built to handle things like notifying nearby users be they dominants or game admins of a potential cheating issue. Cheating sucks in any context and I don't want to make it easier which is why I make these suggestions. Play or don't. |
|
@DarlCat - thanks for responding to that, I was worried I phrased it too antagonistically but I really do appreciate different points of view and being that detailed helps me a lot ❤️ . That said, while I appreciate everyone wants an experience that is closest to their ideal, decisions like this also need to take everyone else into account. If it's possible to give someone what they want without affecting anyone else then it's clearly an easy decision (aside from the amount of work involved). But things like this discussion do affect everyone who's ideal situation is (very) different and it should also be clear that nothing will ever make everyone happy and often I don't even get to make myself happy with a decision 🙃.
You're braver than me already 😁. I decided a long time ago that I would never (casually) wear a relay, but then I also don't feel compelled to go and visit places that rely on them. Not saying your decision is wrong btw, it's just an illustration of why I do appreciate people sharing their experience because I need viewpoints that differ from my own to keep them in mind.
These are just examples, not decisions btw: if the first RLV command an object issues triggers a consent pop-up, then I'd never have it even respond to |
|
I want everyone to have the closest version of their ideal situation that doesn't involve denying others their own, and I firmly believe there is some middle ground here to be found that leaves everyone mostly where they want to be, if only slightly frustrated they didn't get exactly what their demands are. There is truth in the saying that you can please some of the people all of the time, you can please all of the people some of the time, but you can't please all of the people all of the time. In this matter it's clear one side will be left unhappy, probably both to some degree, but whatever is the most fair is what I think will ultimately be the best path forward for the community as a whole. Like you Kitty, I really want to hear other perspectives, especially those that are completely in opposition to this request, to aid with finding common ground and meaningful compromise that can lead to an actual change people don't lose sleep over. |
I dont understand why you need to deflect to experience. It's not like I used those. Infact, I dont even have any experience with those. I just use RLV as a tool to automate things and if I like it I will stay like that. We're living in 2025. We dont live in 2009 when there was a single rlv viewer. If people 'dedicated' to want it as strict as possible, they should naturally not be feeling the need to make use of it. Your (part) does not apply here when rlv lock on attach which is common on TF sims. |
|
The real issue is that the relay should be used a lot more than it is, even if ownersay is an option when attached i.e. TF content. Relays aren't a means to an end (obtaining full rlva access via ownersay by way of attaching), they're a critical gatekeeper but a lot of content does not look at them that way. Consequently, we're where we are and a lot of content breaks the relay security model either by simply not knowing better, or not caring. |
|
To put it bluntly: It is my right, at any time, to any person, to revoke consent for any adult (or any general) interaction. It is an objective standard that if I can do so, then the technical standard is acceptable, and that if I cannot, it is unacceptable, because it places the viewer's ability to determine my consent as a piece of software above mine. This includes at any given point while logged in; an example is a theoretical case in which any given agent logs into a region and begins using RLVa functions in furniture or objects that I do not wish to interact with. While I respect your right to kink and a desire for bondage and surrender of consent, this viewer is for everyone, and a failure state of "I cannot be locked out of giving consent" yields to "I must be given the right to exercise consent as I choose." Anything else is a violation of consent as established as a social contract and in a number of cases, established case law. That is my only pertinent contribution to this conversation and RLVa systems as they are. |
i love NyxXaos' idea. it seems so gosh darn logical to me. everyone gets the best of all worlds. could even make it a toggle that can only be switched before actually logging on. let everyone choose their own path. example: next example: next example: i cant find a fault with this NyxXaos' idea. it just seems logical.
bit harsh, bit crass, bit too pinpoint. i don't disagree with it though... this one makes me think about the victims of sexual abuse i have in my life and their never ending trepidation about my RLVa use. these folks are the reason why RLV-less toys exist on the market and its a shame that those toggles haven't been more accommodating for them. i know at least one of them that has said "love alchemy. im never switching" in specific reference to it's free toggle.
|
|
random poll update: |
|
While you might think my post is "harsh" or "crass," that's just how it works in practicality to comply with the law and limit liability in social media and online games, and best practices in these industries respect this almost universally except in specific cases, such as Slack, where users are expected to be employees and contact is handled presumably through HR. It establishes indemnity for potential liability regarding harmful interactions. Here's a good practical example that also informs why consent, blocking, and such are shaped the way they are in nearly all online social media spaces and games with social elements: User A has a civil harassment restraining order against User B. User B problematically stalks User A across social media. In Second Life, this includes stalking User A to Adult regions with RLVa functionality specifically because of its known difficulties with competent consent. If the software in any way intentionally makes it impossible to forcibly prevent contact with User B, then it is reasonable to expect the person or company responsible for implementing this feature is party to facilitating the violation of the civil harassment restraining order. It would not create liability if, say, a software engineer didn't realize that the block could be circumvented in a certain way, or User B exploited tools that the developer did not know of to deliberately defeat the system, but intentionally creating a system of forced non-consensual contact inherently creates liability, as the developers have a duty to due diligence for the safety of their users, and abdicating that duty in a way that causes harm is civilly tortious. As stuffy as it may be, the takeaway I'm driving at for above is, while it's totally valid to have a kink for non-consent and I'm absolutely not about kinkshaming anyone, as the developer of the system, whether it may be adult furniture you can just unsit from in SL at any time, RLVa, the viewer at large, the Labs, the primary concern is that consent of contact is always best practice. There's nothing wrong with you yourself imposing restrictions on consent for yourself. As a third party and fundamental facilitator of the system, it is best practice to not provide a facility in which genuine forced non-consensual contact, especially forced non-consensual sexual contact, be a possibility. TL;DR, you can be as non-consensual in your interactions as you want, but as a third party developer, consent as a functionality is paramount. Simply implementing even an "emergency stop" that unsits you and disables RLVa until it's reset would be enough, in my opinion. It's the software equivalent of a safeword and ensures that at any time, if a user decides that the intended partner (or unintended partner) is not respecting their wishes or consent, it can be ended immediately. Another good counterpoint is: Why doesn't RLVa disable the ability to block other SL users or turn off the base UI while captured? This could feasibly play into sexual gratification for a user who fetishizes delegation of control or non-consent. The answer is immediately for the same reasons - and probably that it violates LL's policy, or at least I hope it would. |
I am using RLV for various things, and though I've played with adult stuff in the past it doesn't interest me so much in SL anymore. That said, RLV is a very useful extension of the capabilities of LSL. With RLV my trusted people can help me out of a situation while I'm AFK (a sim shutting down, or them leaving a place to go elsewhere for example). It's also useful for things like wearing or unwearing things, and a bunch of other things with RLV alone or in combination with LSL features. I would certainly love to have even more viewer-side scripting features, without having to depend too much on which viewer I am using. I don't really understand what you're asking about in your second question. It certainly would be cool to have a way to customize what RLV capabilities are available in different "modes", but I can see how that would be breaking stuff so I am not suggesting that. That said, I don't think it would break stuff if you could force an item to reattach with (or without) RLV capabilties, rather than having to set it all on or all off for everything you are or will be wearing during your session (note my suggestion of before, of having enabling and disabling policies set, which this feature could then honor: #4 (comment) ). For the third question, the viewer is the one thing I think you should have full control over, whilst your abilities to control items you wear is limited. You don't typically have insight into how those items work (either because it's closed source, or because you don't understand the code if you can access it), while at the same time you might like some of the features an item has but not others. In any case, you should reasonably be able to decide how the viewer should work. If you want to be playing the "game" of being restrained, with an extra hurdle to get out of those restraints, then it's great that you can opt to do so. Equally, it's great if you can opt to not have that extra hurdle when you're done playing, if that's not something you want. Why can't we let the users choose? I seem to see some arguments having to do with issues like "fair game" in "lifestyle situations", but I think that's more of a morality matter than something that should be enforced by the viewer against the wishes of the user. I mean, I would have no problem at all with the viewer having the option to, say, have a number of hours or days between electing to turn RLV off and then confirming that one wants it off before it goes through with disabling RLV - if it is something that some user wants. On the other side of it are those that just want it off right away, and maybe for a single attachment. We can have both, why have only one? Yes, of course, added complexity means more development effort. But if we then keep the restart requirement for those that wish it, we can also have the off-right-away for those that rather not want to restart to disable RLV. Short answer to the question: I have limited control and insight of the stuff I get, even less so before I purchase it - I do have my viewer though, and should be capable to set it to work the way I want it to (as much as possible). I like RLV a whole lot, as an extension to the capabilities within LSL, and absent viewer-side scripting otherwise. Some features of it I wish I could have without needing to do scripting though, such as making an attachment "sticky" by simply right-clicking the item in my inventory. Some viewers I believe have scripting capabilities ( ? ) but I haven't tried them, I like my current viewer too much - I am hoping for Luau giving us more capabilities in the future, but even at that time I think RLV has a role to play even in my life. |
That’s an interesting perspective: I look forward to seeing your pull request implementing your proposed solution in a way that also respects those with differing views. We can continue the discussion then. 😉 |
|
@NyxXaos - I think I missed your original post, sorry for that.. I'll go over all of them later, this kind of blew up 🙈 .
That's already planned, although likely not in any way that will make anyone here completely happy initially. This discussion has certainly moved far beyond the original proposal which was an impactless improvement but it's useful when considering future incremental steps. In my opinion this still remains a question (or outright demand by some) that things be changed for everyone to appease a definite minority group. That doesn't mean it's not a valid question or concern, but that means the needle will move very slowly and stopping to take stock of how things are received before continuing on (or rolling back).
Also planned, I wrote code for this ~10 years ago, just never finished it for a variety of reasons. I'll dust it of for the submission to LL though.
I think we have a very different idea of what the 'hard core' group is like 🙃 . They're the people who want to stack as many restrictions as possible and who's Second Life is a variety of 'no textures', 'no inventory', 'no names', 'locked down vision sphere', 'no IMs' and whetever else you can imagine. Some have absolutely no way to interact with anyone or anything in SL (e.g. banes). To the point of some even locking down their computer with parental controls so they can't install any other viewer (and why they want a viewer where RLV cannot be disabled). There's very little I can do to really appease them but they're a minority as well and what they want would - to put it mildly - 'inconvenience' literally everyone else, but they are a sliding scale as well and it's important to at least keep them in mind because their PoV is just as valid as anyone else's but most likely they'll always end up on viewers less aimed at the general public.
🤭
Thank you for your answers! ❤️ |
RLVa has added functionality over the years that have added new types of restriction or enabled different kinds of interactions, and some of those could be claimed to be a change for everyone to serve a minority, no? While only some content uses vision spheres for example, does that feature existing within the specification materially change the game for those who don't engage with it? Where does adding a feature, a capability of some kind that is entirely optional to engage with, become "changing things for everyone to appease a minority group" and stop being just incremental improvements and updates to the specification? This whole thing keeps being framed again and again as something that's going to disrupt the community, making waves of upset people because it will change their experience simply by existing but remaining unused, but that's not what is being asked for in the slightest. If that were the actual impact of the evolved request I myself would say no at this point, but it's not how I see this going if acted upon due to the compromises that have been discussed, and I sincerely do not understand why it's being treated as such; somebody anybody please explain this to me if it's clear I am missing something. |
|
(Even though I'm quoting you, any "you" is just a general one, not @ you specifically)
Here's my perspective: RLVa has been around for about 16 years now and I've gotten poked, prodded, yelled at and asked for an infinite amount of different things and "let me toggle things off at will" is very far down the list. Whenever the topic even comes up the overwhelming feedback is "don't do it". What is around now has worked for that amount of time (and was copied behaviour from Marine's RLV) and was a core piece of what RLV was and is about so I don't see why being cautious about changing that is such a stretch? For the discussion on any of these proposals to be sucessful, you have to able to step out from your own perspective and look at everyone else's as well. And realize that people who give their opinion or feel strongly enough to bring something up or join in the discussion on GitHub here are simply not representantive. In this discussion on GitHub I'm defending the view of the people who feel like they would loose something if they could toggle RLVa at will because they are almost completely absent from the discussion here. In-world my stance is actually the opposite and I have to defend "all of you" because as I said before, both of your viewpoints are valid and need to be considered and because I believe we can ultimately find something better than what's there now. Appreciate that any change has the potential to impact tens of thousands of users, positively or negatively. And I'm certainly not going to know what the vast majority of users really think, and the only way to know is to introduce change slowly and then wait and watch my IMs/JIRAs etc, with the understand that it's still going to be a guess as to whether they're speaking for themselves or are indiciative of a general feeling. While writing this, I actually received a notecard in-world and I asked if I could share it here:
She's hardly the only one who's expressed this to me and for people who can't see that her opinon and concern is just as valid as your own I'd just suggest that maybe this discussion isn't for you? Do by all means state your opinon because it is valid, but nothing is gained from digging in. My hope for opening up the decision making was that other people would also be prepared to put themselves aside and work towards a solution that gives the most people the experience they want and make the best possible accomodations to the ones that fall outside of that. And in this case I personally believe that that involves a lot of guesswork, which to me means: make small iterations and reevaluate along the way. And I appreciate everyone in this discussion who did make interesting suggestions that do take others into account. That said, if you want to 'yell' at me for being overly cautious, feel free 😛 (just make sure your argument is inclusive of everyone and doesn't just happen to support only what you want)... |
Thankfully, I don't really need your permission or a pull request to continue the discussion while rejecting the assertion that consent is a concept that requires the consideration of "differing views." 😉 Anyway, with current polling and viewer development, it looks like common sense implementation of consent is prevailing, so I'm not sure why I'm digging my heels in quite so hard on something beyond the principle of the matter. I suppose people maintaining that "It's important to me that my sexual preferences and personal immersive experience are prioritized over other users' right to consent" is an opinion that I take umbrage with, and thus feel the need to be involved in. I'm grateful that it doesn't appear these "differing views" will have much traction, but there otherwise remains an environment in which consensual non-consent play is still supported and permitted without needlessly endangering others. I've said all I need to say here, so I'll move on now. |
There is no way for anyone except you to interact with RLVa outside of scripted objects. IM queries like @Version to check whether someone has RLV enabled can be disabled, and @list/except to view someone's restrictions list require the user to explicitly allow it (and can be disabled as well). (Temporary objects or experiences can also be prevented from interacting with RLVa as well to prevent unwanted situations) The only way for anyone to interact with you through RLVa is if you decided to wear a scripted attachment, and for even most of those "everyone can access me" isn't how they come out of the box, that's a mode you'd have to explicitly set them to. I'm not responsible for anyone's scripted objects, nor your choices of what you choose to wear or you putting what you're wearing to public mode (or auto-accept on a relay). If that's the kind of kink play you choose to engage in, feel free, you're certainly entitled to it. But realize that you made a deliberate choice to engage in "unsafe" practices where you might end up "stuck". And your solution is simple: turn it off and relog. Your own choice is what put you in that situation, not whether or not it takes a relog to get out. You do have a point when it comes to viewers that don't allow you to disable RLV. Then the viewer is actively preventing a withdrawal of consent and my stance on that has always been very clear that this is not ok and not something I will ever cater to. The danger that can cause does not outweigh those that actively seek that out (and enjoy) and act responsibly. When XtremRLV was around, I made changes to RLVa to ensure that something like that could never happen again, while we pushed LL hard to take a stance against it. |
|
I do think the question of consent / withdrawing consent shouldn't be conflated with the mechanics of how to do so... I mean, you can withdraw consent at any time by quitting the viewer, and if needed go through the process of disabling RLV as it functions today. This is the mechanic of doing so, which requires a certain effort but also certain knowledge if wanting to use the same viewer again when the RLV items worn put back into place the restrictions that you want to withdraw consent for. That's the hard side of the mechanics of withdrawing consent - the soft side is, in applicable circumstances, to communicate with for instance one's "partner in play". And then there's a range of circumstances where there are more alternatives in how to do this, or you're left with but the hard one. TLDR: we can withdraw consent at any time, that X up in the corner (if on Windows) is your ultimate emergency button. Providing a switch next to the login-button to disable or enable RLV makes this process somewhat easier and reduces the need for knowledge. My interest in this is not about the consent matter, my interest is in not having someone else's preferences determine how I use my viewer. "But that's the whole point of RLV!" someone might chime out. Well, no, not as I understand it. RLV gives you the option to let someone (or something) else control your viewer (to an extent). That is then your preference, not someone else's preference. The point is to let someone else drive your car, not to have it stolen while you're in it (though you can play that scenario!). If my preference then is to have a bit of an extra hurdle to disable RLV (to have you stop and think before making the decision?), then all is great as it is. Could even add more hurdles. But if my preference is to switch it on and off at a whim, then that should also be possible for me to do - I might invite you to take turns driving my car on our roadtrip! I believe the suggestions I have given caters to the will of most if not all people, while also gracefully handles current scripted solutions: #4 (comment) - It does not cater to those that might feel cheated by someone who turns off RLV midsession perhaps, but that's a morality matter, and not so much about cheating when everyone knows it's possible. And you always had the way to cheat out of RLV restrictions, it's just made easier for those that wish to have it easier. The (optional) automatic reattaching also gives the RLV scripts the ability to snitch as they come back on and find RLV disabled. |
|
I disagree on this, particilairy the point of it being 'unsafe' if I run with 'public mode' on my gear. Atm I use plugins on my gear allowing me to directly safeword if I want too. I made a lot of avatar mods that involve thjese same items including my own plugins to allow me to safeword.
As I have said, The ability to toggle on/off would simply allow me to revisit kink sims again about TF's.
I myself, should not care about other kinksters that like it extremerlv.
As I have said, if you're into 'extreme rlv restrictions', you do not feel the need to logout in a non rlv viewer or relog with turning it out with firestorm for instance.
I also dont think that people who allow 'parental control' like systems on outside of SL should be a thing. I think if there is anything dangerous, its particilairy [b]that[/b]. You're giving away your IP to people who are effectively strangers on the interwebs.
…________________________________
From: Kitty Barnett
Sent: Thursday, March 13, 2025 04:38
To: KittyBarnett/rlva-proposals
Cc: SavieSIlverfall; Comment
Subject: Re: [KittyBarnett/rlva-proposals] #4 - Proposal for allowing specific conditions in which RLVa can be toggled while already logged in (PR #4)
[KittyBarnett]KittyBarnett left a comment (KittyBarnett/rlva-proposals#4)<#4 (comment)>
@Sonador<https://github.com/Sonador>
Here's a good practical example that also informs why consent, blocking, and such are shaped the way they are in nearly all online social media spaces and games with social elements:
snip
There is no way for anyone except you to interact with RLVa outside of scripted objects. IM queries like @Version<https://github.com/Version> to check whether someone has RLV enabled can be disabled, and @list/except to view someone's restrictions list require the user to explicitly allow it (and can be disabled as well).
The only way for anyone to interact with you through RLVa is if you decided to wear a scripted attachment, and for even most of those "everyone can access me" isn't how they come out of the box, that's a mode you'd have to explicitly set them to.
I'm not responsible for anyone's scripted objects, nor your choices of what you choose to wear or you putting what you're wearing to public mode (or auto-accept on a relay). If that's the kind of kink play you choose to engage in, feel free, you're certainly entitled to it. But realize that you made a deliberate choice to engage in "unsafe" practices where you might end up "stuck". And your solution is simple: turn it off and relog. Your own choice is what put you in that situation, not whether or not it takes a relog to get out.
You do have a point when it comes to viewers that don't allow you to disable RLV. Then the viewer is actively preventing a withdrawal of consent and my stance on that has always been very clear that this is not ok and not something I will ever facilitate. The danger that can cause does not outweigh those that actively seek out (and enjoy) that. When XtremRLV was around, I made changes to RLVa to ensure that something like that could never happen again, while we pushed LL hard to take a stance against it.
—
Reply to this email directly, view it on GitHub<#4 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AM63OMYWMT6TMNO4NGDGXLL2UD4UJAVCNFSM6AAAAABXDHXYHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJZG42TOMRUG4>.
You are receiving this because you commented.
|
i asked marnie to vote x3 i have been pushing that poll nonstop. whether folks agree with me or not, i just want as many RLV/RLVa users to be heard as is possible. "its our thing! we need to be heard!!!" started a whole fire really XD i hit up so many places with that poll.
if we were going with a majority vote, answer is clear. but "clarity in administrative endeavors" is rarely so easy. i think if what ever decision was reached for the official viewer, did not impact every other viewer's ability to do their own thing free of slight or requirements to adhere to the official viewer's implementations, there would be far less emotions involved. it is because "what ever the official viewer deems the standard all others must obey" is why there is an outcry for every individuals way. ultimately i think the numbers on that poll are such that there is no good conscious way to implement either the status quo, or painless toggle. a compromise which allows for both is just going to have to be the case XD i deal in compromises on the daily. its what administrative folk have to do. so i feel kitty on this one. immovable object, meet unstoppable force. we have to decide between two unsavory options all the time. the ultimate smartest choice, is often found in the middle where no one ends up particularly happy, but likewise they don't get particular unhappy about it either. |
|
I do agree, that I think this should be ironed out as an enshrined compromise before Linden Lab takes any form of code ownership over RLVa. I frankly have much more trust in you, Kitty, to get this right than I do Linden Lab. Your efforts to create and maintain this implementation, and especially in supporting every side of this discussion displays a great deal of good faith and decorum. Linden Lab's direction with Second Life is unpredictable even to those with their ear to the ground, and while that can be exciting to some it's also troubling to those that can see where that could go. I have a great level of confidence that the developers at the lab will be able to maintain whatever you contribute to them, and that they will do what they think is right to serve the overall community. Sadly due to experience I anticipate their leadership making far worse decisions than literally anything you can hammer down here and now. I don't trust the lab to care about the niches that you are right now, or be advocate both sides to the other like this. If Linden Lab took over this space tomorrow and said that I get exactly what I first asked for before any compromise, because reasons unknown, that'd leave a lot of people really upset and that's not what I want; that's never what I actually wanted. Likewise if they told me to pound sand, that my crazy idea "breaks too much content", or that they don't think it's something they can commit to or put a timeline on right now as a way to deflect and kick the can down the road, I trust everyone can see how that's two sides of the same stick that we're likely to contend with if this does not get done before Linden Lab's involvement steps up. I hope that a compromise of some kind on how to handle situations in the API regarding hot-disengagement of RLVa as well as under what conditions that should be possible to the end user, i.e. deliberate choices to engage in casual mode rather than locking in as we have now at login, can be reached so that Linden Lab inherits something that will be ultimately more user friendly to all of their residents as well as RLVa's existing audience, on both sides of this issue. I can throw out UX ideas literally all day for things I think could help the other side of this debate feel better about the thought of these changes, but so far to my experience they've generally been unwilling to come to the table or cede any ground at all leaving me unsure what to say or do to actually move forward with respect to them. I don't want to win or lose by default because the other side wants to give up nothing while I'm over here trying my best to lay down as many barriers safeguards and protections to prevent uneasy feelings that I can think of just to carve out the bare minimum niche in this specification for users like myself. To clarify on my experience: When I have asked those that disagree with this idea, the ones who I've had the chance to speak to personally, for their ideas on compromise or feedback on my ideas to ease their discomfort they invariably tell me to either f**k off and make my own API, or just relog it's not that much trouble. I am trying to hear them and form a coherent proposal that honors them, but not one of these people I've been able to speak to has had a single inch of ground they're willing to cede to make others comfortable. I strongly feel if the roles were reversed then my side here would be far kinder to the other, but despite that I am trying my best here. To recap the ideas for compromise backing away from a free-for-all toggle that I've both shared here and elsewhere, to make things about this idea more easily digestible by the other side:
|
|
To add onto the list from @DarlCat — when toggling occurs, devices need some way of being told when RLVa is being shut down, so they can clean up gracefully. I think this is extremely important, even moreso than the ability to actually safeword while the client is running; if an attachment receives it during login from an RLVa-enabled viewer that currently has RLVa disabled, the attachment could then decide to detach right away instead of waiting a minute or more for a timeout. (Perhaps this should be its own proposal.) After reading this conversation, I am honestly finding myself increasingly apathetic to both sides of the debate. There is no solution that respects the rights of all users: Is it not also the right of RLV and RLVa users to choose to give up their freedom? Only the needs an expectations of newbies seems to tip the scale slightly in favor of implementing the escape feature. One observation is that, if the code to disable RLVa is implemented, it can simply be removed from the UI by editing the responsible XML files. The contrary cannot be said if the features are never coded. This is the solution we use in our products to disable safewording. I would also like to reiterate my earlier suggestion (from here) of adding an alternative
Although it would exclude safeword-users from interacting with all existing RLV-API products, this is the polite, responsible way to do backward compatibility, and satisfy Kitty's goal of providing RLVa for other users. |
That's not an addition, it is covered by point number 2 in my list. Zero blame cast for overlooking it, my last post was dense and probably hard to follow in terms of the list.
|
|
To throw my 17½ cents in, adding the option to toggle rlv "at runtime", takes nothing away from people that don't want it, you don't have to use it and if it being their breaks your immersion there WILL be viewers that don't include it, it can be done as people have implied without even recompiling the viewer. You have always been able to relog and break out of rlv, and that was always an arbitrary limitation, and as said, it would be trivial, to remove the option to toggle at runtime for a viewer experience aimed at a more "hardcore" audience. Add to this that many people use rlv not for its restrictions but because it is the only way to achieve certain things in sl, for those users not having toggle is an active disservice as they don't want to be forced into any of this, they just want to have a nice ui for their clothing system, or cool effects for their game. And rlv is their only option for achieving this in many cases, saying that content made for rlv should obey the kink restriction side of it, is a ridiculous demand, while there is no other option. and another option is not something rlv users would want (see my closing paragraph). I would also shy away from calling it "casual" that word has connotations that will be used against it. Maybe
The last point is mostly to cover the mainline viewer. Frankly, rlv without a runtime toggle has no place in the mainline viewer. It is not the sort of functionality you want for average to lukewarm users, Who are just going to end up filling support tickets with why cant I detach this mud kip that boning my face. Hence my suggestion for a "break lock" option. If toggling is an "optional" part of the spec before it is adopted by LL, then it is less likely they would take issue with viewers "removing" functionality from the default viewer. Without the toggle, it would be far better for LL to adopt an alternative, it is not something that would be difficult to produce, especially if it started with a subset, and translated rlv commands to its own standard. Adopting an alternative would come with many benefits, at least as far as LL are concerned
And if that were to happen, you can bet non bdsm focused viewers would see it as good enough and no longer feel the same need to implement rlv the way it is. |
|
Clarification: I was checking my e-mails during a work call and just instantly felt my energy being sapped seeing yet another post that tries to minimize the other side and I'm really tired of having to represent both sides in multiple simultaneous discussions on here, and then in-world, and on Discord and it feels like everyone is just digging themselves in refusing to budge. And really, I just want to RLV lock you all in a room/dungeon (at this point whichever one makes you the least comfortable) and talk to whoever is still alive the next day. It doesn't currently feel like a helpful discussion that's helping me to make decisions and I think I'm starting to realize why LL has the "don't repeat what's already been said" in place. This is probably my own fault for not having a README somewhere. At this pooint, the only thing I'm still interested in is context, and less dictating decisions to me so for instance: "I use RLV primarily for the Wardrobe feature, but I feel uneasy knowing that an unknown attachment could execute unexpected RLV commands without my knowledge or consent. This uncertainty makes me hesitant to accept attachments from others, as I have no way of knowing what they might do once worn. I wish I had more control over which attachments are allowed to execute RLV commands." So if you have problem statements to add, feel free to continue to do so, they are genuinely helpful at providing insight and to check whether a solution covers your issue (and there have been some here, thank you to those who provided those). If you just want to keep stressing that your problem is that 30 seconds to relog is too much effort for you so everyone else should just accomodate, you've been heard, no further details are needed (similarly if you feel that RLV should not accomodate vanilla uses then that's equally unhelpful for the same reasons but that's largely an SL/Discord problem for me to sort through). |
|
<random>Sorry for the accounts I ended up pinging with this discussion, I forgot to `` all the @ commands 😳</random> So maybe I'm just jaded at this point, but I went through the entire discussion top to bottom and the only stated problems seem to have come from @DarlCat, everything else is just proposing solutions without stating what actual problem they are supposed to solve. That really just makes me value their opinion a lot more and makes me want to take the whole conversation private and explore useful compromises and make constructive progress, primarily because that approach has just worked really well for me in the past. But that would defeat the entire purpose of all of this... So here goes:
I do really sympathize with this one, and consider this one very valid since that was actually me starting out. I however, took the time to read up on it and then made an informed decision to turn it on after I felt confident I had an idea of what to expect. Let's imagine the worst case: someone's brand new to RLV, not into loss of control and the person who got them to enable it gives them something that blocks their chat and their IMs, does llTakeControl, They might try to detach things, which won't work. They might try to change into a saved outfit, which won't work. They might try talking in local chat, which will get filtered (and they won't know they can OOC I imagine) and they might IM which would be blocked. They might eventually close the viewer and relog because that usually solves all other problems (but of course RLVa is then still enabled). How do you help them as the viewer? Can you even help them? Why would an at runtime toggle help them when a relog one doesn't? The reaction to close the viewer and relog feels like the most likely outcome? So would a pop-up offering to disable it on the first relog after 'first use' be helpful? (And knowing that users are notorious for always taking the time to read messages)
Can you explain why you can't rez the prim and work on it that way? Or if it needs to be attached, why you can't put an additional 'safeword' script in there to issue a 'clear,detachme=force'?
This has come up, but just as a recap: I'm only concerned with issues that are not the result of an action you knowingly undertook to allow that interaction to happen (e.g. right-click Add/Wear on an RLV object you purchased/received). So the involuntarily things I can think of:
Is there anything I'm missing? Slightly related, I did work out a proposal for a 'permission first' approach in addition to what exists now, so that someone who only ever wants to use RLV for their Wardrobe (as an example) and nothing else would always get a pop-up and then they can simply decline (and there's no need for a toggle if you don't allow things you don't want in the first place).
Skipping 30 seconds of inconvenience cannot be a reason to change a core behaviour that has existed for its entire lifetime in my opinion.
Speaking personally: a few weeks ago I teleported somewhere and stupidly accepted an experience and it attached a relay on auto that then immediately locked me down. I'd forgotten I was on a test build which keeps its own settings so I hadn't turned RLV experiences off. I rolled my eyes since I personally hate this kind of thing and just relogged, twice. No big deal, my fault for one accepting the experience and two for not remembering to set my own settings properly. Why is this too much to ask? You state that you made a choice, knowingly fully it can just mess up due to poor scripting. Why is a relog so utterly impossible to do? Back to more netural: valid point, although it feels like the whole automated scripted RLV experience used to be a lot more popular than it is now? The only time it comes up now is indeed because someone complains when it went wrong, but then it's frustration at the experience, not about needing to relog out? Do you have any thoughts on a way to resolve this without doing a full-blown toggle? You should be able to clear the relay on your own, if you chose a relay where you can't then that was your own choice to make so you should accept that you need to relog. For 'give-to-#RLV' items specifically, I can see potential for a setting to maybe treat them differently. But I personally don't have any idea how that would impact some content so I'd need to ask around for that. |
I re-read my comment and I am guilty of this, along with being more dismissive than i wanted to be. Sorry Kitty SL Experiences can't stop you leaving a sim, rlv can. So my main concern is with rlv possibly going into the main linden viewer experience, not having a toggle will cause headaches for users not accustomed to how this works, and by the transitive relationship of customer problems are LL problems, problems for LL support. And a 'you need to restart' solution isn't really suitable for general use software. It takes me only a couple seconds to reboot my computer, but needing to do that and close and save everything else I was doing, isn't a suitable "Fix" if a piece of software isn't letting me do what I want. Users needing to restart their viewer because something rlv is bothering them or not letting them do something, when they are midway though something else, maybe something that can't be easily resumed, (there are some board games in sl that don't let you rejoin if you leave for instance) is not really a workable solution. And one problem I have actually had, is being unable to adjust a game hud onto my screen correctly, because the edit widget was too far off screen and a locked attachment was preventing me from zooming out my hud far enough in edit mode. (Which I believe is a deliberate and desired feature, to prevent people editing a forced attachment off their screen) I use alchemy though, so i toggled rlv off, moved the game hud and toggled it back on. This is to me, why relog isn't a suitable alternative to a toggle. And making toggle a thing and making it optional before LL adoption is better I think than if LL were to force the issue later. Because I'm 99% certain it will be made toggle-able in the main viewer eventually if it doesn't start out so. @DarlCat mentioned this in part, but not so directly I think. |
|
This is less of a direct response to the request for further user stories and examples, which I hope to hash out later today due to my schedule, and more putting my cards on the table so everyone can see what I'm working with and maybe understand things better down the thread when I'm able to put more hard thought into this rather than rattling off my circumstances
This is the RLV relay that I use, it's the relay module in the Full Array HUD that I mentioned previously, and this is how I have mine configured. I have mine set in trust mode which means "Auto accept Relay prompts from objects your own, parcel owner owns, or is set to parcels group.", this makes experiences as defined by venue owners / staff immersive without making myself vulnerable to sandbox trolls or other such risks. It certainly makes an open relay less scary, and is something more relays should have. The relay I use has a fully functioning safeword system, and other provisions to deal with restrictions it brokers that might make taking advantage of those escape hatches easier, including the ability to disable it remotely via the web. That might all seem very extra, but having options at all rather than not does help. What I and at least one other person mentioned above, and I still want to bring attention to, is that using a relay like this with multiple options to bail out does not protect you. It's an illusion of security. The wide-open hole in this model is that the relay and protocol can be used to effectively obtain a privilege escalation by giving and attaching another item, much like experiences. Once newly attached, an item no longer need abide by the relay broker model and is now fully in control against the wishes of the user. I feel that, ignoring all other stated issues and gripes about RLVa, this break in chain of privilege is enough to justify serious consideration. If this discussion goes nowhere and we're all supposed to trust the specification as it stands today I feel like it's letting us down by not having some form of tracking to be able to allow relays to render anything that happens as a result of their brokered restrictions / actions to be undone if they call for it. Again Kitty, to remind you specifically of your LL-experiences relay story, a great deal of RLV content exists that operates in the same way. Anecdotally this is the most frequent type/genre of RLV content I encounter, and not because I look for it! The end user is not prompted when they're getting trapped that this experience they're about to have will violate the trust they have in their relay, and without technical knowledge they will probably feel powerless and violated. Users are told to trust their relay, that it's how things work, but in truth it's not. This protocol and its usage conventions are old, and there are many footguns for those who want to dip a toe into this vast ocean of content. A bad first experience like what has been described above or this one will drive just about anyone to have an almost insurmountable distrust, since they feel that they were lied to about relays being the safe way to play. |
RLV (as a concept) isn't a piece of software that's intented to be cozy and ply itself to the convenience of the user though, it's the exact opposite of that at its core. Its entire purpose was to make your SL less comfortable, even by virtue of being enabled and not even having anything detach locked back when I started using it on Marine's viewer. The first 'vanilla creep' things that pop into my head that I've gotten 'flack' for over the years:
I've always wanted to push RLV into the mainstream with RLVa, and I think that's worked out quite well and that only happens because the majority of people do not want to 'suffer', especially when it's not even in use. However, there has to be a line somewhere. There is vanilla use of RLV and that was sort of the point as well but realize that you're more an accidental audience than the targetted one. And there's no logic to where I draw the line, which is where outside opinions come in. I'm not set in stone on anything, but realize that the line will only move a bit at a time and that any movement whichever way will mean a bad time for me because people on both sides just really love to complain. And if you're going to try and move the line to the complete opposite end the productive discussion stops and I have to argue for the side you're scoffing, which isn't something I want to be doing either. My joy doesn't come out of arguing on GitHub, but writing code and solving problems and producing things that other people get to then enjoy for whatever it is makes them happy.
You're right, that feature was there (in Marine's RLV even, I just reimplemented it since it made sense) because HUD attachments were the only way to do blindfolds. Things have progressed a bit since then, so I'm not entirely sure whether that still makes sense to have as a limitation (obviously excessively old things could 'break').
Or you fix that specific problem since it might not realistically make sense in today's world of
I agree with sorting out most things before LL does a viewer release with RLV in it. Part of that is also being able to show that it can be community-owned in a civil and respectful way which is why I'm trying to be open (and it's not any less of an "empress in her little ivory tower"-ship at the moment but hopefully it won't always be just me that has to make decisions). |
Currently, RLVa can be toggled on and off at the login screen without requiring a viewer restart. This proposal aims to refine and improve that functionality.