Connections
EWP defines a synchronous handshake protocol for establishing and terminating follow relationships.
The Follow Handshake
Follower Followee
│ │
│──── POST /ewp/connections ─── ────────────►│
│ { typedData, signature } │
│ │ 1. Verify signature
│ │ 2. Verify followeeUrl identity
│ │ 3. Verify followerUrl identity
│ │ 4. Persist connection record
│◄─── 201 Created ─────────────────────────│
│ │
│ (Follower records local state │
│ on receipt of 201) │
The follower creates its own local record upon receiving 201. No callback to the follower's node is required.
Message Types
CreateConnection
Signed by the follower to initiate a follow:
{
"followerAddress": "0x...",
"followeeAddress": "0x...",
"followeeUrl": "https://bob.example.com",
"followerUrl": "https://alice.example.com",
"timestamp": 1735000000
}
DestroyConnection
Signed by either party to terminate:
{
"followerAddress": "0x...",
"followeeAddress": "0x...",
"timestamp": 1735000000
}
The receiver determines the operation by matching the recovered signer:
| Signer recovered as | Operation | Receiver removes |
|---|---|---|
followerAddress | Unfollow | Followee removes its connection record |
followeeAddress | RemoveFollower | Follower removes its connection record |
If the recovered signer matches neither address, the request MUST be rejected with INVALID_SIGNATURE.
Endpoints
| Method | Path | Auth |
|---|---|---|
POST | /ewp/connections | EIP-712 (CreateConnection) |
DELETE | /ewp/connections | EIP-712 (DestroyConnection) |
DELETE /ewp/connections uses a JSON request body. Per RFC 9110, DELETE body semantics are not universally defined. EWP protocol traffic is node-to-node HTTPS; implementations MUST NOT route /ewp/ endpoints through intermediaries that strip request bodies.
Verification Rules
CreateConnection
- Signature must be valid and recover to
followerAddress - Timestamp must be within ±1 hour of current time
followeeUrlmust resolve and return matchingfolloweeAddressfollowerUrlmust resolve and return matchingfollowerAddress
DestroyConnection
- Signature must be valid and recover to
followerAddressORfolloweeAddress - Timestamp must be within ±1 hour of current time
- Connection must exist
Connection Staleness Protection
DestroyConnection requests are subject to a ±1-hour timestamp window. Additionally, if the receiver holds a connection record whose createdAt is strictly greater than message.timestamp, the receiver MUST reject the request with 409 STALE_REQUEST.
This prevents a delayed or replayed termination message from destroying a connection that was re-established after the original termination was signed.
Follower URL Verification
CreateConnection requires the followee to verify that followerUrl belongs to followerAddress. This prevents a malicious actor from:
- Directing replication notification traffic to arbitrary endpoints
- Using the follow mechanism as a DDoS amplification vector