Jump to content

llRequestAgenData(uuid,DATA_ONLINE) changes resulting from Privacy Policy


WhiteStar Magic
 Share

You are about to reply to a thread that has been inactive for 4390 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

This is in Refrerence to an older JIRA which has come back to life due to TPV Policy Change and the use of "DATA_ONLINE" with regards to avatar privacy.

To respect the wishes of Oz Linden this post is started here.

From that Jira https://jira.secondlife.com/browse/SVC-4823

QUOTE

"Oz Linden added a comment  - 29/Feb/12 8:52 PM

Ideally, we would like to adjust things so that it's possible for scripted object deliveries to be reliable even when the recipient is off line, removing the need for this check altogether. 

However, it's too soon for us to be talking about possible approaches; watch the Forum (and let's not use this issue as one)."

END-QUOTE

 

Link to comment
Share on other sites

Within that Jira I offered a solutionm which hopefully LL will consider...  I know... don't say it. LOL but I'll post it here for others to see as well.  Hopefully this will stimulate discussion as to viable & workable solutions.

My Suggestion

Why not simply correct the ONLINE response so that it honours the users choice of "show online status (true/false)" setting.   So if a user has elected not to show their online status, OFFLINE is returned, if they elect to show their online status then return the Actual Status.  Often the KISS principle being applied is the wisest, simplest & most efficient solution.

BENEFITS:

  • It would not break existing content.
  • Does not require the Script Owner / Script Creator validation check.
  • It would not be in violation of Privacy, as a user independently selects whether or not they wish their online status available.   (almost all forums software, social sites systems, group-ware system use exactly this process and is a globally accepted practise)
  • Would reduce the Tylenol Consumption required by LL Staff to deal with the fallout & resulting breakages/issues/complaints.

CAVEAT ! - The only caveat would be vendors / updater's which check a users status prior to delivering an item.  These system owners would need to inform the end user that "if" they have their Online Status Display set not show, they would have to manually get updates or whatever arrangement is devised.  This is "inconvenient" but not an outright breakage.

EDIT:  A mention was made about the overhead of validating online-status-show.  Well... one check is less overhead than checking Script-Owner & Script-Creator & Online-Status if passes previous 2 tests.  As I have been programming core systems since the ... well too many decades... maybe I just use the "old math" and not the "new-math" when looking at systems.

Seriously, KISS the issue and get back to Keeping It Simple S*.

 

 

Link to comment
Share on other sites

Any proposed solution to respect this BAD policy change overlooks the fact that there is a LOT of content out there to which there will be no updates, and no way for the users to fix when it is broken.

No, I think the entire policy needs to be reconsidered. It is FAR too late to try to put the genie back into the bottle.

Link to comment
Share on other sites

During the voice meeting, Oz mentioned: "For performance reasons, there's no good way to make that part of the code respect privacy settings." So keeping it simple does not seem to an option...

Which led me to suggest two "opt-in based" possible alternatives.

Link to comment
Share on other sites

  • Lindens

I believe Oz was hoping to stem the tide of armchair development on how we should fix it. It is far more valuable to us to hear how it is used. Hence why in what you bolded: "it's too soon for us to be talking about possible approaches".

That said, using the existing flag for 'can everyone see my presence' is a very popular suggestion that I would like to briefly touch upon.

I want to assure everyone that I have *absolutely* investigated that possibility. I think it has some significant downsides in the aspects of code complexity, expectations and usability.

  • Code complexity: It is unfortunate this this flag is really not in the right place to easily use and would require significant code refactoring - while probably a good thing to do it would require significant effort for development and testing beyond what you would naively expect.
  • Expectations: It has never been expected that this flag would control online visibility to scripts and while it might be reasonable to extend it's features in this way changing the meaning of any long-standing feature should be undertaken with great care.
  • Usability: it would be quite reasonable to only want scripts to have access, or only some scripts, or no scripts while still allowing profiles to show online status- none of which would be possible if re-using this flag. Even then it doesn't solve the very significant problem of item delivery and several other mentioned needs.

In short: we are aware of that flag as an option and it is under consideration but is not as clearly an ideal solution as it may first appear to be.

  • Like 1
Link to comment
Share on other sites

Thanks, Kelly.    While I'm very pleased to learn from Oz's reply in the jira that "we would like to adjust things so that it's possible for scripted object deliveries to be reliable even when the recipient is off line," certainly I would like sometimes to be able to continue to deliver things when I know the recipient is online.    I have in mind, particularly, notecards that I'm sending out via a subscriber or list rather than through a group announcement, in the way Zanara Zenovka's PostMaster system does it.

