Oftentimes you will have a URL to access one of your picos and you will want to use that URL frequently and/or share it with others. In such cases you might prefer a shorter URL, and one which does not have to include the random-looking event channel identifier (ECI).
...
The node pico engine has a built-in feature to shorten query and event URLs. It is implemented by a ruleset installed in the Root Pico of an engine. To use this feature, you must first install the ruleset io.picolabs.rewrite into the root pico. Then you must register each short form with the root pico.
Here is a running example URL
...
Create a new channel
This is a discipline that you should have in any casebest practice. For each usage of a pico, that pico should have a specific channel. This allows you to revoke that usage without interfering with other usages of the same pico.
To create a channel for this purpose, in the UI go to the "Channels" tag. The type of this channel must might be "web shortcut" (without the quotes and a single space between the two words), and the name must might match the first part of the path of the short URL. In the running example, this would be "/my.room".
Note that the ECI which had been used in the full /sky/cloud URL is not shown in the list. It was deleted before the screenshot was captured. That is because the specific value need not be known or shared at all for the shorter link to work. The engine will select the channel of type "web shortcut" with the name my.room and use that channel's ECI
Capture the newly created ECI, and register it with the root pico, so that it can be used when it re-writes the short URL to produce the standard URL which the engine actually uses internally. You can use the "Testing" tab of the root pico to do the registration, or use some mechanism provided by the pico engine owner/operator.
Having created the channel as specified, and registered it with the root pico, the short URL will now work.
...
by creating a channel of type "web shortcut" with name "/clear-temps", and registering this first path component (FPC) and the ECI with the root pico, as before, except that the type would be "event" rather than "query".
Note that that the FPC "/clear-temps" can be chosen arbitrarily, because it is the event identifier (EID). Contrast this with the case for queries in which the name of the channel must match your ruleset identifier (RID). For events, the RID does not appear in either the longer standard URL nor in the short one.
...
This technique is most useful when you own and operate the node pico engine. When you own a pico that lives on an engine operated by someone else, there is a risk of inadvertent naming collisions of the FPC. The io.picolabs.rewrite ruleset in the root pico will detect a collision and not allow you to register a shortcut with an FPC that is already in use.
Of course, you really ought to operate your own pico engine. It's not that hard (see Pico Engine Quickstart) and it gives you more personal freedom. If you grant others access to your engine and allow them to have an owner pico (see Account management using the Root Pico), you might wish to set up some kind of registration procedure for naming web shortcuts to avoid duplicates. If there is a collision – if more than two owners choose the same web shortcut name -- the one that happens to have the ECI that sorts earlier in alphabetic order will win, because these other owners will not have access to your root pico's "Testing" tab.
Like the longer, standard links for events and queries, the shorter links are not permalinks unless you take steps to keep your engine running permanently and never change the ECI. The shorter links would have more tendancy towards permanence because when deleting an ECI you can create a new channel (with proper name and type), and then registering it with the root pico, without requiring the link itself to change.
...
If you are wondering why the ECI for the secret channel named "admin" is redacted in the image above, it is because this is the only channel that the pico has which is not fungible, which cannot be deleted without requiring the pico itself to also be deleted. So, even though the pico is running on an engine which I control, and which itself is running on a machine which I control, I'm not taking any chances.
...