[sldev] An Alternative solution to the PERMISSION_DEBIT problem.

[Erik Anderson]

If you don't know by now, if something could be handled by a third party
just as easily as LL could do it, then LL is going to ask someone else to do
it.  They're too small a company to do anything else :-P

On 5/30/07, Jason Giglio <gigstaggart at gmail.com> wrote:
>
> Tateru Nino wrote:
> > Not so rare, perhaps:
> > http://www.gridgrind.com/?p=93
> >
>
> That article gives the impression that objects you don't own can debit,
> that was never the case.
>
> *Every* game I sell and/or make for clients takes PERMISSION_DEBIT from
> someone.  Almost any object that needs to handle money has to have it.
>
> Even with llRefund most of my games would still need it, because they
> all allow a small bonus to be paid if you get the high score.
>
> There is another solution.  A third party (or parties) can create a site
> for "trusted PERMISSION_DEBIT"... each user would rez a box from the
> site gotten through authenticated channels.  People could manage their
> permissions to debit on the site, and objects that were compliant with
> the site would make an HTTP Request to trigger a payout.
>
> This site could have fraud controls built into it.  Throttling based on
> how much the user expected the machine to pay out.  Logging of attempted
> debits, etc etc.
>
> The site could pay for itself by taking a small commission from each
> transaction.  A few L$.
>
> This site could either be for-profit, or better, run by a group of top
> scripters in SL.
>
> There's nothing stopping Linden Lab from pre-emptively GOMing this idea
> though.  Hint hint. :)
>
> -Jason
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070530/f6e5375d/attachment.htm