Subject: [mmox] Permissions

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 08:59:50 +0000

Just been talking to Adam about this and knocked out a very very rough
spec. It may be early in the game to discuss this issue, but it's one
that drives a lot of emotion in people on all sides of the debate.

So, without further a-do, here's a rough spec for a DSL (Domain
Specific Language) for permissions to discuss (copied and pasted from
my vim session, excuse any formatting weirdness):
Original concept courtesy of Adam Frisby, see
http://www.adamfrisby.com/blog/2008/08/hypothetical-permissions/

Very very rough thinking out loud

Each asset has a set of metadata fields:
	Author
	Creation timestamp
	Last modified timestamp
	Logs of modifications? (TBD)

Possible actions:
	Copy
	Modify
	Transfer
	Transfer for cash

Each action attached to a simple function that returns a boolean value
if action is allowed.
Data types:
	Entity
		Describes a user, organisation, system or network
	Asset
		Describes an asset ;)
	Location
		Describes a virtual location, rather than a physical system
	Time
		Date and time :)

Entity has these fields:
	Name
	UUID
	Class (person, organisation, system, network)
Optional fields for person entities:
	Agent domain? (TBD)
	System (what system is the user connecting from - may be withheld for
privacy reasons)
	Location (where in the metaverse are they?)
Optional fields for organisation entities:
	Organisation type (nonprofit/commercial/government etc)
	Company type (for corporations: LLC/Ltd/PLC/whatever)
	Address (i.e postal address)
	Technical contact (a person entity!)
Optional fields for system entities:
	Platform
	System hash (hash of various bits of hardware, HD serial and ethernet MAC etc)
	Network
	Current IP address
Optional fields for network entity
	Technical contact (heh, redundant)
	CIDR prefix

Asset
	Name
	MIME type
	UUID
	Creator
	Creation time
	Last modified time
	Last modified by

Location
	TBD (Obviously not the SL style Region/x/y/z)

Time
	You need to ask? ok,
	Day
	Week
	Month
	Year
	Hour
	Minute
	Second
	All integers

Simple comparision operators to match on what is passed to the functions
!=, ==, >, <, >=, <=, a few simple string functions, the usual suspects

function prototypes:
copy(Entity src, Location location, Time time, Asset ass)
	src      == the user currently holding the asset who wishes to copy it
	location == the location the requesting user is inhabiting at present
	time     == the time the request was made at (just in case there's
batch processing or serious latency)
	ass      == the asset being copied
modify(Entity modifier, Asset ass, Time time, Location loc)
	modifier == the entity trying to modify
	ass      == the entity they're trying to modify
	time     == the current time
	loc      == where is our modifier while they're trying to modify?
transfer(Entity src, Entity dst, Location loc, Time time, Asset ass)
	Same as copy essentially
sell() is just transfer, but invoked for transfers in exchange for compensation

The modify() function could probably do with a description (if
possible) of the modification being requested, for example in my own
work i'd want to prohibit modifications to the permissions in order to
enforce the GPL, others may have different requirements.

DANGER! DANGER! READ:
	Any system that can be proposed here can only be used to express
intent, it can express that intent very clearly using a DSL as i've
roughly
        spec'ed out above, but it will never be possible to actually
enforce it on systems that do not want to enforce it. I'll note that
personally I
	absolutely hate DRM for the most part, but if it's going to be a
reality it should be done right, and should allow any type of license
to be roughly
	expressed in a way that can be handled by automated systems. If for
no other reason than mere practicality, a decent DSL for specifying
what
	permissions an author of a copyrighted work has granted under
existing copyright law can be useful and saves having to pester the
author.

---

From: Jesrad <[email-masked]>
Date: Mon, 23 Feb 2009 10:18:02 +0100

Imagine for a second that the cross-grid protocol mandate somehow that
objects made on one grid be hosted and served to clients from this
grid, and not transfered to other grid servers / simulators (though
the owner may have the third-party possibility of exporting from one
and importing to another so it is hosted multiple times and thus
exists in multiple instances).

>From there any specific policy of "DRM" would purely be a matter of
specific grid implementation. I would say that a lot of headaches and
flames would be averted, saving us the trouble of directly addressing
these matters in the MMOX scope itself and leaving them for
grid-caretakers and their own customers to discuss and decide policy
about.

Please, everyone, let me know what you think of this.

On Mon, Feb 23, 2009 at 9:59 AM, Gareth Nelson <[email-masked]> wrote:
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 09:31:16 +0000