That's got advantages at both ends -- I don't have to worry so much about running into the llGiveInventory throttle, no matter how adjusted, and, as a merchant, I would certainly rather have people receive announcements about new items, updates and promotions soon after they log in, rather than have them delivered offline, because I know they're far more likely to get read that way.    It also means I can stop trying to deliver stuff after the event is over, and I can periodically prune my lists, so I'm not clogging up the system trying to send out annoucements to people who never seem to log in any more.

 

Link to comment
Share on other sites

The problem has really arose from trying to kill two birds with one stone, which is often appealing but in this case falls a little short of being ideal. Your proposal is a good one that addresses both issue to a degree, although what the original Jira really asks for is a new function to login invisibly, like you get with Yahoo Messenger and I can remember doing with ICQ back in the 90's.

As Kelly points out it would take some major coding overhaul to achieve the desired results I'd suggest the best way forward for now is for LL to keep the scripted funcion but make sure the TPV policy is enforced, TPV's don't need to show true online status as part of the client.

Link to comment
Share on other sites

If it's changed for scripts I am going to have to rework my vendor system I am trying to finish.  as it stands currently right now I am having to put it on hold to await to see what the lab is going to do.  so awaiting is what I will do.

To edit this a bit,  the bridge firestorm or phoenix uses, I get and understand, that's not going to effect how my system works.

Link to comment
Share on other sites

A bounce protocol seems to me the first thing needed by any sensible communication system; whether it is about deliveries or instant messages. I made a(n) (unfortunately angry) JIRA about lack of such protocols a long time ago... after all this is basic 101 in electronic communication.

I still can't believe that communication sent to someone, can go to "dev/null", due to a cap (fair enough) but without proper due bounce errors for failed delivery? Thinking about it makes me bang my head again...

Link to comment
Share on other sites

I understand your point. It is reasonable.

As a user receiving lots of subscriptions and IM's, I deal with all my 'received' as soon as I get on. Note cards and stuff may get minimized until I get to them. I don't care very much when you send them. I just want to get the ones I subscribed to. If they can fix delivery, I would not think it makes a difference when it is sent, as long as I get it.

When I am in-world and playing in a game or busy, arrival of more stuff gets annoying. At some point I can get annoyed enough I just delete stuff rather than deal with it.

Those playing in combay games can get really annoyed when things arrive during a battle. TPV's with the ability to control all aspects of delivery, toasts, and IM's are popular with the comabt and RP crowd.

Link to comment
Share on other sites

As was referenced in the JIRA recently, if the issue was in part about too much load, disallowing TPVs from using this will reduce that load immensely (eventually, anyway) and allow the legitimate uses to continue without constant stress.  

Breaking the script was not the solution, disallowing TPVS from including it in their newer viewers definitely was - just because the possibility to see true online status exists doesn't mean every single person using a certain viewer should have auto-blatant-access to it.

I imagine LL knows that many users will continue to use older versions of TPVs, and that is why they proposed breaking the entire functionality.  But I am very happy to see that they have realized that approach was too heavy-handed.

Link to comment
Share on other sites

Good to see some comments on the thoughts behind it.

To add my 2 L$ here:

"Code complexity: It is unfortunate this this flag is really not in the right place to easily use and would require significant code refactoring - while probably a good thing to do it would require significant effort for development and testing beyond what you would naively expect."
That's unfortunate, but just the way things are. Nothing much to really comment on that.

Expectations: It has never been expected that this flag would control online visibility to scripts and while it might be reasonable to extend it's features in this way changing the meaning of any long-standing feature should be undertaken with great care.
I'd argue that it is fully reasonable that an option to "Hide online status" hides your online status, and that any other interpretation is what breaks expectations. As for changing the meaning of a long-standing feature... well, the whole issue here exploded exactly because it will be changed, one way or another.

Usability: it would be quite reasonable to only want scripts to have access, or only some scripts, or no scripts while still allowing profiles to show online status- none of which would be possible if re-using this flag.
In theory. I am skeptical about the practical use. Few people would be able to make informed choices about such a fine-grained control system. (And as a side note, keying it to some entirely unrelated rule about original script creator was an utterly baffling design choice which really, really needed to be scrapped).

I have a hard time seeing any other option than to bite the bullet and do the refactoring to actually support the flag. Think of it as what you need to document to a new user. You really, really don't want to write a complicated series of rules and descriptions of ways the choice can and will be circumvented if certain criterias which a new person know nothing about has not been observed from day one.

Link to comment
Share on other sites

