Script That Allows Purchase From the Demo?

[FairreLilette]

1 hour ago, Rolig Loon said:

Create a HUD with a button that links you directly to the item in the merchant's Marketplace store. Buy the item there.  Let Linden Lab accept the responsibility for handling the money and delivering the product.  

It sounds good except not all seller's have all their products in their Marketplace Store...some have small limited item stores only and some skin stores even you can only buy one shade (tone) of skin on MP.  I don't know why some seller's do that because it's the same money either from MP or an inworld store...it all adds up.  I know why I do it of late (not feeling well enough) to taking all the photos to go on MP as inworld if I just rez the object it's easy to use the rezzed object as a vendor itself.  

Yesterday, I found a hair store I had never heard of.  The MP store only had a few items.  So, I went to their inworld store and found lots and lots and lots of hairs.  It takes me a while to find the one I want to buy inworld by finding the picture again as I usually take anywhere from 10 to 20 demos inworld at a time.  So, it just seemed to me "wouldn't it be great if we could buy it from the demo"...but it sounds like there are some problems with it which I didn't know about and that's too bad because I really think it could improve sales but how...hmmmmmm....it may not work then because of scammers.  That's a terrible reason to lose so many sales possibilities because of potential scammers if I am understanding all that is written in this thread correctly.  It's like letting the bullies (scammers) win because we have no choice as bullies could cheat this system of purchasing from a HUD.  But, there is also the inherent possibility of "system failure" in this as well from my understanding of what's been written in this thread.  

Edited May 3, 2020 by FairreLilette

[Adam Spark]

28 minutes ago, Rolig Loon said:

No, Linden Lab comes down really hard on people who run scams like that, just the way that RL police come down hard on con artists and people who hold up liquor stores.  That doesn't means that people can't find nasty things to do with basic tools and then risk getting caught.. 

Gift cards are good examples of limited liability systems.  When you buy something with them, the L$ doesn't come directly from your account.  Just as in RL, you hold a card that gives you permission to get a limited amount of goods.  You either paid for the card up front or the merchant has simply decided to be a nice guy and give you up to L$500 worth of products by presenting the card.  The card isn't asking you for any more than that, and once you've used up the value of the card, it's worthless.  Fairre's idea for a demo HUD could incorporate something like that too, as a promotional gimmick.  ("Use our demo to try out the product, and we'll discount the price of the final product by giving you a FREE L$50 discount when you click this button.")  It would be a nice way to encourage people to get the demo first.

What I meant by letting scripts get away with it wasn't implying that LL doesn't have ways to deal with it. I meant that it kind of shocks me that the ability to take money from accounts unknowingly after one simple debit click using a timer exists in the system.

Some gift cards do in certain situations - I have use gift cards that become vendors for the item when you click on the in-store vendor. If my balance is less than the cost, I have had the remaining L's taken via debit perms.

[Rolig Loon]

44 minutes ago, Adam Spark said:

What I meant by letting scripts get away with it wasn't implying that LL doesn't have ways to deal with it. I meant that it kind of shocks me that the ability to take money from accounts unknowingly after one simple debit click using a timer exists in the system.

I agree, and I thought that's what you meant.  It's one of those balanced risk situations.  Without some way to request PERMISSION_DEBIT, we'd have no way to create any but the simplest vendor systems in SL, but making that request possible opens up a way for con artists to take advantage of it.  Linden Lab handles the risk in two ways, first by opening that mandatory yellow Warning box whenever a script requests PERMISSION_DEBIT and then by giving the Governance team powers to ban scammers permanently and to recover any stolen funds.  Neither is perfect.  Many people don't read notices. Many don't speak English as a first language.  Many don't appreciate the potential risk. On the enforcement side, the system misses con artists who leave SL before they can be caught.  Still, those are the tools LL has.  Those and vigilance by responsible scripters and alert residents. 

[Adam Spark]

5 minutes ago, Rolig Loon said:

