Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111

From: "[email-masked]" <[email-masked]>
Date: Mon, 23 Feb 2009 13:44:54 GMT

>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).

Extraordinary reluctance to transmit information given the usual value of opensource to want information to be free and to move unhindered across frontiers!

Putting a CC license notecard *is not sufficient*. CC is not an economy and not commerce; it's a browbeating to give your content away for free in exchange for name credit only. It is not the foundation for a micropayments scheme. Notecards can also get lost or removed. 

If the permissions information is transmitted, and the TOS of the sending platform includes within the concept of trustworthiness that such permissions information must be implemented, then you have a very good ready-made regime for proving trustworthiness.

>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.

Transmitting metadata about permissions doesn't "fall short" of diversity. It creates the bedrock of diversity for an economy that is based on capitalist commerce and not only on collectivist "sharing" and *that* is what enables diversity.

I'm glad to hear you confirm, however, what others in OpenSim keep denying, mainly that to transmit metadata about permissions in fact "reduces greatly the possibility of interoperability with OpenGrid. Now why is that? Interoperability should give choices of systems, not take them away.

"Fair use" might need some updating or contextual examination and shouldn't be invoked casually merely to defeat commerce. In a virtual world, just because the platform providers already stream all the content, you already have your fair use, and so does everybody else who would like to see an object "for reference"! If you buy a skin or table, it renders for you -- what more "fair use" would you need when the entire thing renders for you always and everywhere, in your copy? If you've rezzed it out or are wearing it, everybody sees the full copy already lol. No, invocation of "fair use" here, as if stopping copyright theft in a VW would hobble fair use seems out of place and out of date.

>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, why can't it mandate DRM implementation as a condition of trustworthiness? And...why does the mere passage of information "waste resources"? Tons of data is transmitted, what, you can't spare a few bytes for c/m/t?

____________________________________________________________
Click for online loan, fast & no lender fee, approval today
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIpd4J1s4V5InglOtuqIfdBHGtUTsTbf6ji5kG7PYZqO10VzCMgHu/

---

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