Some people are going to insist on the DRM or not allow their content
to be transferred at all, at least if there's a scheme in place like
this it will reduce headaches (at least until hell freezes over and
copyright law is overthrown).
I am absolutely NOT advocating DRM as a good thing, what I am
advocating is a system similar to DRM which simply tells you what you
are legally allowed to do. If you choose to ignore the permissions and
thus violate the copyright, that is between you and the courts, but
you should at least be able to find out where you stand legally
without pestering copyright holders every time, and it would help if
automated systems can aid you.

---

From: Kajikawa Jeremy <[email-masked]>
Date: Mon, 23 Feb 2009 18:55:18 +0900

I had a very interesting chat about this with Gareth...

and this is what I came up with... based off existing Email and
FileFormat styles...

Im going to tag this for style within this message...

anything in <> is to be machine readable sections,
anything encoded within a tagged item as "<...>encoded-data</...>"
 is to be human OR machine readable (Im not defining that here).
and I will be marking commentary below this point with the C++ comment
prefix "//"

<OBJECT 0xDEADBEEF>
  // Object verification starts here
  <ATTR label="name">My Custom AV Crossgrid Mohawk</ATTR>
  <ATTR label="license">MIT</ATTR> // human readable
  <ATTR label="pgp-sign">...</ATTR>
  <ATTR label="copy"></ATTR>
  <ATTR label="exportable"></ATTR>
  <ATTR label="resale"></ATTR>
  <ATTR label="UUID">0000-0000-0000-0000-0001</ATTR>
  <ATTR label="prim">...</ATTR>
  <ATTR label="mesh">...</ATTR>
  // Object verifies to here
</OBJECT 0xDEADBEEF>

// Processing concepts...

any "object" as described above will have mixed attributes when
export/imported
 across systems,  it may *gain* attributes but transfer back to the
originating system
 will include an "update-check" mechanism and notification of author
when a tampered
 item is detected...

Yes it breaks any "complex" down into bare primitive parts for various
systems,
  and also translates into "asset+inventory" functions of SL being
merged when out
  of that ecosystem along with trusted transfer mechanisms being used
for adding
  attributes where the author permits or the author can be specific and
use system
  permission markers on multiple systems where editing becomes
available.

This does have an enabling feature in that an incomplete object can be
invalidated
  at point of transfer where limitation of connection makes enforcement
occur in
  similar to a fashion of international travel.
  (you are crossing a great divide of some kind with the object)...

The above is to be defined as an inflexible bottom layer (physical
format)
  similar to the "layered transport" mechanisms already in use...
  recognition and use of any particular attributes by human or machine
processes
  is to be done as a seperate layer on top of this "formatted"
datastream...

This allows for encoding to a file OR encoding for transfer across the
network,
  either whole or not at all (the encoding needs to have a complete
transfer)... 

anyone who does make a "damaged" system will have it as a compromised
  server,  not as client system for any particular server.

also existing systems as example uses already exist under both MS and
GPL
 licenses,  so there is existing code-base re-usable to this context...

I submit the above as potentially expanding on the MIME encoding
transport
 of Email already in use and the way that is "multipart message
boundary"
 marked for each piece of a message and loss of one part breaking the
message
 and invalidating it.

Sincerely,
  Jeremy

---

From: Jesrad <[email-masked]>
Date: Mon, 23 Feb 2009 11:10:15 +0100

> to be transferred at all

And some people like me will insist that there is a way to do it that
cannot be prevented by third-party permissions system like this.

> thus violate the copyright, that is between you and the courts

I disagree. There is a very obvious situation where it is not only
legal to ignore permissions, but also illegal to have such
restrictions in place, and that is precisely the situation I am in
with regards to virtual world content. Where in your proposal do I
have the possibility of restricting further owners from restricting
further owners from copying, transferring, transferring for cash, etc.
? And even if you carve up more specs for this case, then what about
the case where the creator wants to restrict further owner from
restricting further owners from restricting further owners from
copying/selling/giving etc. ?

I hope you see where this is going.

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 10:17:40 +0000

"Where in your proposal do I
have the possibility of restricting further owners from restricting
further owners from copying, transferring, transferring for cash, etc.
?"

That is precisely one of my own reasons for wanting a more flexible
system. I know if I release anything under the GPL on SL, people will
go and modify it remove the permissions without a second thought.
Basically, i'm trying to define the things restricted by copyright
law, and then tie them to functions saying whether the author has said
"you're allowed to do this" or "you're not allowed to do this".
Basically, a way for automated systems to do what requires human
intervention right now - humans have to pester copyright holders or
interpret the license document.

Whether or not you actually OBEY the license is up to you and the
relevant legal authorities.

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 10:21:18 +0000

> cannot be prevented by third-party permissions system like this.

