[vwrap] Hello world
Cristina Videira Lopes <lopes@ics.uci.edu> Tue, 31 August 2010 19:50 UTC
Return-Path: <lopes@ics.uci.edu>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 726033A6A76 for <vwrap@core3.amsl.com>;
Tue, 31 Aug 2010 12:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No,
score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001,
HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZXLvRz0BT7L for
<vwrap@core3.amsl.com>; Tue, 31 Aug 2010 12:50:10 -0700 (PDT)
Received: from david-tennant-v0.ics.uci.edu (david-tennant-v0.ics.uci.edu
[128.195.1.174]) by core3.amsl.com (Postfix) with ESMTP id B95A93A6A8C for
<vwrap@ietf.org>; Tue, 31 Aug 2010 12:50:09 -0700 (PDT)
Received: from tagus.ics.uci.edu (barbara-wright.ics.uci.edu [128.195.1.137])
by david-tennant-v0.ics.uci.edu (8.13.8/8.13.8) with ESMTP id o7VJoWkp016402
for <vwrap@ietf.org>; Tue, 31 Aug 2010 12:50:32 -0700
Message-Id: <1F8EA561-D5EE-4673-978A-A2A5814684CD@ics.uci.edu>
From: Cristina Videira Lopes <lopes@ics.uci.edu>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary=Apple-Mail-122-34354473
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 31 Aug 2010 12:50:32 -0700
X-Mailer: Apple Mail (2.936)
X-ICS-MailScanner-Information: Please send mail to helpdesk@ics.uci.edu or
more information
X-ICS-MailScanner-ID: o7VJoWkp016402
X-ICS-MailScanner: Found to be clean
X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.362,
required 5, autolearn=disabled, ALL_TRUSTED -1.44, HTML_MESSAGE 0.00,
TW_VW 0.08)
X-ICS-MailScanner-From: lopes@ics.uci.edu
Subject: [vwrap] Hello world
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group
<vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>,
<mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>,
<mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Aug 2010 19:51:34 -0000
Thanks, Josh! I'm signing in to this ML with my other identity, Crista Lopes @ UCI. So don't be confused, I'm the same person behind diva@metaversink.com , and 'diva' is my pseudonym for all things open source. Here's my introductory message. I'm a core developer of OpenSimulator, and the main architect of the Hypergrid -- but by no means the only one. As you may have heard, OpenSim reached its 0.7 version a couple of months ago; it was a hard, painful labour with foundation work taking priority over feature work. But it's here, and it uber-rocks! I can't stress enough the social impacts of the rewrite of the framework. What we had before was a straight jacket for innovation, and would have led to horrible clashes of the titans (read forks), as people have very different ideas about what to do with virtual worlds. One of those contention points was interoperability between virtual worlds. All that is now free of contention! The OpenSim framework doesn't impose anything at all, and these virtual worlds can load any network connectors and security checks that people plug into them. Now that the code is out of the way, the only agreements are those that groups of people *voluntarily* decide to agree upon. With the comfort of knowing that, if agreements are not reached, we don't need to fork the core code that does simulation, we just need to provide different plugins for people to use. (Not that I'm advocating disagreement, but it's always good to have a solid Plan B) Having that as stepping stone, we continued to work on the Hypergrid architecture, which is now in its 1.5 version, and has a decent trust/ security model -- as opposed to 1.0 which had a deficient trust/ security model. I'll be happy to explain how it works, as I'm working on a paper that does that. I know some of you here in this group felt insulted that I didn't join VWRAP when it was created. I stated my reasons at the time, which boiled down to three points: (1) lack of time -- it was either working on code or working on standards, but not both; (2) my impression that the effort of defining standards for VWs was premature, because there were no concrete solutions for interoperability, not even HG1.0 much less OGP, and people would better invest their time in implementation efforts; and (3) my impression that Linden Lab was using this group as a marketing tool. Things have changed (except for (1) lack of time... :-). So here I am. Best, Crista ----------------- • From: Joshua Bell <josh at lindenlab.com> • To: diva at metaverseink.com, "vwrap at ietf.org" <vwrap at ietf.org> • Date: Tue, 31 Aug 2010 11:28:37 -0700 (Dropping opensim-dev from the distribution list - cross-posting between moderated lists is not ideal, and the conversation tends to be quite hard to follow. My apologies if this makes it worse.) Thanks for dropping in, Diva! This discussion is completely within the bounds of the VWRAP charter, so it's perfectly welcome on the vwrap at ietf.org list, if it's being done with an eye towards encouraging independent implementations. Don't feel that you're intruding at all - quite the opposite! This would be a great place to hash out details of security/trust models and protocols for data transport between virtual world instances, with the benefit of input from other list contributors who have experience in related areas. That's what this working group is chartered with, after all. As an example, over on the opensim-dev list branch of this thread, I noticed some conversation about the global identifiers that implied parsing URLs to extract data, rather than treating them as opaque references to resources. That's generally considered a big "no-no" and runs contrary to the collected wisdom of the IETF for several reasons (that I'm sure folks will be glad to enumerate), and there are alternate patterns that should be followed. Hopefully, input on that level would be appreciated - if so, please do take advantage of this forum.
- [vwrap] Hello world Cristina Videira Lopes