Talk:Viewer URI Name Space

Does this mean that no region can be named 'app'? Phoenix 17:27, 23 July 2007 (PDT)

Yes, no region can be named "app". I had to pick some prefix, this one seemed reasonable. Unfortunately, also any string starting with secondlife:// can be legally parsed as a region name. James 08:54, 24 July 2007 (PDT)

I think this is a really bad direction to start down -- it artificially limits our usable space. I think we should instead make a new protocol for local resources, or make a more general url syntax. For example:

slclient://locally/available/resource

or

secondlifegrid://localhost/locally/available/resource

Phoenix 09:39, 24 July 2007 (PDT)

I agree with Phoenix here. Extending the secondlife: scheme is a mistake, since it's already well defined what it means:

"Via the Second Life protocol I am access Region Foo at x,y,z"

Mozilla uses the uri scheme chrome for "locally accessable resources that are accessed without knowing their precise filesystem location".

secondlife:// as a region name is actually okay. In URI form, it would be secondlife://secondlife%3A%2F%2F/1/2/3

From what I can tell, something like slchrome:// or slui:// would be better.

Mark 10:07, 24 July 2007 (PDT)

Yes, I see your point and agree. I initially chose secondlife:// for expedience, as the installer already registered it on all platforms, the embedded mozilla already had callbacks for the links, etc. But we need a different protocol for this type of command.

I'm going to use slclient:// because the word "client" is probably more understandable to an end user (who might see the raw link in a browser warning dialog) than "chrome" or "ui".

James 10:30, 24 July 2007 (PDT)

---

Well, while it is ugly, and unfortunate, I don't think a "one-time" fix of inserting "/app" at the top level is that bad. I think there are plenty of downsides to creating another scheme identifier. A way to make this more palatable is to fix the top level of the path, so whereas before you had:

secondlife://Obscure/123/98

you'd now have:

secondlife://location/Obscure/123/98

The old one would be deprecated, and yes, regions with the name "app" or "location" or whatever else we put a the top level wouldn't work with the old style.

The primary reason for having a scheme is that it is the way to get an operating system to open up another application with a class of URIs. Hence, everything in such a URI namespace is really the name for something the running viewer can do. We shouldn't use the secondlife: scheme to address elements of our network at all. Hence, I don't think the need for a top level '/localhost' in the examples above.

Since the scheme is entirely for the purpose of directing the viewer, it is reasonable to think of all those resources named as actions or concepts in the viewer. In otherwords, the URI

secondlife://event/<uuid>

should be though of as the viewer's concept of that event in our system. And this should conceptually distinct from, say:

http://services.agni.lindenlab.com/event/<uuid>

which would be a reference to the event resource back at the grid.

As such, such URIs really should only imply viewer actions on those objects: I could see secondlife: URIs that open an event in the viewer (but one wonders why?), but not one that creates an event that way. For the most part, I think we should be steering such functionality to the web services.

Lastly, a big problem with the URI tree proposed is that it puts all content into global name spaces by type. In particular:

secondlife://app/parcel/<uuid>

implies that one can reach ANY parcel that way. This is bad as it forces us to think in terms of a single global list. Much better would be

secondlife://app/grid/agni/region-by-name/Obscure/parcels/<uuid>/view

Though, admittadly, the "/grid/agni" part may be overkilll.... but perhaps not...

ZeroLinden 10:38, 24 July 2007 (PDT)

---

The primary motivation for this is to make clicking on links in a Find All search results page (output by Google Search Appliance) show SL UI with details on that data. Even if we move that data display to HTML, we'll still need a way to have links/buttons that offer teleports, open the IM window, etc. So we need a commmand format.

At the time the parcel links in the HTML pages for search are made, I do not have access to the region name or other information other than the UUID of the parcel. For example, top picks only store the parcel UUIDs. I could thrash the database during the static HTML page generation for search to look up the region names for each parcel UUID I encountered, but that seems a waste of effort to me.

I could imagine having special links that opened, say, the event UI as a useful way to share references to information in our system, on outside web pages, in our own IM, and in tutorials. Since I have to do some internal link management for search, it seems reasonable to me to expose those URLs to the outside world.

I would prefer to reserve the words "event", "classified", "place", "parcel", "agent", "resident", "person" and "group" as being invalid region names. secondlife://agent/<agent_id> looks cleaner to me than secondlife://app/...

Without slclient://, all these links are working now. Do we really want slclient://? Also, our entire system for places/events/top picks currently stores only parcel ids. I'm not thrilled about embarking on a huge refactoring of this system just to get search to work.

James 10:56, 24 July 2007 (PDT)

Non-Standard

Bah! I can't believe I didn't notice this before: Our syntax doesn't follow the recommended syntax for path based URI schemes! It should start with three slashes, not two, like file: does. This is because the thing after the double slash is the authority section, containing a hostname and port (and other stuff optionally as well...).

It might be worse - depending on one's reading of section 3 of RFC 3986, our use of double slashes without an authority section could be seen as illegal. Of course, we could claim that the region name or "app" was the authority (and hence host).... but I bet w don't follow all the proper conventions for host names. Fie!

See http://tools.ietf.org/html/rfc3986

ZeroLinden 15:33, 6 September 2007 (PDT)

---

James writes:

Looks like secondlife:/// is what we want. My only concern would be that crappy IRC clients and other programs that attempt to automatically identify URLs in text would choke. Colloquy does it correctly. I will try other clients in the office tomorrow.

Changing to secondlife:/// is trivial in my code. Any reason I shouldn't just do it?

---

Well, we have to continue to handle the existant URLs. So perhaps we take this moment to "fix" the whole scheme:

secondlife://<region name>/<x>/<y>/<z>
 -- old style, still accepted

secondlife:///viewer/go/<region name/<x>/<y>/<z>
 -- new style, with well defined rules about encoding region names

secondlife:///viewer/agent/<agent_id>
secondlife:///viewer/group/<group_id>
 -- etc., the controls being added for search
 -- (that these are an implicit "open a floater on this item" verb is a little odd,
  what's the URL for "IM this line of text to this agent"?)

secondlife:///viewer/login/...
 -- the login work for web site auth.

ZeroLinden 08:57, 7 September 2007 (PDT)

---

I will of course support legacy URLs. I see no strong reason to switch from "app" to "viewer". Likewise, my initial syntax for agents/groups/etc. is of the form:

 secondlife:///app/agent/<agent_id>/about

Where "about" is the verb. Thus we can add "im", "offer-teleport", etc.

Any reason I should not just implement secondlife:///app/agent/<agent_id>/about ?

James 09:57, 7 September 2007 (PDT)

Question About secondlife:///app/chat/channel/text

I tried "secondlife:///app/chat/0/Text" And That Worked But How Do You Get More Than One Word? I Would Like To Use It In A Hud For Staff At A Club When The Hud Will Fill In The First Name Of The Person Into Some Standard Greetings And Information. But Escaping The Text And My Character Will Of Course Say It With It Still Escaped. Ive Tried A Few Ways Hoping Something Would Work But Get Only The Forst Word Or Nothing At All, Its A Rainy Day Project

 llOwnerSay("Click To Speak:  secondlife:///app/chat/0/Testing, Testing 123");//Says Testing
 llOwnerSay("Click To Speak:  secondlife:///app/chat/0/" + llEscapeURL("Testing, Testing 123"));//Says Testing%2C%20Testing%20123
 llLoadURL(llGetOwner(), "Click To Speak", "secondlife:///app/chat/0/" + llEscapeURL("Testing, Testing 123"));//Nothing Happens
 llLoadURL(llGetOwner(), "Click To Speak", "secondlife:///app/chat/0/Testing, Testing 123");//Nothing Happens

Adi 07:12, 8 August 2010 (UTC)

URL Escaped?

Someone tell me if I am testing this wrong, since this article says it is URL escaped.

If I click: secondlife:///app/chat/0/foo%20bar

The result is as follows:

[11:46:03] kizmut Smit: foo%20bar

Kizmut Smit 18:47, 23 August 2010 (UTC)

---

Example Corrections

I was trying the old script on here and noticed it does not work it either came back with Syntex Error or said Object: Touched by (nobody).

Original Code

string Who(key id)
{
    return "secondlife:///app/agent/" + (string)id + "/inspect";
}
 
default
{
    touch_start(integer n)
    {
        llSay("Touched by " + Who(llDetectedKey(n)) + ".");
    }
}

Reworked Code

string Who(key id)
{
    return "secondlife:///app/agent/" + (string)id + "/inspect";
}
 
default
{
    touch_start(integer n)
    {
        llSay(0,"Touched by " + Who(llDetectedKey(0)) + ".");
    }
}

Kobra Stein 11:43, 12 January 2013 (PST)

Note that the original code was certainly a typo; unless, of course, a lot more had been eaten up by gremlins, e.g.

string Who(key id)
{
    return "secondlife:///app/agent/" + (string)id + "/inspect";
}
 
default
{
    touch_start(integer n)
    {
        integer i;
        for (i = 0; i < n; i++)
        {
            llSay(0, "Touched by " + Who(llDetectedKey(n)) + ".");
        }
    }
}

In practice, however, that code would be overkill (it's not easy to catch several avatars simultaneously touching the same object). Your own solution is much more reasonable.

— Gwyneth Llewelyn (talk) 11:00, 2 February 2023 (PST)

Confusing WikiSyntax explanations...

I was going through this article's history to see if I could understand the point about the strange explanations regarding the usage of <nowiki>...</nowiki> tags around the secondlife:// URIs; I couldn't even understand what the <nolink> tag is supposed to do, since it doesn't seem to be defined anywhere (aye, I did search for it elsewhere, and got no results).

Also, there was a cute *~ NISA ~* message at the end — allegedly showing what is supposed to happen when clicking on a group link. The meaning of that remains obscure to me (it's possibly a private joke of some sort? Maybe @Tapple Gao, who originally wrote that, might explain it to us).

My presumption, therefore, is that these instructions were written on behalf of potential SL Wiki volunteer writers; however, the way they were rendered didn't make any sense to me (I know, I know, below-average IQ here!), so I attempted to do a full rewrite (and also drop the <nolink> tag reference, since it doesn't seem to be relevant for Mediawiki-based wikis...).

If you believe I got it wrong, please make whatever corrections you deem to be necessary! 😊

— Gwyneth Llewelyn (talk) 12:04, 2 February 2023 (PST)

About the "authority" in the secondlife:/// URI, and why it might be a good idea to reuse it...

The very early reference to RFC3986 mentions that the reason we have three slashes on the "revised" URIs is for strict adherence to this RFC, which states that, following the first two slashes, there should be an authority identifier. On the Web, of course, URLs use as the "authority" the FQDN of the machine running the webserver, e.g. server.example.com.

As mentioned in the early comments, in the case of the Second Life Grid, there is just one authority, which is the Second Life Grid itself (as a whole), so one might argue that no "authority" field is necessary — consequently, it is left empty, thus the triple slash.

Now, one might argue that, at the time these discussions among the Linden developers (that were so kind as to preserve for all eternity their reasoning around the implementation here on the Talk Page) were made, Second Life had two publicly open grids, agni ("main grid") and aditi ("preview grid"), besides a few others which some lucky residents stumbled upon by sheer chance, and which are not meant to be ever public — but just for Linden Lab's private purposes (such as doing experiments that are too dangerous even to place on the preview grid).

While, technically speaking, these two (or more) grids are separate and independent, probably with their own asset servers and all, there is a common thread binding both (or all): they run Linden Lab's software, are maintained by them in exclusivity, and the physical hardware where they are running is legally leased by Linden Lab. As such, there are no other parties that could be considered to be "authoritative" over what information is retrieved by these URIs.

Fast-forward just a couple more years (the discussion here is from ca. 2007), and suddenly OpenSimulator grids start popping up like mushrooms.

For all purposes, they run on totally independent infrastructure, which is not even closely related to LL's own, and their server software is merely a reverse-engineered solution based on the communication protocol between viewer and simulator — which has been thoroughly documented, especially since LL made the viewer code public and open-source. While it's almost certain that LL's own simulator code is completely different (it's not even written in the same programming language as OpenSimulator...), they at least share a similar (if hardly identical) networking infrastructure. Thus, secondlife:// URIs, as interpreted by the TPVs, will also work to retrieve essentially the same information — much of it being implemented at the viewer level anyway — just for a different grid.

There is an additional twist.

The grids hosted by Linden Lab — with the possible exception of the discontinued Teen Grid — are essentially isolated from each other: you cannot teleport from agni to aditi, for instance, even if both run software developed and maintained by Linden Lab. Instead, you have separate accounts on the two public grids, and not even Lindens are able to jump from one to the other. They're not "connected", in the networking sense of the word.

But, by contrast, for a long, long time, OpenSimulator grids are interconnected. While this is strictly a voluntary setting/configuration — OpenSimulator grids can be as isolated from the rest of the multiverse as their owners/maintainers wish them to be — the majority of all more popular grids, as well as many not-so-popular ones, use HyperGrid jumps to do cross-grid teleporting. Linden Lab experimented with that technology, strongly encouraged by IBM (and, to a degree, Intel as well) during a very short period of time when Linden Lab was open to the idea, and they went so far as to develop and standardise the so-called "Open Grid Protocol" (OGP) and setting up a task force to tackle the definition of a cross-grid communications protocol that all parties could accept.

Needless to say, OGP was a child of the Golden Days of the exponential growth of SL, of its lack of market regulation, of griefer clashes, and, of course, of corporate virtual presences, mostly worried about the impact "their" build in SL would have on the media. As the media's interest waned, and as LL got rid of all the speculators, casinos, Ponzi schemes, and other wild concepts, the corporate presences also faded away and essentially retreated into private islands without any public access (according to Linden Lab, at the time of writing this comment in 2023, there are still some 700+ organisations in SL — between corporate and academic — most of which have zero interest in giving public access to their islands).

While IBM's interest in SL faded, Intel still maintained a strong presence — but on OpenSimulator instead, where they could tackle difficult challenges (such as how to get a thousand avatars simultaneously in the same region) since OpenSimulator's source code was open-source and very easily acquired. They contributed a lot of code, and even had one or two employees working full-time (or at least a substantial part of their work time) to contribute code to OpenSimulator — and fixing the odd bug or security flaw on the official SL viewer.

OGP was, for all purposes, abandoned. It's still a module that comes with every version of OpenSimulator, and enabling OGP is trivial. Some, like me, keep it around just for the infinitesimal chance that someone at LL wants to pick up the project as it was 15 years ago. The major issue was, of course, how to safely carry content across grids. "Safely" in this scenario means "without the possibility of having such content illegitimately copied by malicious third parties" (downloaded either with a "special" viewer — many of those are still around, in spite of the conjoined effort by many parties to squash them down — or also by a "rogue" grid operator, who would easily extract whatever content they wished from their own server databases). The solution, according to LL and IBM, was to deploy very strong cryptography and creating a "web of trust" around digital certificates (which would possibly be generated by IBM — and not Linden Lab! — merely because, at that time, it was simply too hard for grid operators to trust LL as a "certificate authority". The last time I checked, the OGP workgroup had set the basics down — indeed, some prototype jumps were made from the preview grid to OGP-enabled OpenSimulator grids, without any content or inventory whatsoever (welcome back, Ruth!) — and were furiously discussing how to set up a public-key infrastructure (PKI) which would allow webs of trust to be created between the many grid operators, without the need of a central "authority".

(The irony is that, a few months later, a certain mysterious character, going by the very-avataresque nickname "Satoshi Nakamoto", launched Bitcoin — where such issues as mutual trust of cryptographically-generated digital certificates are at the very core of the technology. A fortunate coincidence?...)

Well, since this whole process was taking too long to accomplish, the OpenSimulator community came up with their own concept, HyperGrid jump, which went through several revisions and iterations. Today, this allows perfectly seamless teleports with all allowed content to be (temporarily) transferred to a different grid; I'm always surprised at how well it works. Users can add friends on different grids, and can subscribe to groups on those as well (I'm not quite sure about land ownership, though); objects created on different grids by different creators, so long as they have the appropriate permissions, can be linked together; profiles can be made public, no matter on which grid they're located; and web-based content marketplaces can deliver items to any grid (again, so long as such permissions are granted by the content creators themselves).

But I digress. The point is that HyperGrid jump-teleport introduced its own URI, the hop://. But, in this case, it's not enough to use the region name and the coordinates within that region; you also need to add the grid's login server. A hop URI, therefore, has an authority — the grid where that region is supposed to be, and which is under the control of its grid operator.

Everything else in OpenSimulator has "extended" names, using the ubiquitous '@' character, to separate the avatar's name (first and last) from the grid it comes from. The same logic is applied to everything where, on Second Life, just an avatar name is shown; in a sense, HyperGrid is a concept in itself not very different from what later became the "Fediverse" around Activity Streams 2.0 (read: a federation of Mastodon-compatible social media), or what was already popular with Jabber/XMPP and even {{abbr|IRC|Internet Relay Chat].

Thus, thanks to HyperGrid, we have a Metaverse accessed through the SL Viewer (or, rather, a TPV, since LL disabled that ability on their own viewer, by choice and due to the Havok licensing issues) where the concept of "URI authority" is quite well defined. There is just a catch — hops are just meant to be used for intergrid teleporting. Inside a specific grid, the usual secondlife:/// scheme is used to retrieve information regarding the local grid where the avatar currently is, as well as any relevant information regarding that specific avatar (and their origin). It's up to the SL Viewer to figure out when to apply one secondlife schema to the current grid or to the avatar's origin grid; this is clear from the context in most cases, but... why should it be so?

Wouldn't it make so much more sense to universally use the secondlife scheme, but immediately followed by the authority that such an URI is supposed to be pointing at?

It might be argued that such URIs, if implementing the whole API, might be a pain to type; and that any change right now may break old content. I'd reply to that by establishing an exception for existing content not to break, namely assuming that, if not explicitly set, the "default" authority would be taken to mean "the current grid we're in right now".

One possibility would be to use what OpenSimulator, in its configuration file, calls the "short grid name", which is not much used — usually just a word of about 6 letters or so, describing the grid. "agni" and "Aditi" are obvious for SL; "OSgrid" is obviously the one used for the OSgrid. These are supposed to be unique short names, but, lacking a "central authority", a registry of sorts, currently that's not guaranteed. However, it could be — for starters, a simple lookup service could be enough: grid operators register their grids through an online form, and a simple KVP store could hold the hundreds (or thousands) entries very easily. Later on, some improvements could be done, such as dealing with redundancy and "always on" services... the point is, it's doable.

Granted, in such a scenario, probably a scheme named secondlife: makes little sense, especially when used in places that are, for all purposes, technically outside the Second Life Grid. We should therefore come up with something different — something that does not violate any of Linden Lab's registered trademarks...

— Gwyneth Llewelyn (talk) 20:47, 11 October 2023 (PDT)