Pico channels

When we say that a pico is "on the Internet" we mean^* that it presents an API to the world. A key part of every API request is an Event Channel Identifier (ECI) for the pico. It is a random-looking string that gives access to and authorization for each usage of one of its many^** APIs.

Each pico can have an unlimited number of channels. Each event and query comes into the pico via one of these channels. Each channel has a policy, listing which events and queries will be accepted over it.

Publishing a channel

Although the pico itself is on the web from the moment of its creation, it isn't available for others to access until channel identifiers have been published.

Publishing narrowly

A web-based API usually assists a developer in signing up to use it, giving out an API key which authorizes access. An ECI plays this role, as well as identifying the pico itself.

This is important because a more typical web-based API is an interface to a service, rather than to an individual entity represented by that service. The individual entity of interest is typically identified in a different part of a service URI. 

From the perspective of this blog, wherein we are considering fully sharded^*** web applications, the ECI combines both identity and authorization.

Picos do not natively provide a way for people to come and apply for an ECI, but it would be easy to code up a web page that did just that. Exactly how the consumer of an entity obtains the ECI they need is left to the KRL developer to design and implement.

Publishing broadly

This would generally happen by embedding the ECI in a URL that is linked from a published web page. That page could either be a static asset of a web site, or produced by a web application.

Both approaches can be combined by a generated public web page with a link (or form) that delivers the visitor to a web page about a particular entity. In that case the visitor needn't even be aware that an ECI is involved. It's just part of a URL.

Revocation of a channel

The owner of a pico gives out channel identifiers to outside partners, of various levels of trustworthiness. Should a partner prove to be untrustworthy, the owner of the pico can simply delete the channel: access is revoked.

The pico owner can broadcast a channel widely, and if any user misbehaves, delete it. A new, replacement, channel can be created very cheaply. 

When the entity ceases to be available because of this revocation, it just looks like a broken link, and legitimate users can get it back by going through the same application process they used initially. Most will not notice that the provided URL is different from the original one. Holders of the original link cannot get to the pico any more and malicious or mischievous use ceases.

Best practices

There are a couple of practices that experienced PicoStack developers recommend.

Create a channel on ruleset installation

It is a best practice to create a channel that allows access to a pico every time a ruleset is installed. This channel can be used by an application administrator for routine/exceptional maintenance. Its event and query policies should be open enough for this purpose, and its identifier shouldn't be published.

After creating this new channel, it is good practice to delete any old channels from previous installations (multiple installations happen often during development and maintenance).

Create a channel for each usage and user

Channels are really cheap to create. If you have one for each user and for each usage, you'll be able to revoke them as necessary while causing minimal disruption to other users/usages.

Notes

^* we could be more precise, saying that the pico is "on the web" because the worldwide web is just a part of the Internet. See "What is the web?" in the first post of this blog.

^** is "API" singular or plural? A pico presents an API to the world. It consists of many individual APIs, one for each shared function and one or more for each event that rulesets in the pico have rules for. So, it is both singular (for the collection of individual APIs of a pico) and plural because a pico has many APIs.

^*** the topic of (horizontal) sharding is addressed in this earlier post.