[MUD-Dev] Seamlessly Distributed Online Environments

[J C Lawrence]

On Thu, 11 Sep 2003 20:25:01 +0100 
Crosbie Fitch <crosbie at cyberspaceengineers.org> wrote:
> From: J C Lawrence

>> That doesn't solve any of the core problems.  You are relying on
>> emergent user popularity metrics to implement what you assume will be
>> an emergent approximation to a globally unique namespace, while
>> ignoring the fact that you've implemented no way for a new object
>> sharing the identity of an older and necessarily more popular object,
>> to overtake the older object's popularity as you also have no way to
>> explicitly specify an exact version and implementation of an object.

> The name of a 'shared file' is equivalent to (encodes) the fractal
> address of a region of 3D space.

Right.

> Anyone can produce a file to define a particular region. No one can
> delete that file except its creator, though people can choose to view
> it, copy/adopt it, and share it.

Sure.

> Obviously, there will be several files vying to be considered as the
> 'preferable' definition of the respective portion of space. Some good,
> some nefarious. Some old, some new. Some sparse, some dense.

Precisely.

> A user can adopt whatever policy they fancy, e.g. I'll prefer the
> version that is most popular among other nodes in my vicinity. OR I'll
> prefer the latest dated version that is signed by an artist in my
> 'list of favourite artists'. Or the 'Wiki' policy, i.e. I'll use the
> latest version whether it's graffiti or not, and revert on an 'as
> necessary basis'. Or, I'll always prefer my own versions, but will
> take the most readily available otherwise.  Or any combination of the
> aforementioned or anything else you can think of.

You cannot prevent two people creating identically named files with
identical meta data but different contents.  Further you cannot
guarantee that two distinct players will retrieve the same file for the
same request, where a request is defined as a filename and any degree of
meta data other than signatures for the object.

> What we now have are people (very sophisticated computers) able to
> refine policies for selecting preferred content from a variety of
> alternatives.

And yet you have no way to distinguish among collisions, international
or otherwise.  

  Remember: The client is in the hands of the enemy, and in a P2P
  system, all the nodes are clients and all the nodes are in the hands
  of the enemy.

>> The catch her is that once you have a way to explicitly and exactly
>> identify particular versions and implementations of objects, you then
>> have a global namespace which is _attempting_ to be unique.  The
>> problem is that guaranteeing that uniqueness is non-trivial.

> I don't think I've understood you here... :(

You have no way to explicitly specify one particular version of a data
object in a fashion that can't be forged or otherwise dicked with.  You
have a name space consisting of object names and associated meta data
which does NOT guarantee uniqueness.

> How can you have a global namespace that isn't unique? 

Simple, you have names within the namespace which may have multiple
values: one to many mappings.

> If it's global then surely it's its own universe and by definition
> unique?  

Sure, it is singular as a namespace, but that's an uninteresting
characteristic for most things.  What is interesting is the degree of
uniqueness and the qualities of that uniqueness of names in the
namespace.

> Though I'm only taking a stab at the semantics here, cos I never knew
> I was attempting to create a 'globally unique namspace'.

Without it you have no way of determining what a particular object is,
or of referring to a specific object.

>> You both (near-)simultaneously transition a boundary into a new world
>> segment.  How do you guarantee that you both get the self-same new
>> world segment?  What guarantees that you both retrieve the same
>> version of the same object for the new world segment?  He might get
>> one version, you may get another.  How does that work for communal
>> play?  How about if you then ask Boffo to join you in this new world
>> segment -- how do you ensure that he gets the same one you do?

> Oooh. I can see I should've mentioned this...

> Solar Systeme Segundo is viewed/explored/modified in the large from a
> single user perspective (as a god).

Right, but this thread is not talking about Solar Systeme but rather the
application of P2P object distribution to MUD systems.

> Any section of the world can be (transparently - if we're lucky)
> exported as a 'level' for play in Quake/Unreal/Halflife, etc. And any
> one section of the world may have umpteen 16 or 32 player games
> occurring simultaneously. Think of SSS as a better 'map'
> browser. Indeed, there's no reason why live statistics of these games
> can't be overlaid in the god-mode viewer.

Even if you do centralised aggregation of a particular combination of
object definitions into a single super object representing a given map
definition, you have no method of guaranteeing that each player gets the
same map as long as you use a P2P transport.

> The point about SSS is that it's a FIRST STEP. It's a pretty trivial
> coding task (in the big scheme of things), certainly compared to the
> coding required for the kind of system necessary for a fully
> interactive P2P MMOG.  But, hey. Let's walk first.

Which is not the point.  The point is that this is a small corner of the
problem of identity mechanics, and you are assuming properties of
identity algebra which don't exist.

--
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw at kanga.nu               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev