New LSL function proposal. llIsFriend

[Rider Linden]

I'm considering adding the following LSL function and would welcome some community feedback.

Function: integer llIsFriend(key agent_id)

The llIsFriend function will return TRUE if agent_id is a friend of the script owner and either the owner or the agent is in the same region.  If agent_id is not an agent, not a friend, or neither the agent nor the script owner is on the region this function returns FALSE.

(I am also considering adding llIsFiend just to be cruel... it would return TRUE only on Halloween 😉 ) 

[Lucia Nightfire]

Is there going to be an explicit, non-auto-granting permission involved to get this information? As it is sensitive information and despite the convenience with the application mentioned, some users will definitely feel it is no business of anyone, whether land owner, estate owner, estate manager, etc. whom their friends are.

I also see unwanted/inconvenient marketing/profiling exploits with access to this information.

[Rolig Loon]

I can think of situations where that might be handy, but it's not a function I would have requested or one that I would put high on my list of functions I am likely to use a lot.  Nice, but ... who's asking for it?

Personally, I have a friends list that is embarrassingly long, simply because I rarely take time to remove people I haven't thought of for a while.  If I used that function myself, it would probably embarrass me by pinging people I forgot even existed years ago. 

 

[Lucia Nightfire]

I am also bringing up relevant information/concern on this at https://jira.secondlife.com/browse/BUG-230999

[Love Zhaoying]

That means..

integer bFoe = ! llIsFriend(sKey);

[Mollymews]

trying to think of the use cases

if (!isFriend) on my parcel, eject them

if (isFriend) invite them to my private group

if (!isFriend) invite them to my public group

if(isFriend) in my shop. give them friend gift or friend discount

if(isFriend) renting from me, give them friend discount

if (isFriend) in my performance venue, add them to my significant people to greet list

if (isFriend) on my battle arena, don't shoot them  

 

[Love Zhaoying]

24 minutes ago, Rolig Loon said:

Nice, but ... who's asking for it?

Use case: Request friendship until llIsFriend() returns TRUE!

[Lucia Nightfire]

1 hour ago, Mollymews said:

trying to think of the use cases

if (!isFriend) on my parcel, eject them

if (isFriend) invite them to my private group

if (!isFriend) invite them to my public group

if(isFriend) in my shop. give them friend gift or friend discount

if(isFriend) renting from me, give them friend discount

if (isFriend) in my performance venue, add them to my significant people to greet list

if (isFriend) on my battle arena, don't shoot them  

 

I'm aware there are such benefits, but I'm not for access to this information without my explcit permission.

I'm not for attempting to create a new standard where permissionless access should be treated as a new norm.

[Quistess Alpha]

I'm having trouble thinking of many clear-cut ways to abuse this, (you can't use it to quickly log a person's whole friend-list for example) but at the same time, I'm not really seeing any 'must-have' use-cases for it either. I think most of the use-cases would be equally well (or better) served by creating a friend-group, especially since many people on /my/ friends list are far from actually being my friends.

(One of my "friends" even owes me 2k, and (probably) has me blocked. . .)

Edited July 21, 2021 by Quistess Alpha

[Rolig Loon]

7 minutes ago, Quistess Alpha said:

(One of my "friends" even owes me 2k, and (probably) has me blocked. . .)

if ( llIsFriend(llDetectedKey(0)) ) {  // Hide wallet }
else  {  llSay(0, "Can you loan me L$50?"); }

 

[Coffee Pancake]

I have application for this right now, would be super useful for anything where we would normally be maintaining casual access lists.

Nefarious usefulness seems to be  limited , worst idea I could come up with  .. someone writes something we all end up using, quietly building a massive databased web of who's friends with who, brute forced testing of ever single avatar the wearer associates with. gradually collating a copy of the Linden friends database !! (mwhahaha!) To then ???????

Suggest possible friends? Maybe  ... which seems like something any other social network could add and no one would even blink. It would be a tremendous amount of work for junk because that's not how friends work.

 

Friend time tracker - you spend 36% of your time near Bob. This means Bob is your best friend! UtOh! Your Bob time is down 4% on last week ... 

if (isFriend) on my battle arena, DO shoot them   - Guns that only shoot your friends .. that's just fun, and being a good neighbor.

if (isFriend) allow to open the doors in my house - Casually useful

Adult toys .. deny access to people you're not friend with, seems like a no brainer .. (or vice versa if that's your bag).

 

I would be fine with permission-less access. 

 

Edited July 22, 2021 by Coffee Pancake

[Extrude Ragu]

14 hours ago, Rider Linden said:

I'm considering adding the following LSL function and would welcome some community feedback.

Function: integer llIsFriend(key agent_id)

