Community hub
Recent from talks
Contribute something
Nothing was collected or created yet.
WebFinger
View on Wikipedia
WebFinger is a protocol specified by the Internet Engineering Task Force IETF in RFC 7033 that allows for discovery of information about people and things identified by a URI.[1] Information about a person might be discovered via an acct: URI, for example, which is a URI that looks like an email address.
WebFinger is specified as the discovery protocol for OpenID Connect,[2] which is a protocol that allows one to more easily log in to various sites on the Internet.[3]
The WebFinger protocol is used by federated software, such as GNU social (via its use in OStatus), Diaspora,[4] or Mastodon,[5] to discover users on federated nodes and pods, as well as the remoteStorage protocol.[6] The WebFinger protocol does not specify the usage of "template" within the "links" section. That is an extension made by the former oStatus protocol that the Fediverse inherited from. The reasoning for expanding upon this later was justified by wanting to use a different key for a value that isn't an URL but a pattern to create one.[7]
As a historical note, the name "WebFinger" is derived from the old ARPANET Finger protocol, but it is a very different protocol designed for HTTP.[8]
The protocol payload is represented in JSON format with a MIME-Type of application/jrd+json.[9]
Technical overview
[edit]Basically the WebFinger is just a structured data format. The content of this structure depends entirely on the applications using it. While ensuring compatibility and extensibility.
Basic example with profile page and business card
[edit]For this example we've two users Alice and Bob. Alice only knows the E-Mail address of bob bob@example.com. Bob previously setup WebFinger over at example.com.
- Alice opens the "Add contact" page of their E-Mail client and only enters Bobs E-Mail Address.
- The application then derives the WebFinger URL:
- test
https://- + the domain part of the email address
example.com - +
/.well-known/webfinger?resource= - + the kind of schema the application is looking for, in this case we want to have account information, so it's
acct - + followed by an URL-Encoded
:-character, aka.%3A - + followed by the URL-Encoded value (the email address) we'd like to know more of
bob%40example.com. - Resulting in the URL:
https://example.com/.well-known/webfinger?resource=acct%3Abob%40example.com
- The application then makes a HTTP-Request towards it and follows all potential HTTP redirects according to the HTTP specification.
- When the application got a successful result it parses the obtained JSON looking at all of the obtained "properties" and "links" to find ones it understands ignoring all others. Like e.g.
http://webfinger.net/rel/profile-pagefor populating the users homepage field orhttp://webfinger.net/rel/avatarfor adding a picture to the contact details.
For this the client sends the following request:
GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1
Host: example.com
Server response body:
{
"subject": "acct:bob@example.com",
"aliases": [
"https://www.example.com/~bob/"
],
"properties": {
"http://example.com/ns/role": "employee"
},
"links": [
{
"rel": "http://webfinger.net/rel/profile-page",
"href": "https://www.example.com/~bob/"
},
{
"rel": "http://webfinger.net/rel/avatar",
"type": "image/png",
"href": "https://www.example.com/~bob/avatar.png"
}
]
}
Usage within the Fediverse
[edit]Fediverse instances like e.g. Mastodon[5], Peertube, Misskey, ... can look up the server name of a specific usernames by sending a request to the WebFinger endpoint of the domain within their username (the part after the 2nd @-symbol). This also allows companies, influencers (anyone with their own DNS domain name) to point towards their official accounts within the Fediverse (aka. with ActivityPub) without needing to have their own instance running on their own domain and without all of the accounts having to be on the same instance (e.g. automatic accounts populated by the websites CRM, one for some primarily video content on a Peertube instance, and some personalised "employee" accounts on either one or multiple different Mastodon/Fediverse instances WITHOUT having to separate all of these to different (sub) domain names. Allowing to have a single easily readable and recognisable association with ones website within multiple usernames like e.g.: @authorname@bigcompany.tld, @news@bigcompany.tld, and @videotutorialsXYZ@bigcompany.tld instead of a confusing mix of e.g. @authorname@social.bigcompany.tld, @feed@feed.bigcompany.tld, @videotutorialsXYZ@videos.bigcompany.tld, and especially instead of @authorname@othercompany.tld.
Without WebFinger when a company either chooses to outsource or team up with another company for operating these platforms on their behalf they normally not only make it trivial for others to impersonate them (because of having usernames that do not depend on their websites like e.g. @something@anothercompany.tld) but they also have to give up control over that account and its social capital to that specific company. The owner of anothercompany.tld is now in control of a companies entire social capital. Even worse should that company decide to shut down their servers for one reason or another the entire social capital could have to be rebuilt from scratch as nobody will be able to find the new company they moved to.
With WebFinger all of these problems can be avoided easily as e.g. @authorname@bigcompany.tld does not have to be served by https://bigcompany.tld/, nor does @otherauthorname@bigcompany.tld have to be on the same server anymore. If WebFinger is used a company gets enabled to use Mastodon.social today but once it either is no longer ideal or becomes inaccessible they can on their own accord - without any approval, vetoing, or even cooperation of the Mastodon gGmbH that owns and operates Mastodon.social, moved towards any other instance without losing their social capital. Be it a self-hosted one, one spun-up and operated by a smal regional IT contractor, or similar. And all of this completely transparently and without any for their community members having to "refollow" or do anything. Basically making migrating ones social media platform operator as easy as the one for ones website. Thereby eliminating vendor lock-in (e.g. as seen on centralised "big-tech" platforms like Twitter, Facebook, TikTok, or Instagram) and allowing one to staying in control of their network relationships and social capital.
All at the little cost of having to purchase single DNS domain. And to stay in control of it (e.g. by being registered and listed as the rightful owner of that DNS domain name within the DNS registry). Note: In most cases this is neither anything new or unique to WebFinger and for most companies associated risks are also already being managed as losing control over ones domain usually includes also losing ones Website, E-Mail reachability, and thereby not "just" their social capital but their entire web presence including losing out on income from e.g. ads, affiliate links, and/or sales. For WebFinger specifically one most ideally should also ensures to stay in control over their webspace as well. However compared to losing ones entire DNS domain that's basically just an annoying inconvenience.
When WebFinger is solely being used for the Fediverse alone it can be seen as a more universal, versatile, and simpler alternative to the more walled off AT_Protocol controlled and solely used by Bluesky. As all that is needed for WebFinger to function for this is host a single static file per username with a fixed file name of webfinger?resource=acct%3A<<USERNAME>>%40example.com within the .well-known folder on ones website. This means when someone visits https://example.com/.well-known/webfinger?resource=acct%3A<<USERNAME>>%40example.com they need to get a small JSON-file (aka. a text file) with content similar to the example below).
Example for user @Mastodon@mastodon.social
[edit]WebFinger aware platforms and clients first tries to access the URL https://mastodon.social/.well-known/webfinger?resource=acct%3AMastodon%40mastodon.social by sending the HTTP-Request:
GET /.well-known/webfinger?resource=acct%3AMastodon%40mastodon.social HTTP/1.1
Host: mastodon.social
Then the server responds with:
More human readable and formatted:
{
"subject":"acct:Mastodon@mastodon.social",
"aliases":[
"https://mastodon.social/@Mastodon",
"https://mastodon.social/users/Mastodon"
],
"links":[
{
"rel":"http://webfinger.net/rel/profile-page",
"type":"text/html",
"href":"https://mastodon.social/@Mastodon"
},
{
"rel":"self",
"type":"application/activity+json",
"href":"https://mastodon.social/users/Mastodon"
},
{
"rel":"http://ostatus.org/schema/1.0/subscribe",
"template":"https://mastodon.social/authorize_interaction?uri={uri}"
},
{
"rel":"http://webfinger.net/rel/avatar",
"type":"image/png",
"href":"https://files.mastodon.social/accounts/avatars/000/013/179/original/b4ceb19c9c54ec7e.png"
}
]
}
Response in raw unformatted and unmodified including all headers for reference:
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 628
referrer-policy: same-origin
x-runtime: 0.016346
x-frame-options: DENY
x-xss-protection: 0
content-type: application/jrd+json; charset=utf-8
etag: W/"1b12765828befeb0088ccfaa101276d5"
x-request-id: 6b75d72dfe8e62d97f15f6fce1095d7b
x-content-type-options: nosniff
via: 1.1 varnish, 1.1 varnish
content-security-policy: base-uri 'none'; default-src 'none'; frame-ancestors 'none'; font-src 'self' https://mastodon.social; img-src 'self' data: blob: https://mastodon.social https://files.mastodon.social; style-src 'self' https://mastodon.social 'nonce-VcuwDlT8Sp/BslgCzk90Aw=='; media-src 'self' data: https://mastodon.social https://files.mastodon.social; manifest-src 'self' https://mastodon.social; form-action 'self'; child-src 'self' blob: https://mastodon.social; worker-src 'self' blob: https://mastodon.social; connect-src 'self' data: blob: https://mastodon.social https://files.mastodon.social wss://streaming.mastodon.social; script-src 'self' https://mastodon.social 'wasm-unsafe-eval'; frame-src 'self' https:
cache-control: max-age=259200, public
Accept-Ranges: bytes
Age: 102821
Date: Sun, 12 Oct 2025 13:27:46 GMT
X-Served-By: cache-fra-eddf8230117-FRA, cache-fra-eddf8230158-FRA
X-Cache: MISS, HIT
X-Cache-Hits: 0, 0
X-Timer: S1760275667.945082,VS0,VE1
Vary: Origin
Strict-Transport-Security: max-age=31557600
alt-svc: h3=":443";ma=86400,h3-29=":443";ma=86400,h3-27=":443";ma=86400
{"subject":"acct:Mastodon@mastodon.social","aliases":["https://mastodon.social/@Mastodon","https://mastodon.social/users/Mastodon"],"links":[{"rel":"http://webfinger.net/rel/profile-page","type":"text/html","href":"https://mastodon.social/@Mastodon"},{"rel":"self","type":"application/activity+json","href":"https://mastodon.social/users/Mastodon"},{"rel":"http://ostatus.org/schema/1.0/subscribe","template":"https://mastodon.social/authorize_interaction?uri={uri}"},{"rel":"http://webfinger.net/rel/avatar","type":"image/png","href":"https://files.mastodon.social/accounts/avatars/000/013/179/original/b4ceb19c9c54ec7e.png"}]}
See also
[edit]References
[edit]- ^ Jones, Paul E.; Salgueiro, Gonzalo; Jones, Michael B.; Smarr, Joseph (September 2013). "RFC 7033: WebFinger".
- ^ "Final: OpenID Connect Discovery 1.0 incorporating errata set 1". openid.net. Retrieved 2022-12-19.
- ^ "OpenID Connect | OpenID". 2011-08-01. Retrieved 2022-12-19.
- ^ Clemens (2011-09-17). "How Diaspora Connects Users". Sarah Mei. Retrieved 2022-12-19.
- ^ a b "WebFinger - Mastodon documentation". docs.joinmastodon.org. Retrieved 2022-12-19.
- ^ remoteStorage protocol draft at the IETF website.
- ^ "Making sure you're not a bot!". codeberg.org. Retrieved 2025-10-12.
- ^ Introducing WebFinger
- ^ Jones, Paul; Salgueiro, Gonzalo; Jones, Michael B.; Smarr, Joseph (September 2013). WebFinger (Report). Internet Engineering Task Force.
External links
[edit]WebFinger
View on Grokipedia/.well-known/webfinger endpoint on the host derived from the target URI, including a resource parameter specifying the entity (e.g., acct:username@[example.com](/page/Example.com)) and optionally a rel parameter to filter for specific link relations.[1] Servers respond with a JSON Resource Descriptor (JRD), a structured document containing the subject's URI, aliases (alternative URIs), properties (key-value pairs like names or photos), and links to related resources with types defined by the Link Relations registry.[1] This design supports decentralized discovery across domains, facilitating interoperability in applications like social networking, identity management, and federated services, while mandating HTTPS for transport to ensure security.[1]
Key features include support for Cross-Origin Resource Sharing (CORS) to allow browser-based queries, redirection for hosted services, and extensibility via the properties and links in JRDs, though it explicitly excludes dynamic or real-time data to maintain simplicity and privacy boundaries.[1] Security considerations emphasize the use of valid TLS certificates, rate limiting to prevent abuse, and user consent for published information, as exposure of personal details can lead to privacy risks or spam harvesting.[1] Developed by Paul E. Jones, Gonzalo Salgueiro, Michael B. Jones, and Joseph Smarr, WebFinger builds on earlier discovery mechanisms like LRDD but standardizes them into a single, RESTful interface for broader adoption.[1][3]
Overview
Definition and purpose
WebFinger is a protocol defined in RFC 7033 that enables the discovery of information about people or other entities on the Internet through standard HTTP methods, primarily using identifiers in the form of "acct:" URIs or email addresses.[1] It operates by allowing clients to query a server's well-known endpoint, typically via HTTPS, to retrieve static metadata associated with the identifier, without requiring direct access to the entity's location on the web.[1] The core purpose of WebFinger is to facilitate decentralized discovery of public profile information, contact details, or other metadata, avoiding the need for centralized directories or proprietary systems.[1] By leveraging HTTP, it promotes interoperability among diverse services such as social networks, email providers, and identity systems, enabling users to share and access information across platforms in a standardized manner.[1] This approach supports broader goals of decentralized identity management on the web, where entities can expose links to resources like profile pages without relying on siloed APIs.[1] WebFinger draws conceptual inspiration from earlier user discovery mechanisms, including the UNIX "finger" protocol and integrations with systems like OpenID for simplifying identity lookups.[4] It has been adapted for use in OpenID Connect to dynamically discover identity providers based on user identifiers.[1] The protocol returns results in a JSON Resource Descriptor (JRD) format, which encapsulates links and properties related to the queried entity.[1]Key concepts
WebFinger relies on the acct: URI scheme to identify users and entities in a standardized manner. The format isacct:user@host, where "user" represents the local identifier and "host" is the domain, providing a URI-based account reference that is distinct from email addresses despite superficial similarity, as it functions solely for resource discovery rather than message routing.[1]
At the core of the protocol are resource descriptors, which are structured documents typically formatted as JSON Resource Descriptors (JRDs). These descriptors contain an array of links pointing to related resources, such as user profiles, avatar images, or additional metadata, enabling clients to retrieve contextual information about the identified entity.[1]
Discovery begins at a standardized well-known URI endpoint, specifically /.well-known/webfinger on the target host, which serves as the entry point for querying resource information via HTTP.[1]
Each resource descriptor includes essential properties, with the subject field mandating the acct: URI of the entity (e.g., acct:user@host), and an array of link relations defined by the rel parameter to specify the type of connection, such as rel="http://webfinger.net/rel/profile-page" for linking to a user's profile webpage. These relations use either IANA-registered values or full URIs for precision, accompanied by optional attributes like href for the target URL, type for media types, and properties for embedded metadata.[1]
History
Development origins
WebFinger originated in 2009, when Brad Fitzpatrick, then at Google and known for his work on LiveJournal and OpenID, proposed the protocol as an extension of XMPP's XEP-0157 to enable web-based discovery of user information.[5] This proposal aimed to adapt the XMPP extension's approach to contact addresses—originally designed for specifying service details like email and JabberIDs—into a simpler HTTP-based mechanism for broader internet use.[5][6] The development was driven by the growing interest in decentralized social networking during the late 2000s, where users sought ways to link identities and profiles across independent sites without relying on centralized platforms.[5] Fitzpatrick's idea built on existing efforts to make email addresses more expressive as identifiers, influenced by OpenID's decentralized authentication model and the Friend of a Friend (FOAF) project's emphasis on semantic web descriptions of relationships and profiles.[5] Early prototypes focused on practical implementations tied to blogging platforms, including LiveJournal, to support cross-site profile linking and user discovery through straightforward HTTP queries.[5] These initial efforts highlighted WebFinger's potential for enabling services like social graph exploration and identity verification in distributed environments. Key early discussions involved the IETF's XMPP Working Group, where contributors like Peter Saint-Andre recognized similarities to XEP-0157 and advocated for broader standardization to refine the protocol for internet-scale adoption.[5]Standardization process
The standardization of WebFinger began with an individual Internet-Draft submission titled "The WebFinger Protocol" (draft-hammer-webfinger-00), authored by Eran Hammer-Lahav, Brad Fitzpatrick, and Blaine Cook, and posted to the IETF on October 19, 2009.[7] This initial draft outlined the protocol's use of HTTP GET requests to a well-known URI for discovering metadata about entities identified by URIs, including the introduction of the 'acct' URI scheme for user accounts.[8] In April 2012, the IETF issued a call for adoption of the evolving draft by the Applications Area Working Group (APPSAWG), marking its transition to a working group effort under the name draft-ietf-appsawg-webfinger.[9] The working group, chaired by Barry Leiba and Murray Kucherawy, refined the specification through 19 iterations of drafts between July 2012 and August 2013, addressing feedback on security, extensibility, and integration with HTTP standards.[10] Key contributors during this phase included Paul E. Jones, Gonzalo Salgueiro, Michael B. Jones, and Joseph Smarr.[2] The finalized document was approved by the Internet Engineering Steering Group (IESG) and published as RFC 7033, "WebFinger," on September 27, 2013, achieving Proposed Standard status.[11] This RFC formally defines the protocol's core mechanics, including the use of HTTPS for all requests to ensure secure discovery, the structure of JSON Resource Descriptors (JRDs) for responses, and extensibility through link relations; it also incorporates security considerations such as protection against information leakage and denial-of-service attacks.[1] Additionally, the 'acct' URI scheme was further specified in a separate RFC 7565, published in August 2015.[12] Following publication, RFC 7033 has seen no major formal updates or revisions, with no reported errata as of the latest IETF records. Community-driven extensions have emerged in related standards, such as the W3C's ActivityPub (published as a Recommendation in 2018), which leverages WebFinger for actor discovery in federated social networks while enforcing HTTPS as mandated; these adaptations focus on integration with modern web architectures without altering the core protocol.Technical specification
Resource discovery
WebFinger resource discovery involves parsing the input URI to identify the target host. The acct: URI, an identifier of the formacct:username@[hostname](/page/Hostname), is parsed according to RFC 3986 to extract the hostname component, which forms the base for the HTTPS URL (e.g., https://[hostname](/page/Hostname)).[1][13]
The client then constructs the WebFinger URI by appending the fixed path /.well-known/webfinger to the hostname and adding the required resource query parameter with the encoded target URI (e.g., https://[hostname](/page/Hostname)/.well-known/webfinger?resource=acct%3Ausername%40[hostname](/page/Hostname)).[1]
Upon querying the WebFinger URL, a 404 status indicates the resource is unknown to the server.[1]
Host metadata retrieval
Once the WebFinger endpoint has been discovered for a given host, clients retrieve metadata about a specific resource by sending an HTTP GET request to the path/.well-known/webfinger on that host, appending the required resource query parameter that specifies the target URI (e.g., acct:[email protected], URL-encoded as acct%3Auser%40example.com).[1] To indicate the desired response format, clients include an Accept header with the value application/jrd+json, ensuring the server returns the resource descriptor in JSON Resource Descriptor (JRD) format if supported.[1]
The request supports an optional rel parameter to filter the response by specific link relation types, allowing clients to retrieve only relevant metadata; for instance, specifying rel=http://webfinger.net/rel/avatar limits results to avatar-related links.[1] Multiple rel values can be provided for broader filtering, and the parameter uses URL encoding for any special characters in relation URIs.[1] Servers process these parameters to generate a targeted response, which upon success returns a 200 OK status code with a Content-Type header set to application/jrd+json.[1] In cases of failure, such as an invalid resource or server error, the server issues appropriate 4xx or 5xx HTTP status codes without disclosing sensitive details.[1]
All WebFinger queries must use HTTPS to protect the confidentiality and integrity of the exchanged metadata, with the request host matching the host portion of the resource URI to prevent cross-host leaks.[1] For performance and scalability, servers include standard HTTP caching headers, such as Cache-Control, in responses to specify expiration times or validators, enabling clients to cache resource descriptors and reduce repeated queries.[1] This caching mechanism aligns with HTTP/1.1 guidelines, allowing conditional requests to refresh stale data efficiently.[1]
JSON resource descriptor format
The JSON Resource Descriptor (JRD) serves as the standardized response format in the WebFinger protocol, consisting of a single JSON object that conveys metadata about the queried resource.[14] As specified in RFC 7033, the root object of a JRD includes a "subject" member, which SHOULD be present and is a string representing the URI (typically an acct: URI) of the entity being described, and an optional "links" member that is an array of link description objects.[15] Additional optional root-level members include "aliases", an array of alternative URIs for the subject, and "properties", an object mapping URI keys to string or null values for arbitrary metadata.[15] Each element in the "links" array is a JSON object describing a hyperlink, with the following properties: "rel", a required string indicating the relation type (a URI or registered link relation name); "href", an optional string providing the target URI; "type", an optional string specifying the media type of the target resource; "titles", an optional object of language-tagged strings for human-readable titles; and "properties", an optional object for extension metadata similar to the root "properties".[16] Servers may include multiple links, and clients must ignore any unrecognized properties or members to ensure extensibility.[15] Common relation types in JRD links include "http://webfinger.net/rel/profile-page", which points to the user's profile page, as illustrated in the protocol's normative example.[17] Another frequently used relation is "me", a registered link relation indicating that the target resource represents the same entity as the subject, often linking to a self-referential profile or identity endpoint. For instance, a typical JRD response for the subject "acct:[email protected]" might appear as follows:{
"subject": "acct:[email protected]",
"links": [
{
"rel": "http://webfinger.net/rel/profile-page",
"href": "https://www.example.com/~bob/"
},
{
"rel": "me",
"href": "https://www.example.com/~bob/",
"type": "text/html"
}
]
}
{
"subject": "acct:[email protected]",
"links": [
{
"rel": "http://webfinger.net/rel/profile-page",
"href": "https://www.example.com/~bob/"
},
{
"rel": "me",
"href": "https://www.example.com/~bob/",
"type": "text/html"
}
]
}
Examples
Basic profile lookup
To perform a basic profile lookup using WebFinger, consider a hypothetical query for the identifieracct:[email protected] on the fictional host example.com. This initiates a discovery process where a client sends an HTTP GET request to the server's /.well-known/webfinger endpoint, specifying the resource parameter to identify the user. The server responds with a JSON Resource Descriptor (JRD) containing links to relevant resources, such as a profile page and contact information.[14]
The request is constructed as follows:
GET /.well-known/webfinger?resource=acct%3Aalice%40example.com HTTP/1.1
Host: example.com
Accept: application/jrd+json
GET /.well-known/webfinger?resource=acct%3Aalice%40example.com HTTP/1.1
Host: example.com
Accept: application/jrd+json
acct:[email protected] URI in the resource query parameter and requests the JRD media type. For manual verification, the curl command-line tool can be used:curl -H "Accept: application/jrd+json" "https://example.com/.well-known/webfinger?resource=acct%3Aalice%40example.com". This fetches the response directly from the server, assuming HTTPS is enforced for security.[14]
A successful response includes an HTTP 200 status, appropriate headers, and the JRD body. The headers typically specify the content type and may include CORS allowances:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json; charset=utf-8
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json; charset=utf-8
subject field matching the queried resource and an array of links describing discoverable items. For this example:
{
"subject": "acct:[email protected]",
"links": [
{
"rel": "http://webfinger.net/rel/profile-page",
"href": "https://example.com/~alice/"
},
{
"rel": "http://webfinger.net/rel/avatar",
"href": "https://example.com/~alice/photo.jpg",
"type": "image/jpeg"
},
{
"rel": "http://packetizer.com/rel/businesscard",
"type": "text/vcard",
"href": "https://example.com/~alice/alice.vcf"
}
]
}
{
"subject": "acct:[email protected]",
"links": [
{
"rel": "http://webfinger.net/rel/profile-page",
"href": "https://example.com/~alice/"
},
{
"rel": "http://webfinger.net/rel/avatar",
"href": "https://example.com/~alice/photo.jpg",
"type": "image/jpeg"
},
{
"rel": "http://packetizer.com/rel/businesscard",
"type": "text/vcard",
"href": "https://example.com/~alice/alice.vcf"
}
]
}
Social networking integration
WebFinger plays a crucial role in enabling user discovery across federated social networks, particularly in platforms like Mastodon, where it facilitates interactions between users on different instances without relying on centralized directories. In Mastodon, when a user enters a handle such as@[email protected] to follow someone remotely, the local instance triggers a WebFinger lookup by querying the remote server's /.well-known/webfinger endpoint with the resource parameter set to the account URI (e.g., acct:[email protected]). This process allows seamless cross-instance following by resolving the remote user's identity and associated resources.[19][20]
The response from a Mastodon server in the Fediverse is a JSON Resource Descriptor (JRD) that includes the subject's URI and an array of links pointing to key resources, such as the ActivityPub actor JSON document (via a self rel with application/activity+json type), the user's profile page (via profile-page rel with text/html type), and the avatar image (via an http://webfinger.net/rel/avatar rel). These links enable the requesting instance to fetch the remote user's profile details, posts, and media for integration into the local feed, supporting features like displaying avatars and bios during follows.[19]
Beyond Mastodon, WebFinger supports cross-instance discovery in other federated platforms. In Diaspora, it resolves user handles to hCard documents and seed location endpoints, allowing pods to exchange profile data and initiate connections across the network. Similarly, Pump.io employs WebFinger to identify users via acct: URIs and discover their feeds and social graph endpoints, promoting interoperability in decentralized social environments.[21][22]
This integration provides significant benefits in social contexts by enabling decentralized user search and federation, where individuals can locate and interact with others across independent servers using simple identifiers, eliminating the need for central registries and enhancing privacy through distributed control.[19]