But that's besides the point, since doing so isn't going to convince
people to allow the content to move AND this system does not in fact
prevent anything, it's a machine-readable version of the license - the
only force comes from compliant systems and users or the courts.

---

From: Jesrad <[email-masked]>
Date: Mon, 23 Feb 2009 11:27:11 +0100

Hmm, "it's not gonna enforce IP technically" was not the point I
wanted to make. The actual point is: attempting to define a mechanism
for signalling what categories of actions are permitted or not under a
specific copyright law (which may or may not be applicable depending
on national/sovereign context) is a non-starter because of infinite
recursion.

This is one of the main reasons I suggest curtaining the issue
entirely by adopting a multiple-host approach, where content (but not
necessarily the MMOX-layer object reference itself) remains hosted on
the originating grid and is not replicated between different grids
through the cross-grid protocol. The other reason for following such
an approach, is that it's the only one compatible with existing P2P
VWs like Solipsis.

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 12:44:03 +0000

Well, talking to a few others it seems the general consensus is "make
a field on assets for all this stuff and make the scheme extensible".

---

From: Jesrad <[email-masked]>
Date: Mon, 23 Feb 2009 14:32:24 +0100

OK, but doesn't that just make this "stuff" a form of content, or at
most metadata ? In this case, it might fall off scope anyway.

Even if it is recognized by consensus as a valid form of data to be
exchanged between grids, which is reasonable when presented in this
way, the twin problems of relevance WRT the domestic legal context and
of relevance WRT the actual implementation of any DRM in the target
grid make this sort of data irrelevant when it can be entirely
superseded by any other form of user content associated to the object
(like, say, a CC license notecard as in SL, or a simple copyright
notice).

To put it differently: if we do not mandate any implementation of DRM
per protocol specifications, then this sort of data is purely
"client-side" and is better left to the resident/player-creator to
make and include in the concerned object. And if we do mandate DRM
implementation, then this implementation ifalls short of the diversity
of legal contexts (for example fair-use cases, which vary widely
between jurisdictions), breaks some models (like mine), and reduces
greatly the possibility of interoperability with a number of existing
VWs like the OpenGrid or (AFAIK) Solipsis.

If you insist that there is space for this sort of metadata and the
protocol does not mandate DRM implementation for the server-side to
enforce, then I can live with it. But I'll still think it a waste of
resources.

...well, maybe it can be later hijacked for a better end user-worthy
purpose, I guess.

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 13:37:47 +0000

Well, the "stuff" was generally recogonised by others as being much
more complex than my naive ideas on the subject would make it appear
for multiple reasons which i'll point you at today's
[email-masked] logs for.
I would be quite opposed to actually *mandating* any implementation of
DRM, as i've said multiple times the idea is to let automated systems
know what is allowed - it's up to the implementers of those systems
whether they obey the license restrictions or not.
The problem i'm trying to solve here is one where you need to manually
ask the copyright holder every time you want to move their work to
another grid. Making it machine-readable makes it possible to automate
things, while a human-readable license does not.

---

From: Jesrad <[email-masked]>
Date: Mon, 23 Feb 2009 14:59:13 +0100

This amounts to an implementation of some DRM, if I understand it
correctly. Would it be part of the protocol that grids are to
machine-read it and enforce it ? I would guess so if there is also a
section of the protocol addressing asset exchange. In this case the
problem is still more complex than anticipated (how do I restrict next
owner or next grid from restricting next owner or grid from
grid-exchanging the asset, etc.)

Nevertheless, the entire issue is avoided by keeping content hosted in
its original grid, and the renderview being supplied by multiple
sources (according to the endpoint identity's credentials, if required
by the source grid implementation). Isn't it ?

---

From: Gareth Nelson <[email-masked]>
Date: Mon, 23 Feb 2009 15:33:42 +0000

You can't actually prevent the remote grid from doing anything once it
has the data, if I accidentally claimed otherwise slap me with a
hypocrite stick.
The idea is that grids CAN enforce it, but the main point is just to
make it possible to know what's allowed.
However, since explained before this issue is much more complex than
it at first appears and goes wildly out of scope, so consider my
initial proposal withdrawn.

---

From: Morgaine <[email-masked]>
Date: Mon, 23 Feb 2009 16:31:27 +0000

This is not an area where a bit of quick brainstorming will yield useful
fruit.

It's an immensely complex area that handles the expression of rights,
permissions, licenses, covenants, patent grants, EULAs, and many other items
that are only partly analytic, and then intertwines them all with real-life
semantics to yield an explosion of complexity beyond anything we can plan to
handle, or even imagine.

