Summary

  • Project Athena designed Zephyr to route short, time-sensitive notices across a growing workstation network, where local broadcasts and ordinary email each failed in different ways.
  • Zephyr kept authenticated identity, login location, exposure choice, topic subscription and message delivery as separate states; none proved that a person was available or had read a notice.

The first problem was not how to put a message in a window. It was how to reach the right person after computing moved away from a single shared machine. Project Athena’s 1987–88 plans describe an academic environment shifting toward many networked workstations. A process on one host might need to tell users of a file server that it was going down; a print service needed to report a completed job; a teaching assistant might want to reach a class. Traditional mail could persist, but it imposed delay and a named recipient list.

Network broadcast was quick, yet confined to a local network and wasteful when every machine had to inspect traffic intended for only a few users. The Zephyr designers named both limits plainly: email was slow and cumbersome; broadcast was transient and did not scale.

Zephyr was therefore specified as a notice service beneath several kinds of communication. Its 1988 USENIX paper described a base transport and higher layers for subscriptions and user location. By the 5 June 1989 technical plan, a workstation typically had a HostManager (zhm), each login had a WindowGram client (zwgc), and multiple Zephyr servers handled registration, routing and state. A notice carried routing fields separately from client data. Servers used the header to find recipients; they did not need to interpret the message body. That separation let a file server send to users it already knew, while a service without a fixed audience could publish a notice under a class and let clients subscribe.

The subscription was explicit state, not a campus-wide shout. A server recorded a tuple of class, instance and recipient. A user’s client could request a subscription; a notice matching the tuple could then be routed only to interested clients. A direct zwrite used a recipient identity. Kerberos supplied authenticated principals used as Zephyr IDs, so the system could distinguish an authenticated account from a string typed into a message. Yet authentication answered “which identity sent this request?” It did not, by itself, grant every sender permission to locate or interrupt every recipient. The design separately described access controls, user exposure and privileged emergency notices.

Presence had its own limits. Zephyr registered a user’s login and locations so notices could find the active client without the sender knowing which workstation held the session. The designers warned operators not to read the location database as a perfect live roster. A record showed that an authenticated login had been reported, but a workstation crash could prevent a logout message and leave stale state. The reverse inference also failed: no visible location did not prove that the person had never logged in, because the user could choose not to expose location.

The system tried to clear stale workstation records during reboot and when servers discovered a host was not responding. Those repairs reduced bad state; they could not turn a distributed service into a flawless witness.

Zephyr’s exposure controls made that distinction visible to users. The 1989 plan listed six settings: none, opstaff, realm-visible, realm-announced, net-visible and net-announced. Location lookup and login/logout announcements were not one switch. A person could be visible within the Kerberos realm without announcing each login; broader visibility and announcements could be selected separately. MIT’s 1993 user guide also described hide as distinct from turning Zephyr off: hiding location did not stop other people from sending notices. This is a narrower kind of control than a universal “do not contact me” switch, and the guide documents that boundary rather than concealing it.

Transport reliability was another separate question. Zephyr used UDP and added acknowledgement levels where an application wanted them. Its designers warned of duplicates, reordering, loss and absent flow control. The zwrite example promised that a message was sent, not that it arrived or arrived exactly once. A server acknowledgement, a recipient-client acknowledgement and a person reading a WindowGram were different events. This made Zephyr useful for quick coordination, but a transport receipt could not safely stand in for consent, attention or completed work.

By 1993, MIT’s user guide described one-to-one and group Zephyrgrams as ordinary Athena tools; a 1996 study examined the Zephyr Help Instance as a synchronous support channel. These are evidence of use at MIT, not proof that one campus service became the universal model for instant messaging. Project Athena’s system was shaped by its own workstations, Kerberos realm and operations staff.

Its history is more instructive at the boundary it drew: identity could support routing, a login could support a location record, and a subscription could express interest in a class of notices, while permission, reachability and human attention remained separate questions.

Sources