[MUD-Dev] Seamlessly Distributed Online Environments

[Crosbie Fitch]

From: J C Lawrence

> You cannot prevent two people creating identically named files
> with identical meta data but different contents.

Ah, so the key here is 'meta' data, e.g. 'author', 'version',
'date', or whatever?

I did consider it likely that forgeries would occur (probably only
when some artists become popular), and when this becomes a problem
the author will use public key encryption to demonstrate the
authenticity of the file.

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

Players request all files of the same name. The meta data determines
which one will be presented to the player (and the ordering of
alternatives when the player decides to review them). However,
player selection/rating decisions can validate the files to some
extent, e.g. "Yup, this one looks cool - can't prove it hasn't been
corrupted in some small or subtle way, but I'll use it for the time
being - it meets all my other selection policies".

If players are involved in validating the files, the bad files will
tend to get weeded out (including those with bad meta data).

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

The meta data provides the distinguishing information (valid or
not).

If the player subsequently discovers that "I've seen this before,
this ain't new!", or "No way is this Bill Smith's style", or "Who
put bloody coke cans on all the ice floes?" then the player will do
their dutiful bit of altruism and revert to the previous file (or a
better one). It'll just be a keystroke or two.

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

Hah. You know I've got a gripe with that nafphorism don't you? ;-)

If more than a few percent of file sharers were the enemies they're
made out to be then file sharing would have collapsed
immediately. RIAA simply cannot afford enough stooges (computers or
people) to pollute the MP3 file space faster than it's cleased by
the users.

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

That's right (although there is the 'artist signature' option).

However, once files are on the player's machine they can't
subsequently be tampered with. Once the player vets a file, it's
inviolate. Because of this, a file's integrity starts to become a
function of its host player's integrity. And then we open up the
idea of reputation systems (which nodes have particularly scrupulous
players, and how to measure and exchange measures of this), but
that's something to look forward to.

> You have a name space consisting of object names and associated
> meta data which does NOT guarantee uniqueness.

Granted. But, remember the raison d'etre is not uniqueness or
addressability, but quality and consistency. And because we're
dealing with public domain entertainment here we can cope with only
a good tendency towards q & c. Indeed, the people decide what's good
and what's bad; the people define their world.

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

Hmmmn. I thought a namespace was by definition a 'vocabulary',
i.e. without duplicates. Guess I'll have to revise my
definition. Sorry.

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

But, I do not attempt to suggest that my solutions represent all
solutions or the only ones, just the solutions (I reckon I have) in
my particular application. P2P object distribution is a BIG field
with a big solution space, I've just focussed on a narrow niche
example of how you could utilise a file sharing utility like
Gnutella.

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

If the map is produced as an export conversion from X3D, then that
conversion will have been done on one node. It matters little if
there were minor X3D discrepancies between participating players
(and this assumes that the p2p player validation aspects will result
in a tendency towards consistency). These conversions can be done on
a regular basis by all players, and if there is a particular recent
conversion that more than one player has then the others can request
it.

Players wanting to play in the same area will tend to be those that
have a good ping (no one wants a laggy game) this means they are
also likely to be proximate in the p2p topology. It is thus likely
that their selection policy will be mutually supportive as far as
virtual world consistency goes (if it isn't, they'll learn to
migrate towards such a policy).

I can just tell I'll be accused of hand-waving...

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

Nope. This is social cybernetics. The identity aspects are not as
important if identity failure can be repaired. Ask RIAA.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev