[cap-talk] Fwd: [cors] TAG request concerning CORS &Next Step(s)

[David Barbour]

On Fri, Sep 4, 2009 at 1:34 AM, Ben Laurie <benl at google.com> wrote:

>
> On Fri, Sep 4, 2009 at 6:08 AM, David Barbour <dmbarbour at gmail.com> wrote:
>
>> Another feasible design is to use time-expiry caps... i.e. offering a
>> capability to use Google's ticker for a period of time, with regular renewal
>> from Acme. Acme would be free to cut off the expenditure at any time if a
>> user is discovered to abuse it, and can use a small pool of caps for a
>> larger group of users (using more than one cap allows them to quickly
>> discover abusers, but avoiding one cap per user keeps the communications
>> price down).
>>
>> That's the approach I've been pondering for a related problem, anyway: in
>> ocap-secured gaming, how do you ensure that players who obtain an ocap at
>> one point - e.g. to listen to the audio feed for a region, or see the
>> contents of a room - will lose that cap upon the avatar leaving the region?
>> My thought was that the environment would regularly broadcast caps to
>> avatars in the region, allowing the older caps to expire. This would reduce
>> the incentive for 'cheating' because a cheating client could not maintain a
>> cap without the cooperation of the broadcast source... but it would also
>> have a relatively low overhead.
>
>
> I'm curious how you know an avatar is "in the region" for this model?
>

That'd be a different responsibility, so there is no one way to handle it. I
might favor subscribing to database cap that tracks objects in the region,
including tracking which objects can hear ongoings of the region (i.e.
provide a cap for broadcasting the audio channels) and which can see
(provide a cap for broadcasting the video channels - or more than one for
different perspectives).

What mattered to the design is that a client who walks out of a region
cannot indefinitely remain subscribed to the information coming from that
region - to limit the reward for cheating - without having to pay a per-user
cost in the event a large number of observers are active.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20090904/3564ae90/attachment-0001.html