I agree, and I thought that's what you meant.  It's one of those balanced risk situations.  Without some way to request PERMISSION_DEBIT, we'd have no way to create any but the simplest vendor systems in SL, but making that request possible opens up a way for con artists to take advantage of it.  Linden Lab handles the risk in two ways, first by opening that mandatory yellow Warning box whenever a script requests PERMISSION_DEBIT and then by giving the Governance team powers to ban scammers permanently and to recover any stolen funds.  Neither is perfect.  Many people don't read notices. Many don't speak English as a first language.  Many don't appreciate the potential risk. On the enforcement side, the system misses con artists who leave SL before they can be caught.  Still, those are the tools LL has.  Those and vigilance by responsible scripters and alert residents. 

But surely there has to be a way for scripts to only take money when both debit is acknowledged and when a user requests the withdrawal. The fact that debit perms can allow random withdraw amounts to empty a purse surely can be stopped under the hood? But then there is a reason somebody else does these things and not me. It just feels like a loophole LL has resigned itself to not being able to fix - which they are notorious for.

[FairreLilette]

@Rolig Loon 

What about a drop down menu from the HUD demo where the person could write the name of the item they wish to purchase which would register it showhow as a pre-transaction with a number before hitting PAY and then in the nearby window it could give a prompt that is now okay to proceed with purchase (on say a hypothetical HUD purchase demo) to help prevent system failure (i.e. failed deliveries - paying but then getting no goods)?   

I know it's weird to ask a hypothetical but it sure seems like there are a lot of missed sales because it is difficult to go back to the store and find the corresponding picture to buy the item from as I said I usually take lots and lots of demos.   

And, I hate the lag at events...it was lag enough to get the demos...I dread going back to the event and finding the stuff over too which is not easy at all to find each event item that is for sure.  

I'm sad to hear it sounds like this idea has inherent failures and is a no go idea.  

Edited May 3, 2020 by FairreLilette

[Mollymews]

there have been a number of HUDs over the years which act like a little shop. From no-mod objects which contain the for sale items in a prim not the root, to server delivery systems

some of them aggregated specials from different merchants

these kind of systems come and go in SL. Now and again a person will re-invent this and can enjoy some success for a while, because their customers think this is quite cool

after a while the HUD shoppers fall away. HUD shoppers fall away mostly because stuff which has cool as its main selling point over utility tend to be discarded/unused over a while

utility: when we can't fit all the product sale information on the HUD display texture then we either have to use a notecard or a link to a web page

which leads to: if web link then link to market place. Which from a utility pov leads to the merchant's store, which leads to other products for sale by the merchant. Something that both merchant and buyer find to be more useful

[Rolig Loon]

41 minutes ago, FairreLilette said:

I know it's weird to ask a hypothetical but it sure seems like there are a lot of missed sales because it is difficult to go back to the store and find the corresponding picture to buy the item from as I said I usually take lots and lots of demos.   

Yeah, that's a problem, especially at crowded events.  I had an in-world shop (actually a succession of them) for several years, so I have toyed with a range of ideas.  Fortunately, my stuff was never so popular that people had trouble getting back to buy something.  Unfortunately, I never made enough L$ to justify the time it took to maintain the shops, so moved on to other things.  I'm sure that there are all sorts of clever ideas that you could try for making a HUD more versatile and more nimble and for addressing the nuisance of getting back to an in-world store once you have decided to buy something. The basic problem of risk management remains, so I don't see much hope for a safe way to build such a HUD,  at least one that I would feel comfortable using myself. 

Stepping completely back from the issue, I wonder whether we have all become so accustomed to the convenience of on-line shopping that we have become impatient with driving to a store and standing in line -- which was the norm until very recently.  There is quite a lot to say in favor of convenience, but one sad trade-off is that we have opened up issues of security that we never used to deal with.

Edited May 3, 2020 by Rolig Loon

[FairreLilette]

18 hours ago, Chaser Zaks said:

• Have a button to "buy full version" on the hud
• Pop up a dialog explaining the debit permission, as well as a confirmation
• Request debit permissions
• Make payment through LLTransferLindenDollars
• Verify payment through transaction_result
• Send HTTP request to a server somewhere authenticating the payment
• Have the server send out a copy of the full version

I'm not still fully sure "why" it has to be done that way (with permission) when other items don't and I probably never will understand it.  It seems like some can over-ride the protocol or "permission" via vendors and other things inworld such as CasperVend.    

