Coordination Strategies: Examples

Yenta

• Decentralization: Totally distributed peers
• Domain characteristics:
  • Speed:
    • Subdaily cluster message propagation
    • Daily & longer clustering update
  • Robustness & accuracy required: Informational
  • Security:
    • Stored in agent: Heavily encrypted. Carefully-controlled user authentication.
    • Between coordinating servers or peers: Heavily encrypted. Mutual authentication and suspicion with spoofing safeguards. Traffic-analysis safeguards.
    • Transmitted to user: Unencrypted outside of authorization envelope. Perhaps encrypted using SSL or PGP equivalent if desired.
    • Threat model: Major concerns are exposure of confidential informatino, modification of information, and perversion. Minor concern is denial of service.
  • Source of domain knowledge: Peer databases, derived from ubiquitious user data (e.g., mail and news).
  • Completness of domain knowledge: Known partial
  • Persistence of agent memory: Long-term/permanent.
  • User interface issues: Not anthropomorphic. Web-based UI. Explicit exposure of the existence of peers.
• Coordination model: Random point-to-point. Known-partial topological knowledge.
• Communications infrastructure employed:
  • Normal operation: low-bandwidth, semi-real-time, connection-oriented (IP).
  • Boostrapping: low-bandwidth, semi-real-time, broadcast and multicast, plus possible connection-oriented central registry lookup.
  • Possible extension: store-and-forward (mail).

Julia

• Decentralization: Totally distributed peers (one per MUD). No knowledge of each other.
• Domain characteristics:
  • Speed: Subsecond response.
  • Robustness & accuracy required: Informational and fun. Sometimes deliberately misleading (e.g., Turing-mode answers).
  • Security:
    • Stored in agent: Unprotected disk-based permanent database.
    • Between coordinating servers or peers: Not applicable.
    • Transmitted to user: Basic TinyMUD-based security (some spoofing resistance). Can use whispers for certain confidential data. Vulnerable to packet-sniffing, etc, and TinyMUD wizards.
    • Threat model: Will walk away from abusers. Assumes TinyMUD is reliable & secure. Unlikely to expose confidential information, but gossips about public conversations. Assumes home host secure (e.g., typical UNIX workstation security) against modification or perversion.
  • Source of domain knowledge:
    • Self-generated: via walking TinyMUD room layouts, overhearing conversations, etc.
    • Programmer-installed: conversational skills & pass-deflection, etc.
    • From users: message storage.
  • Completness of domain knowledge: Very complete topological knowledge of the MUD. Very complete player-description knowledge for players old enough (e.g., days) to be encountered. Known-partial knowledge of complete, instantaneous TinyMUD state.
  • Persistence of agent memory: Long-term/permanent.
  • User interface issues: Uses anthromorphism heavily (as part of basic functioning). Attempts to deceive users about automation. Uses natural language. Never exposes possible existence of other peers (e.g., copies of itself on other MUDs.)
• Coordination model: Central hub (one Julia per MUD). No coordination between multiple Julias on separate MUDs.
• Communications infrastructure employed: Low-bandwidth, IP connection-oriented (telnet).

Couch Potato

