On 31/08/10 18:56, [email protected] wrote:
One last thing, possibly of interest to the folks in VWRAP:
Another thing that happened to OpenSim as it reached 0.7 was the
reconceptualization of the software itself. As a consequence of this
reconceptualization, interoperability architectures such as the
Hypergrid are built as optional components that don't affect the core of
the walled-garden code.
As such, for those who don't like the Hypergrid for whatever reason, you
can experiment with your own ideas of interoperability without having to
tip toe around it. I suggest you understand HG1.5 first, as not to
reimplement it again. Then, if what you want to do is really different,
and not just a layer of *policy* above HG1.5 (policy specifications will
be supported soon), follow the same philosophy of modularizing things
properly, as that will give your architecture a chance for people to use
as plugin. If you run into a missing hook, just let me know.
Bottom line wrt interop, two major things happened: 1) the hypergrid
1.5, a system-to-system (S2S) architecture with the trust/security model
explained below; and 2) the clean up of the framework, allowing anyone
to experiment with interop.
Yeah, I'd really like to +1 this. If people want to experiment with alternative solutions to Hypergrid on top of
OpenSim we're very happy to make or accept patches for the required modularity. And if a core OpenSim developer
supports and maintains an alternative solution then there's no reason that it couldn't be part of the OpenSim itself,
provided that it's sufficiently general. OGP code for instance, is still present in OpenSim.
Hypergrid is a very interesting architecture but I think that Diva would agree that it isn't regarded as the 'one true
OpenSim way'. There's clearly a lot of experimentation that has to be done in this whole area before a good solution or
solutions will emerge (presuming that they are possible at all).
Like Diva, I also think that good standards very often only come out of working implementations. Hence, though I've
been following the VWRAP lists (and OGP before that) I haven't been participating since there's been a lot of
hard-to-follow discussion without much real-world consequence. And as a working developer I don't have the luxury of
sitting on my tush and contemplating the Platonic world of future standards all day ;) (joking).
[email protected] wrote:
One more thing, a bit less important than the others, as the others
pertain to grid-level content, and this one pertains to user-level
content:
- WRT to the user agent itself (i.e. name, appearance, etc.), the
user's user agent service (a grid-level service) is the party
responsible for creating user agents that are launched at foreign
grids. As such, that component is the authority that defines what
agent data to send. If the user agent service of one grid so wishes,
all of its users' agents can be anonymized and stripped off their
clothes before going out.
- HG 1.5 has another, symmetric, grid-level component called the
Gatekeeper which has the role of deciding what comes in to its grid.
So if the Gatekeeper so wishes, it can anonymize all foreign user
agents and strip them off their clothes before allowing them in.
In other words, the user agent service and the gatekeeper service are
the yin and yang of the Hypergrid.
[email protected] wrote:
[unrelated to the narrow issue at hand, but since people want to
know, here goes]
HG 1.5 has a trust/security model. The base case is one where grids
are peers, and the traveling of one user agent from his home grid to
another establishes the *base trust* in the following manner:
- Everything that the agent references from his home grid is made
available to the foreign grid where the user is. In other words, the
user is the driver of trust.
- Everything else that is not referenced by the visiting agent is out
of reach. "Out of reach" is a soft security model, i.e. the resources
are available on the internet, but you need to know their identifiers
in order to get them. Their identifiers behave as capabilities. This
is the part that still needs work, as Melanie thinks 'soft' is not
enough.
This trust model is the base upon which trust policies can be
defined. In other words, we now have the basis to add additional
grid-level specifications that overwrite the user's actions.
Melanie wrote:
Hi,
HG 1.5 doesn't address these concerns. Also, please remember that
assets need to be freely available to all, else they can't be
displayed. The observer gets a copy, too.
Animations, textures, sounds, etc. need to be given to all observers.
Melanie
Mike Dickson wrote:
Right. I think some of the use cases related to how content is shared
have been glossed over. In a completely open model which is what has
been discussed this is all pretty straightforward. But if I'm running
an asset service (as part of a grid or separately) I might want to
provide access controls as part of that service. The same with user
services. I may have a trust relationship with one agent service and
allow content to be transferred to agents that service represents. But
for another agent service for which no such relationship exists I'd
like
to deny access to content. And even in the transfer case does the new
user get a new copy or a reference. That concept isn't supported
now but
in a distributed grid its an important distinction. I might wish to
know
that copies of objects rezzed in a simulator always come from a
specific
asset service.
In short I think how the security model works is way more important
than
a caching optimization being applied to a URI/URL. Its important to
understand what levels of trust between services are supported and
under
what conditions an access is supported. As an Agent Service I may
consider even the "Names" of my users to be confidential and only
to be
revealed to services for which a trust relationship exists.
Mike
On Tue, 2010-08-31 at 13:23 +0000, [email protected] wrote:
Hi,
As a content creator this concerns me. I believe if I license my
content to
an avatar, and then they go to another grid that any content
pulled should
be from the grid that I have the content loaded into. I think I
should be
in control of my content. I also think I should be able to block
grids that
my content is being accessed from. If you don't always maintain the
original content location there will be no control. If I give
someone a
copy of my content, then that is something else, they are now the
owner of
it and are free to do as they please with it, at least within any
license I
give them. But that is a legal stuff not a technically programmed
one. At
least I don't expect all situations to be programmed.
Also when asset services start happening this will become more of
an issue.
I will have XRMarketplace.com live soon and plan to start selling
content
and provide that content as an asset server. How will I maintain
any kind
of control over the use of my content if people don't have to pull
copies
from me?
I also think, and haven't seen in the new hypergrid, if someone
goes to a
new grid I may not allow any of my content to go there unless that
avatars
gets an authorization from me which should be attached to his
proxy profile
for access into my grid/asset server.
The other thing to think about is how updates or corrections are
propagated.
SL has a terrible system of only supporting copies so any updates
or copies
have to be sent to everyone. Seems content replacement needs to be
supported and if content is all over the place this will get even
crazier.
Also to support dynamic content there needs to be a ways to
refresh or
update content. I suggest there needs to be an expiration date on the
content just like how images and HTML pages on the web work so
that cached
content will know to pull a new copy. And if the expiration date
is 0, at
the time it was pulled, it will always get refreshed.
This is maybe should have its own discussion thread but seems to
be part of
how this is all going to work.
M.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Ai Austin
Sent: Tuesday, August 31, 2010 4:17 AM
To: [email protected]
Subject: Re: [Opensim-dev] Global identifiers
myticaldemina makes a lot of good points... one thing that could
be problematic though relates to this comment...
From: <[email protected]>
...I would suggest any
proxies would give the external system and identifier and not
chain proxy
to
proxy unless there is a reason to do it, and the assets should be
copied
>from the original source.
I agree with the first half... no chains, just hand over the
external system "authority" and its given identifier pair for the
identity involved.
But I don't agree at all with the idea that you then have to get
the asset from that original authority. The permissions could have
changed, corruptions could have occurred or much more likely the
authority simply will no longer be there. The asset "as is" (with
its textures, scripted content and what not) should be provided to
the destination location/grid if the object permissions allow it,
with proper transfer of the permissions to next owner exactly as
if an avatar to avatar transfer or rez in world took place on the
local grid, without trying to reload the asset from an original
source.
.
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