I don't see why a wearable kind of vendor with appropriate transaction markers couldn't be created especially if it were made into a separate purchase HUD along with the demo but, again, I'm not a scripter nor do I know anything about protocols for transactions...it's just simply not all linden transactions need permission so I don't fully understand why this would be different.  It might need two different kinds of purchase HUDS one for inworld and one for MP as a MP one would need to have 10% go to the Lindens for their "percent" *if* this were ever thought an okay way to accomplish a transaction for both buyer and seller.  

But, thanks all for answering nonetheless.    

 

Edited May 3, 2020 by FairreLilette

[Mollymews]

6 minutes ago, FairreLilette said:

it's just simply not all linden transactions need permission so I don't fully understand why this would be different

the difference is that when we pay an object owned by some else then no account debit permission is needed.  We knows who owns the object - the person the money is being paid too - and the amount. We (the payer) can abandon the transaction any time before we commit to the purchase

with a shopping HUD given to me by another person, which pays that person, the script asks me for PERMISSION_DEBIT which I have to accept before I can pay them

http://wiki.secondlife.com/wiki/LlTransferLindenDollars

the security issue is the script in the shopping  HUD provided to me. When we give a script any permission then it retains that permission. We are committed.  There is no way in SL to revoke a permission once granted to a script, other than reset, delete the script, or the script is honest and revokes the permission itself

when the script is No-Modify then the shopper has no way of knowing that the permission_debit script is honest.  A dishonest script when given permission can empty our L$ account balance, transferring all our L$ to the dishonest person who wrote and gave us the script

 

[FairreLilette]

1 hour ago, Mollymews said:

When we give a script any permission then it retains that permission. We are committed.  There is no way in SL to revoke a permission once granted to a script, other than reset, delete the script, or the script is honest and revokes the permission itself

There is probably a way to do it such as for the script to have written into a that __________________ (username), or say it's me and I'm the purchaser from the purchase HUD and then the script would read my name and say in nearby chat "FairreLilette can only pay ONCE from this purchase HUD" or something like that and have it written into the script each username can only pay once, but there is no way to prove this is an honest script and opens the door to scammers then...is that more or less what you are saying?   That's a bummer. 

So, for it to really work, it might have to be something created by LL and I doubt they would want to do it unless it might prove they could make a whole lot more money.  But, they probably wouldn't do it unless the purchase HUD also said in local chat for example "do not purchase from any other purchase HUD other than x/y/z (or insert LL name here) otherwise, it's fraudulent.  It could involve a lot of hassle but everyone could also be losing lots of sales. 

How many sales lost... well I know I don't go back to events if the demos were just too darn hard too get.  Fighting the lag once to get the demos at an event is horrid for me.  It makes events not worth it on my machine or I need to try to go as an invisible avatar.  But, still, there are a lot of times I just don't buy because I know I'm going to have to find each picture and name before I can even buy.  And, after I try on all the demos, I would just like to be able to purchase rather than go back and look for the items again because it could be done in just a matter of minutes on a HUD rather than at least another half an hour or longer to go back to the store or event.   So, all I know is I have not made a purchase because of having to go back to the inworld event or inworld store quite often.  It's too bad the Lindens don't have a poll available on this forum so they could see how many actually go back to the event or to the store to buy the item after trying demos (this is mostly for inworld.)

However...I am also wondering if there are those saying in this thread that this could work as long as there are no scripts in it?  If that were the case, the demo would have to work as a payable object in and of itself as well as a dispenser like my rezzed objects inworld do by giving either the contents or a copy.   I'll have to try it with an alt to see.  

Edited May 4, 2020 by FairreLilette

[Paul Hexem]

11 hours ago, Adam Spark said:

But surely there has to be a way for scripts to only take money when both debit is acknowledged and when a user requests the withdrawal. The fact that debit perms can allow random withdraw amounts to empty a purse surely can be stopped under the hood? But then there is a reason somebody else does these things and not me. It just feels like a loophole LL has resigned itself to not being able to fix - which they are notorious for.

What you're asking for is for a club owner to authorize every single payment to every single performer, every single time a tip jar is paid.

