Re: [mmox] Creating walled gardens considered harmful

[Kajikawa Jeremy <[e-mail]>]

Thank you Thank you Thank you,

Ive been braindumping trying to get something kickstarted like this
myself to see
  if anything Ive been thinking about is at all useful in this problem
space or able
  to be broken down further...

I personally see objects and parts of objects as a recursive item...
  and something like an XRDS description of an object (pen or chair) as
being a lot of
  parts (like lego building blocks to make a life-size chair from
mini-parts)...

glad to see someone getting some forward motion...

JW: I agree that LESS has potential and Server<->Server will be
required...
  but I disagree on disconnecting the clients out of the equation
entirely...

Eventually Client programs for end-users will need to know something
simplistic
  to be aware of region/service/... changes

How does LESS as a whole break into parts and what do the parts deal
with?

MXP ?

SecondLife Protocol ?

Croquet?

others?

having an idea of how all 50 systems are seperated for the tech stacks
will at least let
  us all find the breadcrumbs of similarities...

someone entering WoW only needs to confirm authentication and change
End-User
 program...  Guild Wars will be similar...

But I know for a fact that "BloodFrontiers" (available on SourceForge)
openly uses
  IRC as the chat mechanism and allows for players in-world to also chat
using a
  specific channel over Freenode IRC ...

is there anything similar for gateways between *parts* of a world...

talking by text from SecondLife out to OpenSIM or Croquet or Jabber?

is there any basic cross-connecting mechanism or would it specifically
need a region
  on the 3D system to have a "microphone" object to reflect messages to
the other
  server "room"s for the non-3D system people to listen?

How would that use case be covered?  MXP / LESS / HTTP polling of a
custom server?

what does the protocol that we are trying to declare *absolutely
needing*...
  beyond that we can leave as open for extension later...

we have already Identified the "Teleport" function...
  this needs to have a basic mapper for different services...
  and Im recalling Adam proposing a "service://server/region/x/y" URI
scheme
  that is usable for this...

what about a "service://server/" scheme default for anyone to support an
external
  service login?

Ive also seen mention of "whitelist"ing and "blacklist"ing by
services...

What policy options are we needing to look at for security ?

"Allow ALL" (anyone can connect with a valid server?)
"Whitelist"  (deny unless listed)
"Blacklist"  (permit unless listed)
"Deny ALL" (no one can connect without being a proper client...)

I see the "Deny ALL" rule above being broken by anyone making a custom
proxy
  which fakes being the original client software just enough for the
services provided.

Which runs into Server as client-endpoint security issues...

We need a social fabric to grow around the problem as well...

I recognise there is already various opinions that differ on this
list...

Sorry for the long message...  I started braindumping again...

Jeremy


On Sun, 2009-03-29 at 08:38 +0000, Morgaine wrote:
> On Sun, Mar 29, 2009 at 6:54 AM, Jon Watte <[e-mail]> wrote:
>         
>         I think that it's reasonable to believe that the 50 different
>         technologies will not each go back and re-implement the entire
>         client/server simulation/graphics communication stack.
> 
> 
> We're certainly making a protocol suite that all interoperating
> parties are expected to implement.  That's our entire purpose here.
> However, that does not mean that all elements of it need to be
> implemented by everyone --- that's a local policy decision, and not
> our call.  We are not really at the point yet where we can narrow down
> a "core", because all the elements are not yet on the table.
> 
> It will be a measure of our success or failure to what degree we can
> decouple the underlying services, since it is this decoupling plus
> flexibility in media handling that will give implementers an effective
> design space.  For example, not everyone will want to implement
> identity services, or object storage services, or world simulation
> services.  As we have already seen in practice, for some parties
> interop will mean no more than gaining access to avatar data for local
> 2D projection, so they would implement only the relevant sections.
> 
> With regard to the three elements you mention:
> 
>      1. The "client" of the protocol is actually a client endpoint, so
>         in your context the protocol(s) would have no relevance to
>         your actual clients because the client endpoints of the
>         protocol would be on your servers.
>      2. World simulation is not part of the interop protocol at all,
>         nor can it be because every world may implement a completely
>         different simulation.  On the partially related topic of
>         object behaviour (because this interacts with world
>         simulation), I refer you to this discussion on object models.
>      3. Most graphics would be handled only as extensible media types
>         for transport.  For those graphic elements that have
>         associated behaviour, subsequently event traffic (ie.
>         telemetry) would also be carried by the protocol.  Both
>         avatars and transportable world objects fall into this
>         category.
> 
> There are many parts to the puzzle, but participants need implement
> only those parts of relevance to them.  For example, Limited
> Capability Clients that are interested only in text chat would clearly
> implement only a very small part of the overall protocol(s).
> 
> 
>         
>         Thus, I think that requirement should be placed into the
>         problem space.  Do you agree?
>         
> 
> Requirements should definitely be placed in the problem space!  Note
> however that requirements are often broad and phrased in incompatible
> language, and therefore need decomposition into smaller more tractable
> elements that are fully understood before they can be used to
> synthesize a cohesive protocol.  I've been trying to do that.
> 
> 
> 
> Morgaine.
> 
> 
> 
> 
> 
> 
> 
> 
> On Sun, Mar 29, 2009 at 6:54 AM, Jon Watte <[e-mail]> wrote:
>         Morgaine wrote:
>         
>                 On Sat, Mar 28, 2009 at 5:18 PM, Jon Watte
>                 <[e-mail] <mailto:[e-mail]>> wrote:
>                 
>                        The question is: would you want to work on a
>                 standard, if you knew
>                    that the standard would only be adopted by 3 out of
>                 50 virtual
>                    world platforms in the world?
>                 
>                 
>                 We're not working on a standard for 3/50.  Instead,
>                 we're placing the requirements of the 50 platforms (or
>                 as many as we can) into the problem space, and
>                 analysing each one separately into components so that
>                 we can either find commonalities or else keep the
>                 requirements disjoint.  And then, once we see the
>                 whole problem space as a set of necessary component
>                 requirements, we can finally synthesize solutions that
>                 meet 50/50, or at least a high number.
>         
>         
>         That's great!
>         
>         I think that it's reasonable to believe that the 50 different
>         technologies will not each go back and re-implement the entire
>         client/server simulation/graphics communication stack. Thus, I
>         think that requirement should be placed into the problem
>         space.
>         Do you agree?
>         
>         Sincerely,
>         
>         jw
>         
> 
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox