# Agent Introductions

In order to communicate, agents need to be introduced to each other.

For transports with specific client/server roles, the major difference in introductions and communication applies to each role differently.

Within these roles, the other consideration is ability of an agent to write to a credential store (like a traditional wallet). Static agents have fixed credentials, often stored in configuration files.

## Client/Server Transports
These transports have a specific role of client (initiates connection) and server (receives connection).
Examples: http, websockets, bluetooth

Clarify server and client

Bluetooth or app messaging on the same phone needs clarification.

### Server Agent
- Can be both inviter and invitee

### Server Agent with Fixed Wallets
- example: inbound with webhooks
- fixed wallets makes use feel like a library
- requires manual round trip to pass wallet information

### Client Agent
- example: mobile app
- Must be invitee to communicate directly
- communication always initiated by client agent: polling, websocket. other agent must be server agent
- Uses duplex or return-route to receive messages
- cannot directly connect to another client agent.
- provides no inbound route to direct connection peers in did doc. direct peer must queue outbound messages.
- with routing, can be the inviter

### Client Agent with Fixed Wallet
- Requires manual round trip to pass wallet information.

### Client Agent using a routing agent:
- Can bridge transport mismatches
- can allow client agent to 'act' like server agent

## Client with Smart Transport
In these transports, all parties are clients, with a 'smart' transport layer capable of queueing messages.
Examples: AMPQ, SMTP, Filesystem
- All parties with dynamic credentials can invite and be invited.
- All parties with fixed credentials need a round trip to trade credentials.

## Forms of Introduction
Understanding the constraints leads us to identify the standard flows and formats for introduction. These standards apply for both client/server and smart transport clients.

### Invitation Messages
Using Return Routing, any non-static agent can act as an _inviter_ or an _invitee_. Two _invitees_ cannot connect to each other without one of them using a routing agent to become capable of being an _inviter_. Every other agent can connect directly. An introduction is made by passing an invitation message from the _inviter_ to the _invitee_ and then continuing the connection establishment protocol.

### Static Agent
Any agent with fixed credential storage requires that those credentials be moved manually between the static agent and the agent(s) that it will connect with. This manual exchange must contain all information needed for the connection, as the connection establishment protocol is NOT performed after this exchange.

Question: Is there a valid form of Trust on First Use that allows only one-way manual movement between systems? Could one copy from main agent to static agent be enough to trust it on first message?

Potential TODO: Standardize a bundle format that allows the copy and paste of a single value which contains keys, endpoints, etc.