Trustworthiness of a given grid is better left to the full
appreciation of the grid caretaker because there is no way to make an
automatic validation of the DRM implementation in some distant machine
(but that's really the most basic reason of all), so the entire debate
about what constitutes a trusted grid or not WRT copyright is out of
scope.

> I'm glad to hear you confirm, however, what others in OpenSim keep denying, mainly that to transmit metadata about permissions in fact "reduces greatly the possibility of interoperability with OpenGrid.

This is not what I wrote.

I actually wrote that mandating the implementation of DRM on top of
any permission/copyright metadata transmission mechanism would severly
reduce the number of grid systems that comply with the protocol.

> CC is not an economy and not commerce; it's a browbeating to give your content away for free in exchange for name credit only. It is not the foundation for a micropayments scheme.

I earn significant money from making full-perm content in Second Life,
so these assertions sound empty to me. I'm also a fiercely
individualistic capitalist (of the jusnaturalist kind), but you do not
have to believe me.

On Mon, Feb 23, 2009 at 2:44 PM, [email-masked]
<[email-masked]> wrote:
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: Kajikawa Jeremy <[email-masked]>
Date: Mon, 23 Feb 2009 15:11:04 +0000

currently I am seeing argument with regards the following

  Which virtual world system is more .... <<< CAN WE QUIT THE PISSING
CONTEST?

  to DRM or not to DRM... allow encryption == yes,  mandate it,  hell
no...

I will not mandate screwing over implimentation with damaged and
suspicious
  black boxed code for my own implimentations and any form of DRM is
easily
  subverted where a "trusted" party performs the subversion of its core
function.

reference = rc4 and other cipher algorythms having TLS support and NULL
encryption,
  this is perfectly valid and provides a hole regardless of system.

Either the content creators wake up and accept that each Virtual World
IS different
  along with that eventually the web itself will become 3D and people
are going to need
  their services a hell of a lot more for throwaway or personalized
items.

Each "system" may be as diverse as a "Star Trek" simulation and a
"Battle of Troy"  or
  become as diverse as the "Star Wars" and other Role-play systems
backgrounds...

Personally I can see people walking around various VWs as both Medievil
and
   Technology-expanded variants... will they meet? yes... where? in any
"open"
  or otherwise "public" virtual world with an interop agreement...

My own personal view of virtual worlds has been affected by a LOT of my
reading
  material and I dont expect anyone to actually believe how fast I
read...

since I can read somewhere in the order of 1-2 pages per minute without
  exaggeration at all...

Ive also looked through a good dozen or more RPG systems and see
something of
  a "Rifts" crossed with "Stargate" crossed with "contemporary now"
occuring...

 a LOT of the VWs are *escapes* from the real world and need to keep
that function,
  walking into a "Swords and Sorcery" simulation from a Tech sim would
be a social
  no-no so I am asking about making options here...

I may be coming across as harsh with the following but this is from the
perspective
  of a potential developer on any of the VWs or a potential rival...

1: Identity		-  This is the User Account and what access is required?
2: Representation  -  This is the Avatar or focus object...
3: Connection	    -  What form of connectivity occurs?
4: Transport         -  Is anything actually needing to be transferred
cross-system? if so...what?

5:  serialization of data - this needs to be agnostic and readily
available...

For the above I submit the following as usable...

1: Identity		I submit use of OpenID and OAuth for current mechanisms and
				also recommend requiring some kind of SSL or TLS.
2: Representation  I submit this to be *optional*...
    First access to any system - provision of a "TEMPORARY" account
   (garbage collect on expiry or mark "free" for re-use are choices
here).

3: Connection    I see this as actually bogus,  only the Identity
requires
   Connection and Transport of secure data,  anything of the AV
transferred would be
  usable for "common server" data,

4: Transport  as a subsection of 3 and requiring 5: Serialization.

llsd is a form of XML for my reading and it appears to conform to a file
format more
  than XML does...  make the tags for the angle brackets relevant.

I submit the following to allow mixed human readable AND machine
readable
  data content for use of mixed systems...

<object label="some name">
  <attribute name="UUID">0000-0000-0000-0000-0010</>
  <attribute name="asset-0">0000-0000-0000-0000-1000</>
  <attribute name="asset-1">0000-0000-0000-0000-1001</>
  <attribute name="asset-2">0000-0000-0000-0000-1002</>
  <attribute name="asset-3">0000-0000-0000-0000-1003</>
  <attribute name="asset-4">0000-0000-0000-0000-1004</>
  <attribute name="prim">encoding:sha1:encodeddatastring</>
  <attribute name="mesh">encoding:sha1:encodeddatastring</>
</>

The above is submitted as an example for what I have in mind...
  extensible attributes.

attributes may be added or edited by the original author or as technical
  limitations can permit legally.

---

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

> reduce the number of grid systems that comply with the protocol.

Note that it would be totally possible for someone to come up with a DRM 
scheme, that mandates that content create /under that DRM scheme/ only 
be transferred to other trusted implementors of that scheme. That would 
mean that, if the content was created on a compliant system, and 
properly marked, it could not "escape" into non-DRM systems. I think 
that enabling this within the standard is important.

A world can then compete for attention, by implementing and adhering to 
some popular scheme. For example, if creators feel most comfortable with 
"Microsoft VW Content DRM" or "MacroMedia ContentSafe(tm)," they could 
make sure to create their content in a world certified by one of those 
providers, and mark the object as not transferable outside those 
domains. Part of the certification would then be to make sure that such 
marks are actually adhered to. This neatly splits the interoperability 
protocol into the interoperability part, which is free, open, and allows 
OpenSim or LeftistWorld to be as open as they want, and the 
DRM/enforcement part, which allows the concerned content creators to 
stay as locked-up as they want within RightistWorld.

Sincerely,

jw

---

From: Kajikawa Jeremy <[email-masked]>
Date: Tue, 24 Feb 2009 02:24:47 +0000

and this is why I am wanting any "object" (AV included!) to be a block
  of extensible attributes to allow provision of DRM and also ignoring
DRM sections
  where the VW in question chooses to do so...

the only "common denominator" would be a mandate to not "mangle" the
object
 and attempt to "strip" the DRM or otherwise damage the object data...

I recommend for an object to be able to grow but not pruned unless
killed.

This would be part of the reason why Im wanting to seperate the objects
  from Identity...

That way someone like myself can have a "common name" but have each VW
  visited either be a re-usable or one-time account access...

I might access "OSgrid.org" and show up as a Caveman or Star Trek
engineer
  there and then teleport to "Guild Wars" or another MMORPG...

If I want to *visit* WoW and learn about it... I may do that and be
allowed a temporary
  account there with a single-session limitation with lack of some
interaction?

When making the jump to WoW or GW I would be entering a Swords&Sorcery
arena...
  coming from SecondLife or OSgrid wearing a Star Trek uniform is
definitely out...
  along with any transfer of content... I would *-need* to make a new AV
and select
  to whether I am to become a member or I am only visiting...

Im pursuing this based on my knowledge of existing specifications and
also
  my perspective as an end-user on some existing MMO systems.

I also dont expect to go beyond Identity being transferable to
non-compatible VWs.
  Changing from SecondLife to OpenSIM they have a compatible
architecture...
  and I would think I would keep only what I was wearing or carrying
attached.

is there *any* valid reason to go beyond this?...

the *only* use cases I am understanding would entail definition of
Identity and some
  mechanism for a chain-of-credentials that the servers can use for
Identity and
  making sure the correct account is used for each login along with a
  "compatible systems" transfer of AV objects and the vehicle carrying
it only when
  the user chooses to do this.

If the User is transferring to a new VW grid or system,  and has an
existing account,
  then I would prompt the user with a request to change their AV from
the originating
  systems AV representative to the new systems representative.

This would keep the walled Garden... and the only other part of this
standard would
  then become the connection of commerce...

Do we permit the SecondLife "Linden" play-money to be valid play-money
in OSgrid?
  do we permit an in-game currency from VW-A to be converted for
currency in VW-B?

We can define an optional mechanism for supporting such actions
  (expanding commerce and the area with which content may become
served...)

as that would keep the walled garden but also allow *wall-less* areas
outside
  the gardens "to grow wild and free" as the dictates of the users
permit.

THAT is the model with which I am currently imagining as practical AND
inside the
  scope of the MMOX charter (and it also provides a benefit to
commercial entities)

The value-add for cross-connection is not in an immediate effect...
  its initially a drain of resources for making it happen... but the
value-add result
  is more users have more access,  opening your doors to more
foot-traffic...

  VW foot traffic may be mostly one-time-shoppers... but a LOT of people
do return
  to where they get good service... and time spent making your service
available
  does this not pay back in returns by having loyal customers?

personally Im ignorant of the details and this is as simple-minded as I
am...

Does the above approach work for you?  since you can mark an "attribute"
for your
  content objects as being "allowed outside the garden"(GPL/CC) or
  "this garden only"(*-EULA/Commercial License blah...)

Anyway...Im going back to constructing my own VW implimentation toward
that vision

and I wish everyone else luck with trying to enforce their own opinions
on others...

I invite you all to only consider that vision and explain to me where
you see it having
  holes or lacking expansion?

since I am deliberately leaving whole swathes of items for extensions to
the spec,

VW Federated Identity / VW  Currency Exchange / VW Object Exchange

I propose that we define towards compatible systems becoming interlinked
first
  and work out a means of having additional non-compatible systems
interconnect
  in later drafts...

We dont need to solve everything now...we jujst need to get the snowball
started
  down the hill and all the bullshit about DRM/commerce and the rest
needs a better
  hearing...