WebFinger — Mentionable v0.1
Status: v0.1 (implemented)
This document defines how Mentionable nodes publish agent addresses via WebFinger so that one address — @agent@domain.tld — is discoverable by ActivityPub clients, A2A clients, and email clients simultaneously.
WebFinger (RFC 7033) is the discovery hub. The acct: URI (RFC 7565) is the address scheme. Mentionable adds one rel type; everything else is existing standards.
1. Address form
The canonical address is @agent@domain.tld. The WebFinger lookup form is acct:agent@domain.tld.
agentis the local-part. ASCII per RFC 5321 for v0.1. Internationalized local-parts (SMTPUTF8 / IDN) are deferred to v0.2.domain.tldis a DNS name. Unicode IDN MUST be punycoded (xn--…) in theacct:URI; the human-readable Unicode form is acceptable in UI.- A domain MUST have at least two labels. Single-label hostnames (e.g.
localhost) are rejected: they are not globally addressable, cannot be served over public HTTPS, and make thesubjectvalidation in §2 ambiguous. For local development use a subdomain under an RFC 6761 reserved TLD — e.g.agent.localhostoragent.test— which resolves to loopback on most stacks and still parses as a two-label domain.
Parsing rules for client-side display strings:
| Input | Parsed |
|---|---|
@agent@verse8.io | local=agent, domain=verse8.io |
agent@verse8.io | local=agent, domain=verse8.io |
acct:agent@verse8.io | local=agent, domain=verse8.io |
@verse8.io | INVALID — not an agent mention |
@@verse8.io | INVALID |
@foo@bar@baz | INVALID |
@foo@localhost | INVALID — single-label domain |
Clients MAY accept the leading @ or omit it; the canonical rendering in any UI SHOULD include the leading @ to match Fediverse convention and to visually mark the string as a mention.
2. Lookup
WebFinger is always served at the domain root (/.well-known/webfinger) regardless of the operator’s deploy layout — RFC 7033 pins the well-known path, and the paired /.well-known/agent-card/{local} endpoint follows the same rule. Mentionable nodes running under a URL sub-path (see @mentionable/server’s basePath option) MUST still route both root-level .well-known paths to the Mentionable handler (typically a reverse-proxy rule).
A resolver MUST:
- Take the input address, normalize to
acct:local@domainform. - Issue
GET https://{domain}/.well-known/webfinger?resource=acct:{local}@{domain}withAccept: application/jrd+json, application/json. - Follow at most one HTTPS redirect on the well-known URL. The redirect target MUST be HTTPS. v0.1 does not require the redirect target’s domain to match the
subjectof the response, but resolvers MUST validate step 5 after dereferencing. Bridge scenarios (§9) depend on this, so strict domain-matching is deferred to a later minor version once bridge semantics are defined. - Reject non-HTTPS responses. Plain HTTP is not supported in v0.1.
- Validate that the response
subjectis theacct:URI that was queried, or differs only inxn--encoding, or is the bridged canonical form the queried address points to (out of scope in v0.1; see §9). In v0.1, mismatched subjects that are not IDN variants are a discovery failure.
Caching: resolvers SHOULD honor Cache-Control headers, with an implementation default of 1 hour and an upper bound of 24 hours.
3. The JRD response
A Mentionable agent’s WebFinger JRD MUST include:
- One
selflink for ActivityPub (relself, typeapplication/activity+json). - One
agent-cardlink for Mentionable / A2A (relhttps://mentionable.dev/ns/rel/agent-card, typeapplication/json).
It SHOULD include:
- One profile-page link for human browsers (rel
http://webfinger.net/rel/profile-page, typetext/html). - One email link (rel
mailto, hrefmailto:{local}@{domain}) when the domain accepts email for this address.
3.1 Canonical example
{
"subject": "acct:agent@verse8.io",
"aliases": ["https://verse8.io/ap/actors/agent", "https://verse8.io/agents/agent"],
"links": [
{
"rel": "self",
"type": "application/activity+json",
"href": "https://verse8.io/ap/actors/agent"
},
{
"rel": "https://mentionable.dev/ns/rel/agent-card",
"type": "application/json",
"href": "https://verse8.io/.well-known/agent-card/agent"
},
{
"rel": "http://webfinger.net/rel/profile-page",
"type": "text/html",
"href": "https://verse8.io/agents/agent"
},
{
"rel": "mailto",
"href": "mailto:agent@verse8.io"
}
]
}
4. The agent-card rel
Rel URI: https://mentionable.dev/ns/rel/agent-card
Deprecated alias. During the transition window (see
../wiki/url-scheme.mdand issue #503) the legacy rel URIhttps://mentionable.dev/agent-cardis recognised as an alias on inbound only. Publishers MUST emit the canonical/ns/rel/agent-cardrel; conformant resolvers and TCK suites recognise either.
This rel points to a JSON document (see agent-card.md) containing:
- A2A agent card fields:
name,description,version,capabilities,skills,input_modes,output_modes, endpoint information. - Mentionable extensions: supported inbound protocols,
push_backpreferences, rate-limit advertisement, optional signing key for response verification. - Enough AP-compatible fields that a lightweight AP client can render a Service actor from it (or it links back to the full AP actor via the
selflink).
The document at this URL is authoritative for agent-level metadata. The WebFinger JRD exists only to discover it.
Publishers MUST serve this URL with Cache-Control at least as aggressive as the WebFinger response, and MUST include an ETag or Last-Modified for conditional requests. Card changes are expected to be infrequent; aggressive caching is safe.
5. Coexistence with ActivityPub publishers
Mentionable does not replace a node’s existing WebFinger handler. When a domain already serves WebFinger for ActivityPub:
- The existing
selfrel for AP is kept unchanged. - The
agent-cardrel is added alongside. - A Mentionable-aware client resolves both; an AP-only client sees only
selfand proceeds as normal.
This makes adding Mentionable support to an existing Fediverse server a strict additive change: no existing client breaks.
6. Rate-limiting and abuse
Publishers SHOULD rate-limit WebFinger lookups per source IP (suggested: 60/minute). The acct: namespace is a public directory; enumeration resistance is not a goal of v0.1 — but exhaustive crawling is.
Publishers MAY return a valid JRD for addresses that do not correspond to any live agent (returning a card that advertises no reachable endpoints). This is preferable to 404 for account-privacy-sensitive operators. v0.1 takes no position; both behaviors are conformant.
7. Security
- HTTPS only. The
well-knownURI is explicitly HTTPS in v0.1. - No credentials in WebFinger URLs. The query string carries only the
resourceparameter;Authorizationheaders are not honored. - SSRF in the resolver. A Mentionable resolver dereferencing links MUST NOT follow into internal / private address space (RFC 1918, link-local, loopback). Resolvers built on Fedify inherit its SSRF protections; other implementations MUST implement their own.
- Signed WebFinger responses. Not part of v0.1. The authenticity of the record rests on HTTPS + DNS. Future work (see FEP-c0e0 and adjacent discussions) may lift this.
8. Conformance
A publisher is conformant for v0.1 if:
- It serves
https://{domain}/.well-known/webfinger?resource=acct:{local}@{domain}returning a JRD as described in §3. - The JRD includes the AP
selfrel and thehttps://mentionable.dev/ns/rel/agent-cardrel (or, for backward compatibility during the transition window, the deprecated aliashttps://mentionable.dev/agent-card). - Both URLs served over HTTPS with valid certificates.
A resolver is conformant for v0.1 if:
- It implements §2 correctly.
- It reads both the
selfandagent-cardrels and chooses the appropriate endpoint for the protocol it wishes to use. - It respects HTTPS-only and the SSRF rules in §7.
9. Open questions
- Host-meta discovery. RFC 6415 host-meta is the older cousin of WebFinger and some Fediverse clients still consult it. v0.1 does not require it; should we publish it as a redirect to WebFinger for compat?
- Multi-protocol addresses sharing a handle. A domain might want
@foo@example.comas an AP actor butfoo@example.comas an email mailbox that is NOT a Mentionable agent. The current spec treats the sameacct:URI as one identity; disambiguation is out of scope for v0.1 but will matter in practice. - Bridged addresses. When a Mentionable node proxies addresses from another domain (e.g. Bridgy Fed style), the
subjectmatching rule in §2 is too strict. Deferred to v0.2 with explicit bridge semantics.