If you read the example on event subscription, you know that tokens play a large role in routing the events from one network to another. I don’t think of the token as identifying the network since there’s a separate identifier for that. Rather, the token represents a channel. Consequently, in the On Call TA demo, the TAs’ personal event networks subscribe to the events from the class network by supplying an event channel to the class network.
The token is more properly known as the event channel identifier (ECI), although I think we’ll often end up thinking of the token as representing the channel itself. An event channel, right now, has only a single name associated with it, but in the future you’ll be able to associate other information with the channel so that rules can contextually respond to events on a channel-by-channel basis.
To get a view of this, consider the following diagram.
Tim’s personal event network has a number of apps installed. It’s also is listening on many event channels. These channels are carrying events about everything from Tim’s phone and appliances to merchants he frequents.
REI and the flowershop both have separate channels into Tim’s personal event network. Consequently, Tim can
Tim is in charge of whether and how events are delivered. He manages the channel, delivery, and response while the publishers of these event choose the content.