And before anyone mentions the phrase "machine parseable", please note that
authors have the legal right in most jurisdictions to apply multiple *
incompatible* licenses to a work of authorship ... good luck resolving that
mechanically.

Also, rights/restrictions are not all of the common static type ("no rights
change"), but can also increase or decrease downstream.  Authors need the
semantic of "decreasing rights allowed" to allow customization of generic
assets by intermediaries such as rebranders, as well as that of "increasing
rights allowed" to allow incorporation of their works into mashups and
remixes while retaining visibility as authors, a growing interest.

As if that weren't hard enough already, the diversity of VWs will add
complication because many will have incompatible access domains:  for
example, group access is a common form of rights/restriction, but groups may
be disjoint or overlapping or hierarchical in different VWs, so the semantic
of group access is not immediately portable.  Plus, the non-hierarchical
objects of SL do not allow creators to make higher-level objects by
composition and thus ride on the shoulders of giants, so we can expect them
to become a subset of normal interop objects;  as a result, rights handling
will need to tackle hierarchical object composition as well.  Not easy.

And then on top of that, it all gets even hairier when attempting to apply
the law of the land in different jurisdictions.  For example, some
jurisdictions allow Fair Use or Fair Dealing, so denial of access for such
use is inappropriate.  Other jurisdictions provide strong support for
accessibility, so media needs to be format-shiftable to suit a handicap
which can be in conflict with claimed authors rights, and so on.  This area
is so hard that the best we can do is to express *intent*.

To express *intent *satisfactorily in the presence of what I hope is clearly
a very complex domain, you have to be not only flexible but *extensible*,
because the rights/restrictions needs of VWs cannot be forseen.  One way of
doing this that is interop-friendly is to endow objects with a *property
list*, onto which authors can place an arbitrary number of arbitrarily
tagged metadata items, for example:

   - *GPLv3->{LICENSE-UUID}*
   - *LindenRights->{version,perms}*
   - *CC->{3.0,by-nc-sa}*
   - *MPEG21->{REL_XML_schema}
   *
   - *ccREL->{RDFa_expression_or_URL}*
   - *DoD->{crypto-signed-perms-block}
   *

Some of the above tags you'll all recognize, and some you may not, which is
precisely the benefit --- the set that you recognize in your world may be a
completely different set to that recognized in a second virtual world, and
yet the properties can still be processed.  This remains true even if an
object passes through multiple worlds.

Such a property list is easy to handle on interop:  just look up the tags
until you find some that you recognize (this may require external lookup if
none are cached, and possible ordering), and if required then extract and
parse the tagged metadata.  Some tags express everything you need to know in
the tag name, such *GPLv3*, so passage through interop is trivial.  Other
tags require metadata parsing and checking of field values, such as *
LindenRights*.  The definition of tags and metadata that do not use
published standards would of course be up to the worlds that use them, but
use of published standards would be highly recommended.

The scheme is not tied to top-level OR alternatives either, but can be
extended to arbitrary logical expressions within the metadata.

The above is not proposed as a specific solution, but only to illustrate the
general concept of using property lists as the mechanism for extensibility
of metadata properties such as permissions and licenses.  Without such
extensibility you cannot pretend to be addressing the needs of diverse
future worlds, yet it is also highly practical because it allows existing
worlds with established rights/permissions structures to enter the world of
interop gracefully.  And it is future proof.

PS.  Don't invent your own rights languages unless nothing else is suitable
--- at the very least inform yourselves about the standards that already
exist first, otherwise you are bound to get it wrong if you handwave a new
solution.  A good start might be to examine the *MPEG21* and
*ccREL*standards (used as tags above):

*MPEG21 - http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm
ccREL - http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/
*

Morgaine.

---

From: Lawson English <[email-masked]>
Date: Mon, 23 Feb 2009 12:49:12 -0700

> by the source grid implementation). Isn't it ?

Just how many separately hosted grids/asset servers are we talking about 
here?

And how many assets?

SL, sorry to keep bringing it up, but its an important usecase, has 
20,000 simulators and some
ludicrous number of "assets" to deal with. If there's no local caching 
of assets on any other grid,
permissions allowing, then the SL servers would be expected to be asset 
server to the metaverse
and they already groan under the strain of talking to the limited SL 
world. The metaverse is
projected to become 100-100x larger than Secondlife. the AWG's original 
mission was to try to
desing a SL-like meta-grid that would handle such "scary numbers." We 
can't just handwave
the issues away and suggest that existing systems and architectures will 
"just do it" in some way.