Not feasible. That's why the system is all or nothing. 

7 hours ago, FairreLilette said:

There is probably a way to do it such as for the script to have written into a that __________________ (username), or say it's me and I'm the purchaser from the purchase HUD and then the script would read my name and say in nearby chat "FairreLilette can only pay ONCE from this purchase HUD" or something like that and have it written into the script each username can only pay once, but there is no way to prove this is an honest script and opens the door to scammers then...is that more or less what you are saying?   That's a bummer. 

So, for it to really work, it might have to be something created by LL and I doubt they would want to do it unless it might prove they could make a whole lot more money.  But, they probably wouldn't do it unless the purchase HUD also said in local chat for example "do not purchase from any other purchase HUD other than x/y/z (or insert LL name here) otherwise, it's fraudulent.  It could involve a lot of hassle but everyone could also be losing lots of sales. 

How many sales lost... well I know I don't go back to events if the demos were just too darn hard too get.  Fighting the lag once to get the demos at an event is horrid for me.  It makes events not worth it on my machine or I need to try to go as an invisible avatar.  But, still, there are a lot of times I just don't buy because I know I'm going to have to find each picture and name before I can even buy.  And, after I try on all the demos, I would just like to be able to purchase rather than go back and look for the items again because it could be done in just a matter of minutes on a HUD rather than at least another half an hour or longer to go back to the store or event.   So, all I know is I have not made a purchase because of having to go back to the inworld event or inworld store quite often.  It's too bad the Lindens don't have a poll available on this forum so they could see how many actually go back to the event or to the store to buy the item after trying demos (this is mostly for inworld.)

However...I am also wondering if there are those saying in this thread that this could work as long as there are no scripts in it?  If that were the case, the demo would have to work as a payable object in and of itself as well as a dispenser like my rezzed objects inworld do by giving either the contents or a copy.   I'll have to try it with an alt to see.  

Ownership. If you're wearing a HUD, you own it. If you pay the HUD, you just paid yourself, not the creator. Doesn't matter if you're wearing a vendor script or no script at all. 

The only way around it is with that big all or nothing popup. 

[Wulfie Reanimator]

20 hours ago, FairreLilette said:

The reason a tip jar or a contest board is asking if you will allow lindens to be taken from your account is because of the split even though it doesn't take lindens from you...but the contest board does.

Your whole post was really hard to follow for some reason, so I'll just quote this part (which is also confusing to read).

Objects can't receive lindens. When you pay a tip jar, it goes straight to the owner's account. These days the owner of the tip jar is generally the owner of the club. In order for there to be a split, the script needs permission to transfer lindens from the owner of the object so that whatever cut can be sent back to the person who is currently using the tip jar.

Contest boards are no different. The contest board cannot pay the reward unless it has permission to transfer lindens from the owner. It would otherwise have to be done manually.

19 hours ago, FairreLilette said:

This needs a proper vendor system made, most likely through CasperVend or something like that plus ignoring what Chaser wrote as that is utter nonsense and I think Chaser is way off base (see my post above).

I think to create such a purchase HUD needs someone new school not old school to figure out.  It would need a universal vendor script put into the purchase HUD.  Someone with a reputable name like CasperVend.  

You can't initiate a purchase without right-clicking and selecting Pay (which can't be done on attachments), or having the script do that for you. It's just literally not possible.

17 hours ago, Adam Spark said:

Even debit permissions still require a pay action on the users end, or receipt of lindens by the user. The permission just allows an object to take the Ls you tell it to take.

Take the Relay For Life kiosks. I rez one and accept debit (I have to do this so that the money I get gets funneled automatically to the American Cancer Society). The kiosk is still not capable of blindly removing my lindens - just the lindens that the kiosk pays me.

So with that said I am sure it could be done without trust being a part of the equation.

llRequestPermissions(someone sad, PERMISSION_DEBIT);

while (permissions)
{
    llGiveMoney(someone happy, 1);
}

 

15 hours ago, FairreLilette said:

I am asking this question because some HUDS are coming with REDELIVER options right on the HUD itself as well and you can buy a Gacha now directly from a HUD and a mystery prize comes out.  You can buy the Gacha from the Marketplace itself for 50 lindens for a chance to win a random prize, and you wear the HUD and click for a random prize.

Redelivery and "receiving a random prize from a HUD you bought on the Marketplace" are completely different from what you're suggesting. No money is involved because the payment was already made. These two things are simply implemented with a server (in-world or off-world) that is contacted about the redelivery/prize request, the server "does its thing" and you get the item. In the case of gacha or "one-use" items, the server keeps track of the objects it has already sent the prize to.

15 hours ago, Adam Spark said:

I've used shopping huds and gift cards that "buy" via the gift card hud.

Gift cards should never need debit permissions. They don't need to deal in lindens at all.

A gift card should just be a scripted object that you either purchase (or get for free) that tracks the amount of imaginary "credit" it has. It works by communicating directly with the vendor you're about to buy from. That vendor can either be a "gift card recharger" which you pay yourself before it tells your gift card it has more credit, or that vendor can also just be a regular product vendor that is pre-programmed to understand and accept that gift card and its credits.

The gift cards that complete the rest of the transaction from your funds when there aren't enough credits is a nice quality-of-life feature, but I would instead make a way for those imaginary credits be refundable back to real linden.

11 hours ago, Mollymews said:

there have been a number of HUDs over the years which act like a little shop. From no-mod objects which contain the for sale items in a prim not the root, to server delivery systems

This is a bad idea, because objects can be copied out of the object's inventory even if the object is no-modify.

Edited May 4, 2020 by Wulfie Reanimator

[Mollymews]

28 minutes ago, Wulfie Reanimator said:

objects can be copied out of the object's inventory even if the object is no-modify.

only from the root prim. Right-click Open, Copy To Inventory

shop-in-a-prim (no-mod object) puts the for sale items in a linked prim

[Drakonadrgora Darkfold]

Actually there are a lot of bdsm items that do something like this already. Mostly the findom items. The biggest issue is getting your customer to trust you enough to click yes on the permission request.

[Wulfie Reanimator]

11 minutes ago, Mollymews said:

only from the root prim. Right-click Open, Copy To Inventory

shop-in-a-prim (no-mod object) puts the for sale items in a linked prim

Sorry but no. https://puu.sh/FG46v/972b3ae121.mp4

[Mollymews]

14 minutes ago, Wulfie Reanimator said:

Sorry but no. https://puu.sh/FG46v/972b3ae121.mp4

you are right

i really do have to stop posting about stuff that I never checked for myself

[Wulfie Reanimator]

8 minutes ago, Mollymews said:

you are right

i really do have to stop posting about stuff that I never checked for myself

The fastest way to learn is to be wrong. It's how I like to learn.

[FairreLilette]

5 hours ago, Wulfie Reanimator said:

Objects can't receive lindens. When you pay a tip jar, it goes straight to the owner's account. These days the owner of the tip jar is generally the owner of the club. In order for there to be a split, the script 

Contest boards are no different. The contest board cannot pay the reward unless it has permission to transfer lindens from the owner. It would otherwise have to be done manually.

