Talk:Viewer URI Name Space - Revision history

Gwyneth Llewelyn: /* About the "authority" in the secondlife:/// URI, and why it might be a good idea to reuse it... */ spellchecking and fixing wrong attributes

2023-10-12T09:30:12Z

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

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

2023-10-12T03:47:29Z

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

← Older revision		Revision as of 20:47, 11 October 2023
Line 221:		Line 221:

	— [[User:Gwyneth Llewelyn\|Gwyneth Llewelyn]] ([[User talk:Gwyneth Llewelyn\|talk]]) 12:04, 2 February 2023 (PST)		— [[User:Gwyneth Llewelyn\|Gwyneth Llewelyn]] ([[User talk: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 [https://www.rfc-editor.org/rfc/rfc3986#section-3.2 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 {{abbr\|FQDN\|Fully Qualified Domain Name}}, e.g. {{mono\|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, {{mono\|agni}} ("main grid") and {{mono\|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, {{mono\|secondlife://}} URIs, as interpreted by the {{abbr\|TPVs\|Third Party Viewers}}, 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" (either with a "special" viewer — many of those are still around, in spite of the conjoined effort by many parties to squash them down — but 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 {{mono\|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 {{mono\|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 '{{mono\|@}}' 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 ActivityStreams (read: a federation of Mastodon-compatible social media), or what was already popular with Jabber/XMPP and even IRC.

			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 — {{mono\|hops}} are just meant to be used for intergrid teleporting. Inside a specific grid, the usual {{mono\|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 {{mono\|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 {{mono\|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 '''the authority by default — 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 [https://www.osgrid.org/ 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 {{mono\|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...


			— [[User:Gwyneth Llewelyn\|Gwyneth Llewelyn]] ([[User talk:Gwyneth Llewelyn\|talk]]) 20:47, 11 October 2023 (PDT)

Gwyneth Llewelyn: /* Confusing WikiSyntax explanations... */ {{code|...}} chokes on angle brackets; using {{mono|..}} instead.

2023-10-11T20:41:05Z

Confusing WikiSyntax explanations...: {{code|...}} chokes on angle brackets; using {{mono|..}} instead.

← Older revision		Revision as of 13:41, 11 October 2023
Line 212:		Line 212:
	== Confusing WikiSyntax explanations... ==		== 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 {{~~code~~\|<nowiki><nowiki></nowiki>}} tags around the {{~~code~~\|<nowiki>secondlife://</nowiki>}} URIs; I couldn't even understand what the {{~~code~~\|<nowiki><nolink></nowiki>}} 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).		I was going through this article's history to see if I could understand the point about the strange explanations regarding the usage of {{mono\|<nowiki><nowiki>...</nowiki></nowiki>}} tags around the {{mono\|<nowiki>secondlife://</nowiki>}} URIs; I couldn't even understand what the {{mono\|<nowiki><nolink></nowiki>}} 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 {{mono\|~ 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 {{mention\|Tapple Gao\|p=}}, who originally wrote that, might explain it to us).		Also, there was a cute {{mono\|~ 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 {{mention\|Tapple Gao\|p=}}, 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 {{~~code~~\|<nowiki><nolink></nowiki>}} tag reference, since it doesn't seem to be relevant for Mediawiki-based wikis...).		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 {{mono\|<nowiki><nolink></nowiki>}} 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! 😊		If you believe I got it wrong, please make whatever corrections you deem to be necessary! 😊

	— [[User:Gwyneth Llewelyn\|Gwyneth Llewelyn]] ([[User talk:Gwyneth Llewelyn\|talk]]) 12:04, 2 February 2023 (PST)		— [[User:Gwyneth Llewelyn\|Gwyneth Llewelyn]] ([[User talk:Gwyneth Llewelyn\|talk]]) 12:04, 2 February 2023 (PST)

Gwyneth Llewelyn: /* Confusing WikiSyntax explanations... */ new section

2023-02-02T20:04:07Z

Confusing WikiSyntax explanations...: new section

← Older revision		Revision as of 13:04, 2 February 2023
Line 209:		Line 209:
	: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.		: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.
	: — [[User:Gwyneth Llewelyn\|Gwyneth Llewelyn]] ([[User talk:Gwyneth Llewelyn\|talk]]) 11:00, 2 February 2023 (PST)		: — [[User:Gwyneth Llewelyn\|Gwyneth Llewelyn]] ([[User talk: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 {{code\|<nowiki><nowiki></nowiki>}} tags around the {{code\|<nowiki>secondlife://</nowiki>}} URIs; I couldn't even understand what the {{code\|<nowiki><nolink></nowiki>}} 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 {{mono\|~ 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 {{mention\|Tapple Gao\|p=}}, 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 {{code\|<nowiki><nolink></nowiki>}} 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! 😊

			— [[User:Gwyneth Llewelyn\|Gwyneth Llewelyn]] ([[User talk:Gwyneth Llewelyn\|talk]]) 12:04, 2 February 2023 (PST)

Gwyneth Llewelyn: /* Example Corrections */ Added or else the code examples became unreadable... and added my own twist.

2023-02-02T19:00:28Z

Example Corrections: Added <syntaxhighlight> or else the code examples became unreadable... and added my own twist.

← Older revision		Revision as of 12:00, 2 February 2023
Line 154:		Line 154:

	'''Original Code'''		'''Original Code'''
			<syntaxhighlight lang="lsl2">
	string Who(key id)		string Who(key id)
	{		{
Line 167:		Line 167:
	}		}
	}		}
			</syntaxhighlight>

	'''Reworked Code'''		'''Reworked Code'''
			<syntaxhighlight lang="lsl2">
	string Who(key id)		string Who(key id)
	{		{
Line 183:		Line 183:
	}		}
	}		}
			</syntaxhighlight>
			[[User:Kobra Stein\|Kobra Stein]] 11:43, 12 January 2013 (PST)

	[[User:~~Kobra Stein~~\|~~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.
			:
			:<syntaxhighlight lang="lsl2">
			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)) + ".");
			}
			}
			}
			</syntaxhighlight>
			:
			: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.
			: — [[User:Gwyneth Llewelyn\|Gwyneth Llewelyn]] ([[User talk:Gwyneth Llewelyn\|talk]]) 11:00, 2 February 2023 (PST)

Kobra Stein: /* Example Corrections */

2013-01-12T19:47:52Z

Example Corrections

← Older revision		Revision as of 12:47, 12 January 2013
Line 168:		Line 168:
	}		}

	}

	'''Reworked Code'''		'''Reworked Code'''

Kobra Stein: /* Example Corrections */

2013-01-12T19:46:43Z

Example Corrections

← Older revision		Revision as of 12:46, 12 January 2013
Line 154:		Line 154:

	'''Original Code'''		'''Original Code'''

	string Who(key id)		string Who(key id)
	{		{
Line 170:		Line 171:

	'''Reworked Code'''		'''Reworked Code'''

	string Who(key id)		string Who(key id)
	{		{

Kobra Stein: /* Reworked Code */

2013-01-12T19:46:23Z

Reworked Code

← Older revision		Revision as of 12:46, 12 January 2013
Line 169:		Line 169:
	}		}

	== Reworked Code==		'''Reworked Code'''
	string Who(key id)		string Who(key id)
	{		{
Line 183:		Line 183:
	}		}

	--[[User:Kobra Stein\|Kobra Stein]] 11:43, 12 January 2013 (PST)		[[User:Kobra Stein\|Kobra Stein]] 11:43, 12 January 2013 (PST)

Kobra Stein: /* Example Corrections */

2013-01-12T19:45:54Z

Example Corrections

← Older revision		Revision as of 12:45, 12 January 2013
Line 153:		Line 153:


	{		'''Original Code'''
	string Who(key id)		string Who(key id)
	{		{

Kobra Stein: /* Original Example Code */

2013-01-12T19:45:03Z

Original Example Code

← Older revision		Revision as of 12:45, 12 January 2013
Line 153:		Line 153:


	~~== Original Example Code ==~~		{
	string Who(key id)		string Who(key id)
	{		{
Line 167:		Line 167:
	}		}

	~~----~~		}

	== Reworked Code==		== Reworked Code==

← Older revision		Revision as of 02:30, 12 October 2023
Line 224:		Line 224:
	== About the "authority" in the secondlife:/// URI, and why it might be a good idea to reuse it... ==		== About the "authority" in the secondlife:/// URI, and why it might be a good idea to reuse it... ==

	The very early reference to [https://www.rfc-editor.org/rfc/rfc3986#section-3.2 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 {{abbr\|FQDN\|Fully Qualified Domain Name}}, e.g. {{mono\|server.example.com}}.		The very early reference to [https://www.rfc-editor.org/rfc/rfc3986#section-3.2 RFC3986] mentions that the reason we have ''three'' slashes on the "revised" {{abbr\|URI\|Uniform Resource Identifier}}s 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 {{abbr\|FQDN\|Fully Qualified Domain Name}} of the machine running the webserver, e.g. {{mono\|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.		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.
Line 246:		Line 246:
	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.		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" (either with a "special" viewer — many of those are still around, in spite of the conjoined effort by many parties to squash them down — ~~but~~ 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".		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?...)		(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?...)
Line 254:		Line 254:
	But I digress. The point is that HyperGrid jump-teleport introduced its own URI, the {{mono\|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 {{mono\|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.		But I digress. The point is that HyperGrid jump-teleport introduced its own URI, the {{mono\|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 {{mono\|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 '{{mono\|@}}' 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 ~~ActivityStreams~~ (read: a federation of Mastodon-compatible social media), or what was already popular with Jabber/XMPP and even IRC.		Everything else in OpenSimulator has "extended" names, using the ubiquitous '{{mono\|@}}' 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 [https://www.w3.org/TR/activitystreams-core/ Activity Streams 2.0] (read: a federation of [https://mastodon.social/ Mastodon]-compatible social media), or what was already popular with Jabber/[https://xmpp.org/about/technology-overview/ 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 — {{mono\|hops}} are just meant to be used for intergrid teleporting. Inside a specific grid, the usual {{mono\|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 {{mono\|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?		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 — {{mono\|hops}} are just meant to be used for intergrid teleporting. Inside a specific grid, the usual {{mono\|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 {{mono\|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?
Line 260:		Line 260:
	Wouldn't it make so much more sense to universally use the {{mono\|secondlife}} scheme, but immediately followed by the ''authority'' that such an URI is supposed to be pointing at?		Wouldn't it make so much more sense to universally use the {{mono\|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 ~~'''the authority by default —~~ if not explicitly set, the "default" authority would be taken to mean "the current grid we're in right now".		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 [https://www.osgrid.org/ 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.		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 [https://www.osgrid.org/ 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.