Permissions/digital rights  of SOME kind is required for any asset that 
isn't identified as
Creative Commons" and even there, a CC license can vary quite a bit. 
there's a ccREL
(rights expression language) defined just to identify variations of the 
Creative Commons license,
and CC is NOT enough to handle all the possible needs for digital rights.

L

---

From: Jon Watte <[email-masked]>
Date: Mon, 23 Feb 2009 12:45:25 -0800

> exists in multiple instances).

How then would the soccer ball on my server be able to affect the soccer 
goal on your server? If only the clients know about the entities from 
the 2 servers, your "goal" object on your server would never detect the 
presence of the "ball" object within its "goal zone."

This is why I believe that direct client distribution is not actually 
the right model.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Mon, 23 Feb 2009 13:10:58 -0800

> 	Transfer for cash

:"Transfer" and "transfer for cash" really aren't different operations. 
How two entities choose to transfer is up to them. From the point of 
view of the originating system, a "transfer" means that the "owner" 
field changes from A to B. It may be that you want "conditional 
transfer," where there is some URL that needs to return "true" for the 
transfer to complete; that URL could then affect a sale transaction, or 
it could do something totally different (like signing a "guest book" or 
checking against a "black list").

Does "Copy" mean that the originating system creates a new object 
instance, with a potentially new owner?

And I think you may end up with cases where I get a copy of some object 
you've made. That means that there's an object on your system that has 
me as the marked owner. I may not actually be a customer at all of your 
system, so it may be that your system doesn't want to allow me to do 
that. Or, if they feel that hosting objects for non-customers isn't a 
problem for one reason or another, they could allow that. (There are 
some business models where this makes sense; for example where I can't 
instantiate an object unless I'm in an area on that server, and I can't 
be in an area on that server unless someone is paying for the machine time)

Is there a difference between "modify" as in changing properties of an 
existing object, versus "read source" as in extracting behavior or 
presentation specifics (meshes, scripts, etc), versus "derive" as in 
creating a new object that references the original object with some 
potential overrides?

And are we talking "objects" vs "object blueprints" here? Is it the case 
that any object is actually a "blueprint," and there's no templating 
system in SL? I know that many other systems make an explicit division 
into "instances" vs "blueprints" (or "templates"). An "instance" starts 
out as the template, but can override some set of properties -- for 
example, the "position" property would typically always be overridden :-)

You also need to specify leftism/stickiness. If you allow "copy" or 
"derive," then some licenses say that any copy so created must also 
allow "copy" and "derive." Other licenses say that a "copy" could have 
its permissions changed. Similarly, a "transfer" may be made in terms of 
ownership of the particular instance, OR it may be made in terms of 
source right -- and, in that case, the source rights may be with or 
without sub-source-right permissions.

I think we can capture this by making these changes:
1) specify the "template," if any, of the object
2) specify whether each permission field is "inherited," "revoked" or 
"immutable" on transfer
3) add the "view" and/or "derive" permission bit

Specifically, the left-ism licenses would favor setting the "copy" and 
"view/derive" bits, and set them with "immutable" semantics. A right-ism 
license might specify "copy" with "revoke" -- you can't re-copy 
something that's been copied. Of course, if it's "transferred" then that 
bit probably shouldn't be revoked, so it might be there's a matrix of 
what happens to each permission bit under each operation.

An additional meta-bit on each operation might be "only when managed by 
DRM" -- the "copy" bit might say "allowed only when under DRM," and then 
there's a separate list that identifies the allowed DRM models (so that 
the source can provide trust or not). As long as the DRM trust chain is 
unbroken, and the object originates in a DRM system, that would allow a 
"fully secure" DRM model.

Personally, I think that this could, and should, be done, and that it 
serves the desires of all the parts of the spectrum. The "open" grid 
needs to identify itself as NOT supporting DRM, and then the "closed" 
grid will not send the data. If the "open" grid tries to impersonate a 
"closed" grid, then it's up to the specific DRM schemes to use 
signatures or whatnot to smoke out the impostor; that capability is very 
common with distributed DRM schemes and there are technical solutions 
available, should you want them.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Mon, 23 Feb 2009 13:20:35 -0800

Lawson English wrote:
> permissions allowing, then the SL servers would be expected to be 
> asset server to the metaverse

Note that the SL assets can only be used when the SL servers are 
participating in an interoperation scenario. If SL makes it a 
requirement that at least one SL customer is part of any interoperation 
scenario involving SL servers, then SL has a revenue stream for each 
such interoperation scenario. From the point of view of any one service 
provider, I think that this model will work well, and it will scale 
fine. The problem is then reduced to a per-provider problem, where each 
providers' ability to serve its customers is an implementation and 
business model detail, not an interoperation detail.