I know objects cannot receive lindens.  What I was meaning *is* the contest board (via it's scripts or config cards) that I programmed including amount, when the contest ends, the lindens will come out of my account and so yes the contest board will not work unless I agree to what I call "the scary message" that everyone seems to hate.  There is no other way for the contest board to work unless I agree.  I am authorizing the contest board to take lindens out of my account via that permission message when the contest finishes; no lindens come out of the contest board.  I never said that.  

However, this seems to be a big hassle with loopholes for permission when I know we can pay for lots of things inworld without permission.  My contest board absolutely needs permission to take lindens out of my account and the amount I wrote in there too.  Why a hypothetical purchase HUD would need to have permission I don't understand unless it's because the hypothetical purchase HUD I am suggesting reads us as owner and that throws everything off.   So even a temp rez type of CasperVend purchaser wouldn't work either without permission to take lindens either because that object has ourselves as owner. 

 

Edited May 4, 2020 by FairreLilette

[Wulfie Reanimator]

19 minutes ago, FairreLilette said:

I know objects cannot receive lindens.  What I was meaning *is* the contest board (via it's scripts or config cards) that I programmed including amount, when the contest ends, the lindens will come out of my account and so yes the contest board will not work unless I agree to what I call "the scary message" that everyone seems to hate.  There is no other way for the contest board to work unless I agree.  I am authorizing the contest board to take lindens out of my account via that permission message when the contest finishes; no lindens come out of the contest board.  I never said that.  

However, this seems to be a big hassle with loopholes for permission when I know we can pay for lots of things inworld without permission.  My contest board absolutely needs permission to take lindens out of the my account and the amount I wrote in there too.  Why a hypothetical purchase HUD would need to have permission I don't understand unless it's because the hypothetical purchase HUD I am suggesting reads us as owner and that throws everything off.   So even a temp rez type of CasperVend purchaser wouldn't work either without permission to take lindens either because that object has ourselves as owner. 

Okay, let's go with hypotheticals.

Hypothetically speaking, let's say there was a way to wear a HUD that was owned by someone else (like you).

How am I supposed to be able to make a purchase through this HUD? I can't pay an attachment. The attachment cannot charge me.

Edit: (Also yes, temp-attached things change ownership.)

Edited May 4, 2020 by Wulfie Reanimator

[FairreLilette]

7 minutes ago, Wulfie Reanimator said:

Okay, let's go with hypotheticals.

Hypothetically speaking, let's say there was a way to wear a HUD that was owned by someone else (like you).

How am I supposed to be able to make a purchase through this HUD? I can't pay an attachment. The attachment cannot charge me.

No, let's say I make a hypothetical purchase hud.  I am the creator...you would be the owner.  

But what about a rezzable one...say a hypothetical temp rez CasperVend that comes with a demo and you could rez the temp CasperVend and pay in your own SL home for example and have product that is loaded in there delivered to you right there in your own SL home.  

[Wulfie Reanimator]

5 minutes ago, FairreLilette said:

No, let's say I make a hypothetical purchase hud.  I am the creator...you would be the owner.  

But what about a rezzable one...say a hypothetical temp rez CasperVend that comes with a demo and you could rez the temp CasperVend and pay in your own SL home for example and have product that is loaded in there delivered to you right there in your own SL home.  

The rezzable vendor would work without problems.

The crux of the issue is that if it's attached to an avatar, you cannot pay it. As long as it's not a HUD (or worn on your foot or whatever), there are no issues.

Edited May 4, 2020 by Wulfie Reanimator

[Adam Spark]

12 hours ago, Paul Hexem said:

What you're asking for is for a club owner to authorize every single payment to every single performer, every single time a tip jar is paid.

Performers generally own tip jars and club owners generally have no control (nor should need it) over their tips. In the use case of shared tips or DJ boards, a transaction triggered by a payment should go through. I have no issue with this. What should be stopped are the invisible transactions that bad apples can trigger. Every transaction that does not involve a payment or some other authorization by the loser of the money should not be possible on a technological level, in my humble opinion.

Edited May 4, 2020 by Adam Spark

[Rolig Loon]

53 minutes ago, Adam Spark said:

Every transaction that does not involve a payment or some other authorization by the loser of the money should not be possible on a technological level, in my humble opinion.

But of course that's exactly the way it works now. An object cannot take money from you unless you have given PERMISSION_DEBIT.  The problem is that people grant permission without thinking or without knowing what that implies, even after they have been presented with a big yellow warning box that explains it.  We are in a situation very familiar to anyone who has spent time on the Internet, where we are all told, "Do not share your password," but some people do it anyway.  There is a point beyond which it becomes the user's responsibility to pay attention to warnings.  

[Mollymews]

12 hours ago, Wulfie Reanimator said:

The fastest way to learn is to be wrong. It's how I like to learn.

yes. And when wrong then wrong and don't stress or fret about it. Just take on the correction and go with that thereafter

other thing that works for me is that if I knew everything, I wouldn't have anything to talk about

[Paul Hexem]

6 hours ago, Adam Spark said:

Performers generally own tip jars and club owners generally have no control (nor should need it) over their tips.

Completely incorrect, two or three times over.