[vos-d] VOS requirements

[Peter Amstutz]

On Thu, Feb 01, 2007 at 01:50:07PM +0100, Karsten Otto wrote:
> I finally got around to write some comments on the requirements  
> document. I reversed the numbering, since the last bit is the most  
> controversial.
> 
> 1.4.3. Authoring
> 
> "There shall be a bidirectional mapping between X3D and Interreality  
> 3D capabilities and semantics."
> 
> I assume this include Collada as well, and maybe other file formats?

Yes, ideally it should be possible to both import and export to these 
formats.  We could probably use the metadata/other extensibility 
features of these formats to incorporate as other VOS data as well.

> Can the mapping truly be bidirectional, considering that VOS contains  
> *more* information than just a scene graph? What about X3D scripting  
> and VOS scripting, is there supposed to be a mapping too?

What I had in mind was that you would be able to load up an X3D file 
complete with scripts, and that it would seamlessly translate between 
X3D data structures and events and VOS data structures and events, so 
that VRML/X3D would a mostly first class authoring language for 
Interreality 3D.  

> 1.4.1. Scripts and 1.4.2. Interactivity
> 
> This seems a bit unclear to me, regarding the role of the client and  
> server. Some passages seem to indicate server control, others  
> independent client-based simulation. How do these two fit together?  
> Does the server prescribe client interaction? Can the client ignore  
> any server commands?

It's fuzzy because the role of scripting is still a bit fuzzy.  Scripts 
actually would be able to fill at least two roles: implementing 
behaviors on the server (where it's just an easier alternative to 
writing a behavior in, say, C++) or implementing client-side interaction 
code (similar to the way that Javascript is used on web pages to improve 
the client side experience with everything from simple image rollovers 
to rich AJAX applications).

My biggest, absolute #1 concern with scripting is security and 
sandboxing, but after a couple of VOS prototypes where we tried to avoid 
scripting, I've come to the conclusion that it's largely unavoidable 
(Javascript and web forms are really what made the World Wide Web 
successful).

> 1.2 Multiuser Requirements
> 
> "Users shall be able to establish accounts which persist when the  
> user is not logged in."
> 
> This section is relatively open in *how* this works. I assume it  
> refers to a "traditional" user account database held at the servers  
> end. I've had may difficulties with that concept for some time now,  

Well, since this is the requirements document, it's mainly addressing 
the level of "what", not "how".  The purpose of this discussion is to 
identify everything everyone wants out of a 3D browser.  Then we can 
prioritize and start to hammer out concrete designs that can eventually 
be implemented.  It's a process :-)

> since it seems to me that it does not really scale. If you have a  
> single big world, or at least a central authority, this works fine.  
> But if you aim for a loose clustering of relatively small worlds, you  
> need an account on every single one of them. Its a big hassle for  
> users to create and maintain all of them, even if they just need most  
> of the accounts only to pass through most worlds.
> 
> My idea is to create a user profile once, and let the user carry it  
> around with them. The profile is a small VOS graph. It describes the  
> user, capabilities, current inventory, game state, RPG stats,  
> whatever, each aspect in a distinct subgraph. A server can add,  
> modify, and remove a subgraph independent from other subgraphs; most  
> importantly, it can also *sign* it cryptographically, to certify its  
> authenticity.
> When a user wishes to join a particular world, he uploads the profile  
> to the server. The server looks for subgraphs it understands/ 
> requires, and verifies that it is certified by itself *or another  
> trusted server*. The big assumption here is that neighboring servers  
> know and trust each other. If the profile lacks prerequisite parts or  
> cannot be verified, access is denied.
> When the users leaves the server, he downloads the (modified)  
> profile, to provide it to another server on its way. He can also keep  
> multiple copies of the profile on its private computer, sort of as a  
> "saved game" (thats what the idea was originally designed for).

I like this idea.  It harkens back to the original VOS design which was 
a lot more of a peer-to-peer system and users would "host" their own 
avatar.  It also reminds me of web cookies.  It seems to me there are a 
few issues, though.  For one, if you don't store a copy on the server, 
and the user disconnects unexpectedly, they may not have a up-to-date 
information (or maybe nothing at all).

Also, this means the user can't log in from anywhere, but has to always 
use the same account on the same computer because that's where their 
identity is saved, unless they also store their data on a server 
somewher where they can get it.

However, I do like the idea of some kind of single-sign-on identity, 
which could be client managed (i.e. something like a PGP key).  Then 
creating an account or logging into a site is just a matter of sending 
your public key and authenticating yourself, no "please choose a login 
name and password" bullshit required for every single site.  
Alternately, it would also be nice to integrate existing directory 
services like LDAP into VOS, so you could use existing user accounts for 
a particular site.

Ironically, identity management is probably the *easy* (or at least, 
mostly-already solved) part of security in VOS.  I'm very much 
struggling over how s5 security is going to look (access control lists?  
capabilities?  role-based security?) as well as the very practical 
challenges of sandboxing scripts, both client side (sent by a 
potentially harmful server) and server side (sent by a potentially 
harmful client).
 
> I originally designed this for RDF graphs, but VOS is similar enough  
> to transfer the idea. I also did some experimentation with this, on a  
> cluster of private servers, which worked out nicely. I also have a  
> paper on the idea, If you're interested I can post the PDF.
> 
> What do you think? Too radical? Utter nonsense? Comments welcome.

Please do post a link to the paper, I would like to look at it, 
especially if you addressed the concerns I have raised here :-)

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20070201/4b0afb0a/attachment.pgp