> projected to become 100-100x larger than Secondlife. the AWG's 
> original mission was to try to
> the issues away and suggest that existing systems and architectures 
> will "just do it" in some way.
>

I think we've all agreed that this group is not the AWG. Our role is not 
how to figure out how to "scale Second Life" or even "scale something 
Second Life-like." Our role is to figure out how to make multiple, 
disparate systems able to talk to each other -- hopefully in a way that 
will let the greater world able to scale in aggregate.

Sincerely,

jw

---

From: Jesrad <[email-masked]>
Date: Mon, 23 Feb 2009 22:23:54 +0100

> goal on your server?

In Solipsis, a completely decentralized VW, congruent nodes (servers)
with dynamic objects keep each other up to date with the movements of
those if they are close enough. Objects then determine if they hit the
other object and react accordingly: each soccer ball is told about the
other's position in real time.

On Mon, Feb 23, 2009 at 9:45 PM, Jon Watte <[email-masked]> wrote:
> goal on your server? If only the clients know about the entities from the 2
> servers, your "goal" object on your server would never detect the presence
> of the "ball" object within its "goal zone."
>
> This is why I believe that direct client distribution is not actually the
> right model.
>
> Sincerely,
>
> jw
>
>

---

From: Christian Scholz <[email-masked]>
Date: Mon, 23 Feb 2009 22:24:39 +0100

> checking against a "black list").

The reason "Transfer for cash" is in there because of events where some 
full-mod objects which are not meant to be sold were being sold by the 
new owner.
So in fact it might be some condition but I am not pro URLs which 
perform some check.
The reason for this is that when I buy an object I want to know what the 
rules are. If there is a function under somebody else' control which 
determines if an object can be transferred to entity X than I cannot be 
sure of the rules unless I very much trust the entity controlling that 
URL. Also what happenes if the server hosting that URL goes out of 
business? Can I then still use the object at all?

Because of that I would find a solution better which is self-contained 
and carries all information necessary. The "transfer for cash" is also 
more or less a licensing question which IMHO should be dealt with an 
attached license blurb (GPL, CC whatever). I don't think anyway that we 
can model all license questions into technical solutions.

That being said I am also for a flexible way of attaching such data so 
that we can support multiple permission or licensing schemes. It's then 
up to the entity providing data to define which schemes they support. In 
order to be able to interoperate we of course need at least a basic set 
which MUST be supported (or we end up with the ability of only 
exchanging objects which are public domainish).

There are of course not only permissions which can be attached as 
metadata but potentially a lot more (dublin core etc.).

> be in an area on that server unless someone is paying for the machine time)

We probable run into discussions whether objects should be passed as a 
whole copy from server A to B or as just a reference (and maybe just 
metadata passed). But I might again have a problem with the fact that 
server A could go out of business leaving me with unusable objects (like 
certain ebook servers going down.. ).

> available, should you want them.

As said, I really would like to have a more abstract mechanism of 
attaching metadata with various schemes. The scheme you describe could 
then be one of them. Having an extensible mechanism might also be more 
future proof then.

-- Christian

-- 
Christian Scholz
Blog: http://mrtopf.de/blog
Company: http://comlounge.net
Podcasts: http://datawithoutborders.net, http://openweb-podcast.de

---

From: Jon Watte <[email-masked]>
Date: Mon, 23 Feb 2009 13:53:22 -0800

> other's position in real time.

That's right! That's the model I think will work.

What I'm arguing against is the argument that _clients_ connect to 
multiple servers (in a client/server system); in such as system there is 
no way that the server object of the soccer goal can know about the 
other-server object soccer ball. My argument is simply against the idea 
that a single client connecting to two separate virutal world servers 
could provide a usefully consistent view of a virtual world simulation. 
Unless you require the client to serve as proxy/gateway/translator for 
funneling data between the servers (again, in a c/s system), which would 
be terrible for both technical, trust and scalability reasons.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Mon, 23 Feb 2009 13:58:37 -0800

Christian Scholz wrote:
> much trust the entity controlling that URL. Also what happenes if the 
> server hosting that URL goes out of business? Can I then still use the 
> object at all?
>

If your webhost goes out of business, will links to your website still work?
If YouTube goes out of business, will your hosted videos still work?

> attached license blurb (GPL, CC whatever). I don't think anyway that 
> we can model all license questions into technical solutions.
>

The problem with self-contained systems is that simulation is tightly 
bound to languages and environments. While a simulatable object may be 
transportable between services based on the same technology (or even 
based on the same version of the same technology), general 
transportability of the object is not a realistic goal. Compare sending 
a link to your Wiki, versus sending a downloaded copy of your Wiki -- 
very different things!

