[Opensim-dev] [Proposal] Expanded Grid Info Availability

Tue Aug 1 23:49:42 UTC 2017

At the IMA's Commerce Working Group we are discussing developing a
blockchain standard, if not an actual blockchain, that would be useful for
making a lot of user-centric data (like UUIDs, user content licenses, money
etc) independent of any one grid, decentralized so that users can
communicate with and do commerce with other users.
In my teams work at http://galacticsystems.net, we have found difficulty
finding consistency across the hypergrid in issues like email modules,
http-request functionality, not to mention the perrenial teleportation and
IM issues. We feel that grids should focus on hosting worlds, and let users
control their identities, commerce, and interactions, secured
cryptographically by blockchain technologies.
One example of the problems inherent with having user registration on a per
grid basis is in commerce:
If I am shopping on a gloebit or podex mall somewhere on the hypergrid, I
can buy things from vendors for myself. If I want to gift content to
people, the vendor must be specifically coded to allow that, and unless the
customer knows the UUID of the recipient of their gift out on the
hypergrid, unless the recipient is a resident of the grid that vendor is
located on, there is no way for the vendor to use a script function to
request the UUID of that avatar across the hypergrid.

I would propose therefore, to make commerce work better, for all sorts of
uses, there be a function osGetHGName2Key( string user.name, string
gridURI);  The script would query via Robust the indicated grid for the
UUID of the indicated user name, and return it to the script.
Some might say "but thats a privacy issue". Sorry, no it isn't. If I can tp
to a grid on the hypergrid, look up their profile in that grid and see
their UUID key on their profile dialog, the UUID is not a private key. If I
can create an account on a grid without providing any relevant information
about myself, log in, and look up a name and get their key off their
profile, it is likewise, not a privacy issue, even if it is a closed grid.

On Tue, Aug 1, 2017 at 7:28 PM, David Saunders <abitar.com at gmail.com> wrote:

> Hey,
>
>  I can assume it is because that how the region registers itself :) It does
> send the IP to the client tho.  :)  And we have had dynamic IP hosting our
> sims at one time, We would have to reload the firewall when it changed. And
> then it works :) But this is because we white-list simulators to our grid.
>
> I was looking at some ideas from
> http://opensimulator.org/wiki/Category:OSSL_Functions , but the problem is
> how are you going to know the correct verification URL, if the regions
> tells you what it is?   Only way if you start with a verified URL.  The
> script it self can find out what grid its on. So you really need to know
> the grid has set up this check for you to have any kind of confidence in
> having the script tell where it is :)  You can send the info needed by the
> script.
>
>
>
>  DAvid.
>
>
>
>
>
> On Tue, Aug 1, 2017 at 5:00 PM, Haravikk <opensim at haravikk.me> wrote:
>
> >
> > > On 1 Aug 2017, at 17:28, David Saunders <abitar.com at gmail.com> wrote:
> > >
> > > One thing that might be nice is the ability to add more X headers in
> the
> > > config file. (I never needed it to be added before but can think of
> some
> > > need for it ) .  This way in the future when grid ops need another
> > x-header
> > > they don't have to crack open the code and modify.
> >
> > That's a neat idea, I can certainly look into adding that at the same
> time!
> >
> > > UUIDs across grids would be nice except for who will control it? And
> who
> > > will keep it from being polluted?   It also will put a new overhead on
> > the
> > > robust, for each object gets it own UUID, each copy of its own. So
> think
> > of
> > > having 10 avatars, building a region, each putting down a object in the
> > > region. The region would have to call the central resource, could call
> > > 100/min easy, Then put in an active grid, we can have 20-30 people
> > > building across the grid at once.  If we have to make an internet call
> > to a
> > > server , would add a new bottle neck into the cog of things.
> >
> > I'm not proposing to introduce true GUIDs; in fact part of the idea
> behind
> > making the grid address more easily available is that it would eliminate
> > the need to do so, as you can easily resolve conflicts by comparing
> grids.
> >
> > i.e- if your device(s) encounter two avatars with the same key, but
> > different grid addresses, then you can treat them as different if you
> want
> > to.
> >
> > It is however an area I've thought a bit about, but as you say, a
> > challenging one technically as the last thing anyone wants to have to
> have
> > some complex cross-grid communication going on. My main concern is just
> in
> > making sure I know two UUIDs are either definitely the same, or probably
> > not, anything beyond that does get pretty complicated!
> >
> > > you can implement immediately.
> > >    Just watch out for the snag of reverse dns may return the wrong host
> > > name.  You cant count on a few host names, osgrid can have many 100's
> > and a
> > > simple grid can have 1 or 2.
> > > on our grid all the hosts are names and not IPs in the region table,
> And
> > > should reverse back to us EXCEPT for remote hosted simulators  :)   So,
> > can
> > > be bit confusion on what you need to do.
> >
> > Any idea why they're stored that way? I suppose it might smooth out some
> > issues for simulators with dynamic IPs and such?
> >
> > I'd hoped not to have to do anything involving database modification, as
> > storing IP alongside dns name could be awkward to keep up to date.
> >
> > A possible alternative would be to have the simulator also send its dns
> > name as another header; this way the server can just do a regular
> (forward)
> > DNS lookup, which is faster and more reliable and confirms the IP of the
> > request before sending any query to the grid. If that's how the grid
> stores
> > region addresses then it'll be the easiest way to handle the query.
> >
> > > On Mon, Jul 31, 2017 at 9:49 AM, Haravikk <opensim at haravikk.me> wrote:
> > >
> > >> This is a subject very much related to my topic on IP and region
> > >> validation, and the proposal is very simple; the idea is to make it
> > easier
> > >> to find out which grid an object or avatar belongs to, as this is
> useful
> > >> for a variety of reasons.
> > >>
> > >> It's already possible to get this information with some os*()
> functions,
> > >> but they have a current threat level of Low or Moderate, placing them
> > above
> > >> the default of VeryLow and thus preventing them from being widely
> > >> available. However, I'm not convinced that the threat level of these
> > >> functions actually needs to be so high, as the information can be
> > obtained
> > >> by other means, it just seems like an unnecessary restriction on
> > scripts.
> > >> You can view the full proposal here:
> > >> http://opensimulator.org/wiki/User:Haravikk_Mistral/
> > >> ExpandedGridInfoAvailability
> > >>
> > >>
> > >> I'm interested in feedback about which functions should/should not
> have
> > >> their threat level downgraded, and also about my proposed addition of
> a
> > >> header on llHTTPRequests() that identifies the grid.
> > >>
> > >> In discussion on IRC there was a question raised about privacy,
> > >> particularly tracking between grids, but I'm not sure this is a
> problem;
> > >> currently hyper grid travels works on the assumption that an avatar's
> > UUID
> > >> is unique, which scripts are free to do as well, in which case they
> are
> > >> already able to track an avatar fairly reliably if they want to. Thing
> > is
> > >> though, to do this they'd need to have an external service in common,
> > and
> > >> devices spread about widely enough across different grids to get any
> > kind
> > >> of meaningful tracking, and even then, what can be done with this
> > >> information is fairly limited. Knowing what a user's home-grid is
> won't
> > >> make this any easier; the only difference is that with knowledge of
> the
> > >> grid you can be certain there is no cross-grid UUID collision (i.e-
> UUID
> > >> uniqueness is a bit less uncertain), it opens up no real capabilities
> to
> > >> track avatars that I can see, and there are better ways to prevent
> > tracking
> > >> that could be implemented if it were a problem.
> > >>
> > >> However, the advantage of having this information more readily
> available
> > >> is that it becomes possible for in-world devices to handle avatars
> > >> differently depending upon whether they are from the current grid or
> > not.
> > >> It would also, crucially for me, make handling of data on a
> web-service
> > >> much easier, as it becomes possible to easily partition data by the
> > grid it
> > >> belongs to, and to handle crossover (i.e- travelling avatars) more
> > >> intelligently.
> > >> _______________________________________________
> > >> Opensim-dev mailing list
> > >> Opensim-dev at opensimulator.org
> > >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> > >>
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > Opensim-dev at opensimulator.org
> > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at opensimulator.org
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>

-- 
Mike Lorrey
CEO Galactic Systems, Inc
VP Stokens Venture Capital
bntholdings at gmail.com <mike at tokens.vc>
mike at stokens.co
International Spaceflight Museum
mike at ismuseum.org
Skype: michael.lorrey
LinkedIn: https://www.linkedin.com/in/mikelorrey