• Decentralization: Single central server
• Domain characteristics:
  • Speed: Subsecond response to Web queries. Subminute response to email queries.
  • Robustness & accuracy required: Informational.
  • Security:
    • Stored in agent: None.
    • Between coordinating servers or peers: Not applicable (no peers).
    • Transmitted to user: None.
    • Threat model: None.
  • Source of domain knowledge: External databases not under control of the agent (e.g., http://www.tv1.com, http://www.wgbh.org, etc).
  • Completness of domain knowledge: Fairly complete within the contents of the external databases, but the databases themselves are incomplete in what information would be useful (e.g., not full coverage of all broadcast stations in the Boston area, etc).
  • Persistence of agent memory: Long-term/permanent for user preferences. Medium-term for programming database (updated daily with new database updates).
  • User interface issues: Web-based. No other peers to expose. Exposes underlying information sources. No anthropmorphism.
• Coordination model: Central hub.
• Communications infrastructure employed:
  • To databases: near-real-time, connection-oriented, IP (Web).
  • To user:
    • For configuration and immediate querying: near-real-time, connection-oriented, IP (Web).
    • For autonomous notification: store-and-forward (mail).

Firefly

• Decentralization:
  • Originally: A single central server.
  • Probably now: Multiple, mirrored, loosely-consistent servers which know about each other
  • Probably future: Multiple, mirrored, loosely-consistent servers which do not know about each other.
• Domain characteristics:
  • Speed:
    • Clustering/recalculation/recommendation: subminute response.
    • Chat: Multisecond response.
  • Robustness & accuracy required: Informational/Fun.
  • Security:
    • Stored in agent: None.
    • Between coordinating servers or peers: None.
    • Transmitted to user: None (but has sniffer-viewable, cleartext, per-session authorization protocol).
    • Threat model: Simple guard against user impersonation (sniffer-viewable, cleartext, per-session authorization protocol). Disallows modification of information not owned by user. Assumes no one will try to stuff the ballot-box (aka the database).
  • Source of domain knowledge: Users.
  • Completness of domain knowledge: Assumed partial.
  • Persistence of agent memory: Long-term/permanent.
  • User interface issues: Not anthromorphic. Exposes some details of underlying mechanism, but not of coordination strategy.
• Coordination model: Central hub, with mirroring.
• Communications infrastructure employed: Near-real-time, low-bandwidth, connection-oriented IP (Web).

Webhound/Webhunter

• Decentralization: A single central server.
• Domain characteristics:
  • Speed: Subminute to subhour.
  • Robustness & accuracy required: Informational/Fun.
  • Security:
    • Stored in agent: None.
    • Between coordinating servers or peers: Not applicable.
    • Transmitted to user: None (but has sniffer-viewable, cleartext, per-session authorization protocol).
    • Threat model: Simple guard against user impersonation (sniffer-viewable, cleartext, per-session authorization protocol). Disallows modification of information not owned by user. Assumes no one will try to stuff the ballot-box (aka the database). Assumes external Web pages don't change randomly and frequently.
  • Source of domain knowledge: Users (for preferences) and Web pages (for analysis).
  • Completness of domain knowledge: Assumed partial.
  • Persistence of agent memory: Long-term/permanent.
  • User interface issues: Not anthromorphic. Exposes some details of underlying mechanism.
• Coordination model: Central hub.
• Communications infrastructure employed: Near-real-time, low-bandwidth, connection-oriented IP (Web).

MAXIMS

• Decentralization: One server per user, plus a common, shared central server database (hybrid construction).
• Domain characteristics:
  • Speed: Subsecond response.
  • Robustness & accuracy required: Advisory.
  • Security:
    • Stored in agent: None?
    • Between coordinating servers or peers: None.
    • Transmitted to user: None.
    • Threat model: None? Not even for the central database?
  • Source of domain knowledge: User behavior, plus central database of other users' behaviors and organizational hierarchy information.
  • Completness of domain knowledge: Known partial.
  • Persistence of agent memory: Per-user, plus some long-term/permanent storage in the central database.
  • User interface issues: No anthropomorphism. Slight exposure of underlying central database. Layered on top of existing application (Eudora).
• Coordination model: Central hub (database), but no explicit coordination of server/peers except to update that database.
• Communications infrastructure employed: Low-bandwidth, near-real-time, connection-oriented, TCP (file stream)

Lycos

• Decentralization: Multiple, tightly-consistent, mirrored servers. Servers don't know about each other, but central load-distributor (rotary) does.
• Domain characteristics:
  • Speed: Subsecond to subminute response.
  • Robustness & accuracy required: Informational.
  • Security:
    • Stored in agent: None.
    • Between coordinating servers or peers: None.
    • Transmitted to user: None.
    • Threat model: Denial-of-service due to excessive traffic; throttles implemented per-user and per-server. Assumes external Web pages don't change randomly and frequently.
  • Source of domain knowledge: External Web pages and internal built indices.
  • Completness of domain knowledge: Known partial. Fairly complete globally (though always months behind).
  • Persistence of agent memory: Long-term/permanent for indices. No user customization longer than per-session. (Barely an agent.)
  • User interface issues: No anthropomorphism. Web-based. No exposure of other mirrored servers in normal operation.
• Coordination model: Central hub, mirrored to shed load.
• Communications infrastructure employed: Near-real-time, low-bandwidth, TCP connectection-oriented (Web).

Previous | Table of contents | Next