The ability to transfer an object (rather than a reference) between 
servers, assuming they can each host the same object, might actually 
make for yet another kind of operation. "Transfer ownership" is 
different from "transfer bits." Again, I think that bit could be there, 
and it could be conditional just like the other bits -- "allow," "deny," 
"allow and revert," and "sticky allow," coupled with the mark-up of 
possible DRM requirements, that only needs to be recognized by systems 
actually implementing DRM.

Sincerely,

jw

---

From: Ann Otoole <[email-masked]>
Date: Mon, 23 Feb 2009 14:05:55 -0800 (PST)

"If SL makes it a requirement that at least one SL customer is part of any interoperation scenario involving SL servers, then SL has a revenue stream for each such interoperation scenario."

You forget that there was no requirement established that participation in standards does not require for profit only status sir. Or that sentence of yours was not stated in a sufficiently clear and unambiguous manner. If Kapor/Rosedale wishes to establish interop for non profit activities then Kapor/Rosedale will do so. It is their money.

In addition I think it would be useful to replace any Linden Lab participant's name with "The CEO of Linden Lab said:" to get this correct since the level of discourse has been established at the corporate officer level and is no no way possible to drop to technical level unless the corporate officers of various corporations trying to direct this effort remove themselves and allow peers only to participate. If the Linden Lab staff are not representing their CEO then they need to get a formal corporate officer rep in here since Linden Lab's competitors' corporate officers are here en masse.

>From the available information I have seen Second Life/Second Life derivitives have the interoperability momentum at the moment. Exactly what public "grid" does Forterra bring to the table anyway? How many simulators is Forterra running in use 24*7? How many actual end users does Forterra have on a daily basis? Why should we consider anything from Forterra as authorative? They just show up and start shoving people around complaining about the industry leader? Why does anyone care about Forterra Systems? What does Forterra think will happen if awareness of this effort was properly communicated to the millions of Second Life customers and some thousands of them decided to begin actively participating in these proceedings? Do we really want that mob scene to take place?

Personally I would prefer the animosity stop and this remain technical instead of corporate competition postitioning level.

All it takes to deal with the issue of permissions in general is a commitment to include permissions as a component in the standard, whatever that looks like, and then create a sub committee/list to debate permissions seperately and once consensus is acheived the proposal be brought forth for debate.

---

From: Jesrad <[email-masked]>
Date: Mon, 23 Feb 2009 23:08:11 +0100

> What I'm arguing against is the argument that _clients_ connect to multiple
> servers (in a client/server system); in such as system there is no way that
> the server object of the soccer goal can know about the other-server object
> soccer ball. My argument is simply against the idea that a single client
> connecting to two separate virutal world servers could provide a usefully
> consistent view of a virtual world simulation.

Well, that's precisely the model Solipsis is based on, and it seems to
give a reasonably consistent view. The node with the soccer ball can
decide to let others know about it or not, and that makes little
difference for the rest of the world. In this model you're free to
have things exist only in your own universe and not affect anything
else, and that's fine if that's what you want (meaning you can have
inconsistency if you want it). If you're interested to see how
decentralized a VW can get in practice and theory, read the paper the
project team wrote:
http://bots.netofpeers.net/riam_solipsis/LOT1/MMVE_ID_6_Solipsis.pdf

On Mon, Feb 23, 2009 at 10:53 PM, Jon Watte <[email-masked]> wrote:
> What I'm arguing against is the argument that _clients_ connect to multiple
> servers (in a client/server system); in such as system there is no way that
> the server object of the soccer goal can know about the other-server object
> soccer ball. My argument is simply against the idea that a single client
> connecting to two separate virutal world servers could provide a usefully
> consistent view of a virtual world simulation. Unless you require the client
> to serve as proxy/gateway/translator for funneling data between the servers
> (again, in a c/s system), which would be terrible for both technical, trust
> and scalability reasons.
>
> Sincerely,
>
> jw
>
>

---

From: Christian Scholz <[email-masked]>
Date: Mon, 23 Feb 2009 23:08:28 +0100

> If YouTube goes out of business, will your hosted videos still work?

No but I can copy that video to my collection if I want to. And if I pay 
for something I expect it to be downloadable anyway. Services might be 
different but we see in the case of music that to sell just a license is 
not really working. People want to own their stuff. When I buy something 
in a virtual world in a virtual shop in-world I am thinking about this 
the same way I buy something in real life. It's not suddenly gone.
But even if we say we can reference objects it would still be useful to 
also have the ability to make a real copy if both parties wish to do so.