Would it be possible to make a new LSL function which would be just a wrapper for llRequestAgentData() ? This function would consider OP-suggested flag and nothing else in deciding whether or not to call llRequestAgentData() or return false.

Link to comment
Share on other sites

Well in my honest opinion you should also think about the positive effect of breaking the ability of vendors to view my online status.

Most of the messages I get from automated vendors ARE SPAM, I've never requested those 'news about products', I've never signed anything, I've never ticked a checkbox and I've never clicked ['YES'] on a dialog where I was asked whether I'd like to be informed about new product updates.

Please kill it!

I get this kind of spam twice a week at least, a few minutes or seconds  after logging in. I don't need those!

But since there are a lot of other positive usages of REQUEST_DATA_ONLINE, you should please just put a BIG throttle on it, so that one Resident can only request say 3 DATA_ONLINE-states per minute.

(But without the possibility to distribute the requests over some ALT avatars or over more vendors or sims to circumvent the throttle)!!!!

Link to comment
Share on other sites

I think you may be confusing automated vendors -- which, if you are sending items as gifts, need to check the recipient's online status because, if the recipient is offline, there's a danger his or her messages have been capped, which means inventory offers don't get through -- with subscribeomatics.      

As to unsolicited messages, I don't doubt what you say, but I would point out that most systems are separate from vendor systems and that many of them charge a monthly fee based on the number of people on the list, so there's a disincentive to put pay to have someone on it who hasn't asked to be.    And certainly people's memories sometimes play tricks on them; the only way you get anything from my business partner's mailer is if you've either joined her update group or you've used a subscribeomatic to elect to receive notices, but, nevertheless, every time she sends anything out,  she gets complaints from people that they're receiving unsolicited spam.    When she takes them off the list, she always tells them when and where they used the subscribeomatic to elect to receive messages, and only then they remember.   

Link to comment
Share on other sites

I have designed scripts for several clients with help centers. Each will summon a volunteer when someone clicks the device, checking first to see that the volunteer is actually in world.  The script that keeps track of volunteer availability in the SL library I work with depends on DATA_ONLINE, for example. I suspect that there are many  thousands of scripted devices like that being used by faculty, shopkeepers, counselors, librarians, and others all over SL.  Removing them from service will put a big dent in their availability to provide service.

Link to comment
Share on other sites

I know it's not the right thread for that kind of thing, but anyway:

I appreciate the clarification on why the online status flag cannot be used the way that would appear logical to programmers. I'd guess additional "proper" useable flags might be logical, but not necessarily feasible either.

So far I've heard a few very specific use cases where the changes break existing content. Some are no-brainers, others are not.

#1: Delivering updates. No-brainer. Put an update check script into the product OR provide a rezzable update-checker. I'd prefer the script in the product, but that might not always be feasible.

#2: Staff online: No-brainer. Give a simple object to staff members that they have to wear when on-duty and just implement a simple message protocol to communicate with it. Alternative approach, already used by some places: Give the staff member a box which they have to rez near the master online status object and communicate with that. Sounds complicated, but is trivial really.

#3: Gift deliveries: That one is trickier. The only way I worked around that so far is by not actually delivering the goods, but delivering a "requester object" and ask people to wear or rez it. As soon as it's rezzed or attached, it contacts the main server and delivers the gift. In a sense it's the old re-delivery terminal idea, except shifted to the recipient. It works, but is kind of a kludge. It'd be possible to re-deliver the object periodically (say, once a day or so) until the time the actual gift has been delivered. There's a few other approaches to this peculiar problem, but they're all either really ugly or hit the servers pretty hard.

IMO, #3 is the only problematic issue. If however direct delivery will be accessible via scripting (with proper limits in place to prevent abuse) there would be an extremely easy way around it.

Btw, because of the issues with accessing the privacy flag there also has to be another fix for online status: Groups.. they should just show the last date, not "online". IMs and such are insofar less problematic as you can see who it comes from, unlike llRequestAgentData which allows silent tracking.

Link to comment
Share on other sites

When making my MPV series vendors I considered checking a gift recipient's on-line status prior to delivery and decided that while it may appear "advanced" it is actually counterproductive. What is a vendor supposed to do if off-line status is returned? There are only 2 things it can do: (a) refuse the gift purchase and refund the money to the payer or (b) store the recipient key and product name and keep checking when the recipient is on-line. Option (a) would only hurt vendor's owner receipts so totally out of question. Option (b) would create more problems than it solves. A vendor would have to keep the above strided list and keep checking on-line statuses. What if meanwhile the merchant replaces products in the vendor? Or what if for whatever reason the merchant disables the vendor altogether? All this could of course be addressed one way or another but adds unnecessary complexity. It is much simpler to send immediately and if a giftee doesn't receive either the giftor or a giftee can always contact for redelivery.