The llIsFriend function will return TRUE if agent_id is a friend of the script owner and either the owner or the agent is in the same region.  If agent_id is not an agent, not a friend, or neither the agent nor the script owner is on the region this function returns FALSE.

(I am also considering adding llIsFiend just to be cruel... it would return TRUE only on Halloween 😉 ) 

I'm curious to know what inspired this idea?

There are privacy concerns that could lead to real social impacts on people. For example, if the function does not require permissions, a user might unwittingly attach or rez a device that allows the creator to know who that users friends are. At it's most extreme, it could lead to social outcasting in sims, in an authoritarian style where you cannot associate with certain people because it will be picked up especially in regions which require you to wear scripted objects such as Experiences.

That's not to say the funciton doesn't have genuine use cases. I could see the function being useful for trust based systems, for example it would allow a resident to configure the front door of their house so that it only opens for the owner or friends of the owner. Would be much more intuitive than a whitelist system. I think there needs to be protections in place against abuse though. It's own unique permission that must be explicitly granted rather than auto-grant for attached objects, and should not be bundled in with Experience systems. Maybe even a policy that sim owners may not force visitors to use the function to 'vet' guests.

[Extrude Ragu]

Actually just realized it would only return true if the friend is also in the region. I guess it would be much harder to use it for nefarious purposes in that case.

Seems like an OK idea to me then

[Extrude Ragu]

No re-read that a second time. You said either the owner or the friend is in the same region. I could only get behind it if requires the friend for privacy regions

Edited July 22, 2021 by Extrude Ragu

[Rider Linden]

After some thought (and gentle prompting)  I think this does require a permissions check.

[Nova Convair]

I don't see much abusive potential, since you can always make a list and check that against avatars if you want to play control freak.

I have a problem to find it useful too. Because I have no "friends" list in SL - I have a "contact" list - that is something completely different.

As long as I can't flag my contacts into subsets and use that with llIsFriend I will most probably not use this feature.

[Quistess Alpha]

An abuse scenario:

Lets say I own a club/(insert other place where people go). and lets also say that club has an experience that people have to accept to use the club.

I have some spat with Bob resident, and I decide I /Really/ dislike him, so I ban him from the club. but that's not enough for me. Because I'm super spiteful I want to ban all his friends from the club as well. So I make an invisible auto-attach object associated with the clubs experience, that attaches to each guest as they arrive, then checks if they are friends with bob, if they are, then ban, else silently detach.

but it gets worse: say Bob's friend Bobend gets flagged by the device. I can use my experience keys to also add Bobend to the list of people whos friends I dislike, so after he comes to the club and gets banned, if his friend Bobenda comes in she's suddenly banned as well and so on.

having llIsFriend() require perms mitigates this a little, but if I'm a /really/ spiteful club-owner I could just assume anyone who isn't cool letting me spy on their friends must be a friend of Bob anyway.

Needless to say the device will also try and build a friendship web diagram of sorts for my amusement and drama . . .

Edited July 22, 2021 by Quistess Alpha

[bobsknief Orsini]

Looks like a good addition to me. Make me think of LLSameGroup.

Don't really see and issues with it. Sure all functions can be abused. And yes, one could use a experience to force attach objects to avatars and then check if they are friends with other avatars that are present. On the other hand, one could also track location, local chat etc using the same technique.

Guess the question would be, is it worth for it not to work on attachments or no? To be honest i think the usefulness of this function outweighs the possible abuse. And the abuse would be limited by a permissions requests, and you kind of want to leave that responsibility to the users themself. Its like, just cause i could post a harmful link on this form doesn't mean LL should remove the link function.

[Nova Convair]

5 hours ago, Quistess Alpha said:

An abuse scenario:

Lets say I own a club/(insert other place where people go). and lets also say that club has an experience that people have to accept to use the club.

I have some spat with Bob resident, and I decide I /Really/ dislike him, so I ban him from the club. but that's not enough for me. Because I'm super spiteful I want to ban all his friends from the club as well. So I make an invisible auto-attach object associated with the clubs experience, that attaches to each guest as they arrive, then checks if they are friends with bob, if they are, then ban, else silently detach.

but it gets worse: say Bob's friend Bobend gets flagged by the device. I can use my experience keys to also add Bobend to the list of people whos friends I dislike, so after he comes to the club and gets banned, if his friend Bobenda comes in she's suddenly banned as well and so on.

having llIsFriend() require perms mitigates this a little, but if I'm a /really/ spiteful club-owner I could just assume anyone who isn't cool letting me spy on their friends must be a friend of Bob anyway.

Needless to say the device will also try and build a friendship web diagram of sorts for my amusement and drama . . .