> a link to your Wiki, versus sending a downloaded copy of your Wiki -- 

I still can download the wiki if I'd like to. I can also download photos 
from flickr and so on.
And I am really not sure if on the long run not all systems might become 
similar in their technology. In the beginning you always need gateways 
to move data around but later on those might more and more vanish and be 
replaced by one winning format which might or might not be a mix of all 
the formerly existing ones. On the short run though I agree that not 
everybody now will change their deployed system to conform to the one 
and only standard.
I can also live by having a full copy and reference, I just don't want 
the full copy ruled out directly.

> actually implementing DRM.

As said, I would favour various metadata schemes which you can attach to 
an object or a reference so things stay flexible.

-- Christian

---

From: Jesrad <[email-masked]>
Date: Mon, 23 Feb 2009 23:14:31 +0100

Very interesting point, thank you !

I figure we can have local caching with encrypted, timestamped copies,
and have the original grid/host only transmit the decryption key to
the intended endpoint. That way, we can have caching without unwanted
disclosure of the data to the caching middlemen.

On Mon, Feb 23, 2009 at 8:49 PM, Lawson English <[email-masked]> wrote:
> SL, sorry to keep bringing it up, but its an important usecase, has 20,000
> simulators and some
> ludicrous number of "assets" to deal with. If there's no local caching of
> assets on any other grid,
> and they already groan under the strain of talking to the limited SL world.
> The metaverse is
> desing a SL-like meta-grid that would handle such "scary numbers." We can't
> just handwave
> Creative Commons" and even there, a CC license can vary quite a bit. there's
> a ccREL

---

From: Jon Watte <[email-masked]>
Date: Mon, 23 Feb 2009 14:48:35 -0800

Ann Otoole wrote:
> "If SL makes it a requirement that at least one SL customer is part of 
> any interoperation scenario involving SL servers, then SL has a 
> revenue stream for each such interoperation scenario."
>
> You forget that there was no requirement established that 
> participation in standards does not require for profit only status 
> sir. Or that sentence of yours was not stated in a sufficiently clear 
> and unambiguous manner. If Kapor/Rosedale wishes to establish interop 
> for non profit activities then Kapor/Rosedale will do so. It is their 
> money.
>

Absolutely! What I'm saying is that, even for people who don't want to 
give away computing time for free, the context of allowing their servers 
to host objects for "owners" who aren't actually customers can still 
make sense. This means that the model is universally applicable to both 
for-profit and for-free service providers.

>
> From the available information I have seen Second Life/Second Life 
> derivitives have the interoperability momentum at the moment. Exactly 
> what public "grid" does Forterra bring to the table anyway? How many 
> simulators is Forterra running in use 24*7?

Forterra does not operate "grids." Forterra licenses technology and 
consulting to organizations who want to operate their own virtual world 
systems, of all different kinds of size and scale (think "dozens" to 
"millions"). We are a privately held company, and do not disclose our 
sales numbers publicly, but I can tell you that the number of OLIVE 
systems in production 24*7 is more than a handful.

Additionally, OLIVE systems have been in use in interoperating virtual 
worlds of various kinds since 2005, which includes displaying avatars 
from other systems and vice versa, so I believe we have a lot of 
beneficial learning to share.

> All it takes to deal with the issue of permissions in general is a 
> commitment to include permissions as a component in the standard, 
> whatever that looks like, and then create a sub committee/list to 
> debate permissions seperately and once consensus is acheived the 
> proposal be brought forth for debate.

It's surprising to me that you seem to try to attack the credibility of 
the company I work for, yet the specific proposals I make on this group 
address exactly the specific requirements you say you want to address, 
in a way that makes them generally acceptable to all kinds of operators 
and all kinds of content creators. If there is some technical problem 
with the proposal I've made, that you believe would not serve the needs 
of some particular kind of content creator or virtual world operator, I 
would like to see that technical deficiency pointed out, so that it can 
be corrected. If not, then I expect you to actually support the specific 
proposal.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Mon, 23 Feb 2009 14:51:16 -0800

> difference for the rest of the world. In this model you're free to

In the general case, letting arbitrary, untrusted clients introduce 
content into a virtual world is not desirable. It would actually leave 
organizational users open to various kinds of discrimination and 
harassment lawsuits.

However, if for Sollipsis you consider each "peer" as being a "server" 
in the proposal I've suggested (which, btw, was explicitly called out in 
the keynote slides for last year's IEEE MMVE), then it is the same 
model. I would expect that you could actually quite easily implement the 
proposed interoperability model into Sollipsis and interoperate with any 
other peer or server that wanted to interoperate with you.

Sincerely,

jw