Where the on-line status is really needed is not in vendors but in ad boards and business alarm devices.

Link to comment
Share on other sites

#2 is not trivial at all. Staff members could be in another sim. There is no inter-sim communiations between objects except for email. Object email requires knowledge of objects keys (uuids). As an object key, in difference with an avatar key, is not static and changes with each rez a totally in-world reliable handshake protocol cannot be implemented.

Link to comment
Share on other sites

Expectations: It has never been expected that this flag would control online visibility to scripts and while it might be reasonable to extend it's features in this way changing the meaning of any long-standing feature should be undertaken with great care.

Kelly, while that may be the expectation of long-time users and developers, my anecdotal experience is that everyone is surprised to find it to be true when they discover it.

Perhaps this could be addressed from both viewer and server sides, with the viewer-side switch for the current flag renamed to "only scripts can see my presence" and introduce a new flag for "appear offline" that gets around the code complexity issues.

From a privacy standpoint, I'd like to have the option to:

  • Appear online to everyone (independent of whether I appear in Search)
  • Appear online only to people and objects to whom I've granted permission to see my online status; groups see me as offline; inventory offers, IMs, teleport offers, etc. from people who can't see I'm online are treated as though I'm offline.
  • Appear offline to anyone not in a position to render my avatar; local chat, sensors, etc. work as usual, but anything non-local shows me as offline.

I'd like to be able to set this state prior to logging in, so that I don't appear to go online and then offline immediately.

To get to this ideal state, scripts need a new permission to determine whether they can see my online state. For lots of the legitimate use cases, they need to be able to maintain this permission for an arbitrarilly large number of avatars, so it will probably have to be handled outside of the current permissions system. Could a whitelist version of the block list be implemented to handle this? I'd certainly want the permission to be revokable, and since it only has to be checked if I'm actually online but not appearing so to people, the viewer could handle the query rather than the central database. So...

is_online( avatar ) {

  if ( is_really_online() ) {

    if ( !viewer_says_is_online() ) {

      return FALSE;

    }

    return TRUE;  // Handle legacy Viewers that say WTF when asked

  }

  return FALSE;

}

Link to comment
Share on other sites

#2 is not trivial at all. Staff members could be in another sim. There is no inter-sim communiations between objects except for email. Object email requires knowledge of objects keys (uuids). As an object key, in difference with an avatar key, is not static and changes with each rez a totally in-world reliable handshake protocol cannot be implemented.

Ela, I have a reliable inter-sim inter-object communication setup built for just this sort of use. The worn device registers a HTTP-in URL with the central server (also an in-world object) and receives messages relayed through that central server. It's absolutely doable without having to have the object keys. I've not had it fail once in two years so long as the central server remained rezzed.

Link to comment
Share on other sites

That is exactly right: so long as the central server remained rezzed.

And that is why it is not totally-reliable. True, cases when both communicating objects simultaneously (within the meaning of the protocol) change uuids are rare but it might happen and if it might happen it will happen :)

 

Link to comment
Share on other sites


Ela Talaj wrote:

That is exactly right: 
so long as the central server remained rezzed.

And that is why it is not totally-reliable. True, cases when both communicating objects simultaneously (within the meaning of the protocol) change uuids are rare but it might happen and if it might happen it will happen
:)

 

~shrug~ If you're worried it might be a problem, have the employee rez a sensor somewhere in the same sim you need their online status. I mean, really... it's beyond trivial to get around this with the consent of the person you need to know the online status of. They didn't disable it. They just made it so the person who's being tracked has to own the tracker. In other words, llRequestAgentData(llGetOwner(),DATA_ONLINE) works just fine.

 

 

 

Link to comment
Share on other sites

Reliable or not, it makes a rather simple task significantly more complicated than it is now.  If I have a message board that shows names of a dozen potentially available helpers and needs to indicate which ones are in world and really available, I can get that information now with a simple calls to llRequestAgentData. It's dumb to give up that simplicity and replace it with a system that requires each helper to log in actively (and remember to log out actively when she leaves SL later) and then have the information stored and relayed through an in-world server.  The worst part, though, is that there are thousands of such message boards in SL, all of which will be rendered useless if the DATA_ONLINE functionality disappears.  I can't believe that most of the owners of those boards will be happy about paying for new custom scripts to update them.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4390 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...