I don't see the abuse here 😁
I don't have problems with people that quickly want to empty their club and I don't even need to block them since I'm already banned. I say: perfect - do it please 😎
Besides of that I would never enter clubs with a mandantory experience.

A very theoretical construct.

But until now I never saw a reason to deny most experiences since they are easy to kick and weren't able to do harm. (by my definition)
Revealing my contacts is not in my interest though so that's another reason to reject experiences. I'll keep an eye on this.

Edited July 22, 2021 by Nova Convair

[Quistess Alpha]

31 minutes ago, bobsknief Orsini said:

check if they are friends with other avatars that are present.

As I understand the spec as in Rider's OP, only one of the two parties needs to be present for it to work. Another way to mitigate the abuse potential would be to have it on;y work on avatars who are in-region. As I understand it llIsFriend(bob's key); would tell you if the object owner is friends with bob, whether or not bob is in the region. if bob has to be in the region for it to return TRUE, that basically crumbles the "abuse scenario" I put forward in my last post.

[Mollymews]

6 hours ago, Rider Linden said:

After some thought (and gentle prompting)  I think this does require a permissions check.

i think this is a good start toward a script having to ask a second person (who is not the script owner) for permission to obtain what can be considered as the second person's personal information

if build a framework on this principle then it could be extended to other functions like for example llGetObjectDetails of the second person's attachments. Which in turn could then be extended to getting the details of HUD attachments should the wearer agree 

[Profaitchikenz Haiku]

Why not just use the already-available "friend can see if I'm online" tickbox from the profile? If the person has said it's Ok for you to know they're online then it's also ok for your script to check if they're a friend of yours. If they have some privacy concerns and haven't ticked the box then they also don't want your probing their internals vie a bit of LSL.

 

There is of course a teensy problem here, you can use this to determine if a friend of yours has or hasn't ticked that box, but to be honest you can work this out for yourself by seeing if you ever bump into them without having been notified they're online. (Just saying this because if I don't I know somebody(s) who will

[Quistess Alpha]

1 hour ago, Profaitchikenz Haiku said:

Why not just use the already-available "friend can see if I'm online" tickbox from the profile?

Because that would only worsen the rate of spagettification of SL's code. One box, one function please.

[Coffee Pancake]

12 hours ago, Rider Linden said:

After some thought (and gentle prompting)  I think this does require a permissions check.

I disagree. The worst we've been able to dream up has been entirely self defeating and would operate better without this function existing at all.

 

A club owner bans Bob, and then bans all bobs friends at the club. This is based on the assumption that people who attend the same club together are even on each other friend lists, which in my experience simply isn't the case. "Friends" at a club tend to remain in that bubble, they are unlikely to even be actual listed friends, and don't associate outside of that common meeting point. In the rare case where everyone at the club is a fully fledged "SL Friend" of Bob, the club owner just emptied his venue .. an action that wouldn't go unnoticed by people who weren't Bob's "SL Friend". Self defeating.

Marketing schemes work better without knowing who's "SL Friends" with who, spamming everyone is simpler .. which is exactly what we already have. More work with no gain.

A club or business could record bobs friends via some experience attached prim, and then message his known friends when they didn't show up .. again, this is more work than just storing keys of every attendant, requires many extra steps, and would be less effective than just messaging everyone. More work with no gain.

Good luck to the first region owner or business  that bans friends, probably will be one or two that try it, and the wider population will rightly dump them in a heart beat. Self defeating.

Multiregional ban lists could be accomplished right now, and we don't see them in use. Self defeating.

Plotting friendship webs sounds scary .. but it requires a stupid amount of data and could be done without this check (just logging who is seen on a region with who and then adding weighted links would be more effective and can be done without this). Even then .. Someone making something to enable them to be in a position to even attempt this would have an immense amount at stake. They would need a product on the scale of a top tier mesh body, which alone would make the risk reward equation out of the question.  Self defeating.

Any nefarious activity based on this function that operated at scale would be a clear and unambiguous ToS violation.

[Mollymews]

1 hour ago, Coffee Pancake said:

A club owner bans Bob, and then bans all bobs friends at the club

the proposal is that the owner of the script can check if an agent on the region is also on the script owners friends list

for a parcel owner to know who of their patrons are on each others friends list then it requires each patron to wear a IsFriend script which transmits that information to the parcel owner

forcing patron's to wear a script can be done (wear or be ejected) a HUD script for example.  What a patron needs to know is if the script is able to transmit their friend status to a 3rd-party (i.e. the parcel owner/provider of the HUD). Which is the case and is true

so the proposed permission request, which should not be automatically granted just by wearing the HUD  

edit add to clarify, the permission is requested from the target (agent_id) of llIsFriend(key agent_id). Not from the wearer of the script

Edited July 23, 2021 by Mollymews