Connections

The web was designed around resources connected through hyperlinks. A publisher can link to another person’s work, introduce visitors to interesting sites, reply to an article, or credit a collaborator—without sharing a database or joining the same platform.

Publishing content and participating in a conversation are related but not identical. Ordinary hyperlinks connect resources. Metadata can describe those relationships. Protocols such as Webmention can notify another site that a connection exists. A decentralized social web can emerge from many independently controlled sites speaking compatible standards.

You own your content, control the links you publish, and decide whether to receive or display interactions from other websites.

How websites found and talked to each other

Hyperlinks made the World Wide Web a web. Personal homepages, blogrolls, directories, webrings, and comments helped people find one another. Earlier cross-site notifications—refbacks, trackbacks, and pingbacks—showed the need for verifiable mentions. Webmention emerged as a simpler W3C Recommendation: notify a target that a source links to it, then verify the link.

The IndieWeb movement emphasizes personal domains as homes for content. Microformats2 describes posts; Webmention notifies; Micropub publishes; IndieAuth authorizes; WebSub delivers updates. ActivityPub (2018) is a broader W3C Recommendation for federated social networking. Each specification has its own origin, status, and job—do not treat them as interchangeable.

Not every connection means the same thing

A link is an observable fact about a published page. Its meaning depends on context.

Direction matters: a link from A to B does not imply B links to A. Two sites discussing the same topic do not establish a direct connection. Shared interests, common outbound links, or network membership are not proof of friendship.

A simple link is already a connection

<a href="https://friends.joshua.example/">
  Visit another independent website
</a>

Absolute and relative URLs, stable permalinks, and descriptive anchor text help people and crawlers. Prefer linking to individual articles or projects when that is the intended destination—not only homepages. Redirects and broken links change what visitors actually reach. No extra protocol is required for a hyperlink to work. See Links and relations.

Recommend the websites worth visiting

Blogrolls introduce visitors to independent writers, artists, and developers. Descriptions beat unlabeled URL dumps.

<section>
  <h2>Sites I read</h2>
  <ul>
    <li>
      <a href="https://friends.joshua.example/">Friend’s Notes</a>
      — short essays on photography and feeds.
    </li>
    <li>
      <a href="https://other.example/">Other Studio</a>
      — tools and open-source experiments.
    </li>
  </ul>
</section>

OPML can distribute machine-readable subscription lists. The community rel="blogroll" convention advertises a blogroll document; it is not an IANA-registered link relation:

<link
  rel="blogroll"
  type="text/x-opml"
  href="https://joshua.example/blogroll.opml"
>

Including a site in a blogroll is a publisher-declared listing—not reciprocal friendship, and not proof that the owners have met.

Webrings and community directories

Webrings, personal directories, blogroll networks, topic indexes, and curated collections organize independent sites without turning them into a single social network. Being listed by a third party differs from explicitly declaring membership. A webring can offer previous / next / random navigation while each site stays independently hosted:

<nav aria-label="Webring">
  <a href="https://other.example/ring/prev?site=joshua.example">Previous</a>
  <a href="https://other.example/ring/">Ring home</a>
  <a href="https://other.example/ring/next?site=joshua.example">Next</a>
</nav>

Membership rules belong to each community—not to a universal hyperlink specification.

Let another website know you linked to it

Webmention is a W3C Recommendation for notifying a target that a source contains a link to it. Roles: source, target, endpoint, sender, receiver, discovery, notification, and source verification.

Webmention does not publish the original post—the source already exists. The receiver must verify the link instead of trusting the notification alone.

1. Publish The source page links to the target.
2. Discover The sender finds the target’s Webmention endpoint.
3. Notify The sender POSTs source and target URLs.
4. Verify The receiver fetches the source and confirms the link.
5. Decide The receiver may record, moderate, display, or ignore the mention.

A successful notification does not automatically create a visible comment.

How Webmention works

1. Website B (friends.joshua.example) publishes a post linking to an article on Website A (joshua.example).
2. B retrieves A’s target page and discovers a Webmention endpoint.
3. B sends an HTTP POST with source and target.
4. A validates the URLs and whether the target is accepted.
5. A retrieves the source and checks that it actually links to the target.
6. A may record, moderate, or display the verified mention.
7. When B updates or deletes the source, B can notify again so A can re-check.

Discovering a Webmention endpoint

Discovery mechanisms in the Recommendation include HTTP Link headers and HTML <link> / <a> with rel="webmention". Relative endpoint URLs resolve against the target. Preserve query parameters already present on the endpoint. Follow the specification’s precedence when multiple endpoints are advertised.

<link rel="webmention" href="https://joshua.example/webmention">

Link: <https://joshua.example/webmention>; rel="webmention"

Sending a Webmention

POST /webmention HTTP/1.1
Host: joshua.example
Content-Type: application/x-www-form-urlencoded

source=https%3A%2F%2Ffriends.joshua.example%2Freplies%2F42%2F&target=https%3A%2F%2Fjoshua.example%2Fnotes%2Flab%2F

Use POST with form encoding, source, and target. Receivers may respond with 200, 201, or 202; a Location header can point at a status URL for asynchronous processing.

curl -i -X POST 'https://joshua.example/webmention' \
  -d 'source=https://friends.joshua.example/replies/42/' \
  -d 'target=https://joshua.example/notes/lab/'

Substitute the real endpoint discovered from the target.

Never trust the notification alone

Receivers should validate schemes, reject identical source and target, confirm the target is an accepted resource, retrieve the source (with bounded redirects), verify the actual link, handle unsupported types, avoid unsafe duplicates, and queue verification. Invalid URLs, missing sources, and surprising redirects should fail closed. Successful verification and rejected notifications are both normal outcomes.

Webmention updates and deletions

When outbound links change, replies are edited, or source pages disappear (including HTTP 410), senders should re-notify; receivers should re-discover endpoints when needed and not assume a once-verified mention stays forever. Periodic re-verification is optional. Receiving a deletion-related notification is not the same as immediately deleting a local record—apply your retention policy.

Webmention moderation and presentation

Receiving and displaying are separate decisions. Use moderation queues, spam filters, sender blocks, sanitization, limited quotations, attribution, and privacy review. Presentation models include comments, replies, mentions, likes, reposts, and backlinks. Webmention verifies a link; Microformats2 (or similar) classifies the interaction. Not every mention is a comment or endorsement.

Explain what the connection means

Microformats2 can describe relationships between posts. Common properties: h-entry, u-in-reply-to, u-like-of, u-repost-of, u-syndication, p-author, u-url, dt-published, e-content. These are property classes, not IANA-registered HTML rel tokens.

<article class="h-entry">
  <a class="u-url" href="https://friends.joshua.example/replies/42/">
    Permalink
  </a>
  <p>
    In reply to
    <a class="u-in-reply-to" href="https://joshua.example/notes/lab/">
      the original article
    </a>
  </p>
  <div class="e-content">
    <p>I enjoyed this article and wanted to add another example.</p>
  </div>
</article>

Parsed (abridged):

{
  "type": ["h-entry"],
  "properties": {
    "url": ["https://friends.joshua.example/replies/42/"],
    "in-reply-to": ["https://joshua.example/notes/lab/"],
    "content": [
      {
        "value": "I enjoyed this article and wanted to add another example.",
        "html": "<p>I enjoyed this article and wanted to add another example.</p>"
      }
    ]
  }
}

Webmention communicates that the source exists and links; Microformats2 describes how it relates. See Microformats2.

Reply from your own website

1. Read the original article on joshua.example.
2. Write a reply on your site (friends.joshua.example).
3. Give it a stable permalink.
4. Link to the original URL.
5. Add u-in-reply-to (and author markup as you like).
6. Discover the target’s Webmention endpoint.
7. Send the Webmention.
8. Check whether the receiver accepted and processed it.

If the target has no Webmention endpoint, the reply still lives on your site and the ordinary hyperlink still connects the resources. Lack of Webmention does not block open-web participation.

Likes, reposts and reactions

A reply adds content; a like expresses appreciation (u-like-of); a repost shares or references existing content (u-repost-of); a quotation may add commentary; a syndicated copy is a distribution of your own work. Receivers choose how to display them. A repost is not authorship of the original—attribute and respect copyright.

Syndication: publish on your own site first

POSSE—Publish (on your) Own Site, Syndicate Elsewhere—keeps the canonical original on your domain and links out to copies with u-syndication. PESOS—Publish Elsewhere, Syndicate to Own Site—imports from elsewhere; the original may live off-site. Permalinks, updates, deletes, and attribution differ by strategy. Third-party copies follow that service’s rules and permissions.

Bring conversations back home

Backfeed associates reactions on syndicated copies with the original. Bridges (for example Bridgy, where current features should be verified against their docs) can connect independent sites with other networks. Matching originals, duplicates, missing URLs, edits, deletes, private content, and identity conflicts are hard. Bridges are optional tools—not standardized parts of Webmention itself. Decide what imported interactions you will display.

Get notified when published content changes

WebSub is a W3C Recommendation (02 June 2026) for delivering updates about a topic through a hub to subscribers. Publishers notify the hub; the hub distributes to callbacks. Subscribers need not poll continuously.

WebSub distributes topic updates. Webmention reports a particular source→target link. They are not the same protocol. The 2026 Recommendation updates security considerations (including XSS-related mitigations)—read that section when implementing.

WebSub discovery and subscription

Discover hubs and topic self-URLs via rel="hub" and rel="self" in HTML or HTTP Link headers (often on feeds). Subscribers send hub.mode, hub.topic, and hub.callback; hubs verify callbacks, grant leases, support renewal and unsubscription. Optional secrets enable authenticated notifications. See the Recommendation for normative parameter names and security requirements.

WebSub delivery and failure handling

Publishers ping hubs; hubs fetch updated content and POST to callbacks; subscribers acknowledge; signatures apply when secrets are configured; retries, duplicates, expiration, and malicious payloads need bounded handling. WebSub is not a full historical archive—pair it with stable entry IDs in feeds.

Publish to your website from another application

Micropub is a W3C Recommendation for a client-to-server API that creates, updates, and deletes posts. Roles: client, server, Micropub endpoint, authenticated user, and optional media endpoint. Micropub manages posts; Webmention reports links; WebSub delivers subscriptions.

Micropub endpoint discovery and configuration

<link rel="micropub" href="https://joshua.example/micropub">

HTTP Link headers may also advertise the endpoint. Configuration queries and media-endpoint discovery are defined by the Recommendation. A discovery link does not make a static site accept posts—something must handle authenticated requests.

Creating, updating and deleting Micropub posts

Create posts with form-encoded bodies (and JSON where supported), typically describing h-entry properties, using an Authorization bearer token from IndieAuth/OAuth. Updates use JSON replace / add / delete operations where implemented. Delete (and optional undelete) are specification actions. Media endpoints are optional. Do not treat every optional feature as required of every server.

POST /micropub HTTP/1.1
Host: joshua.example
Authorization: Bearer REPLACE_WITH_ACCESS_TOKEN
Content-Type: application/x-www-form-urlencoded

h=entry&content=Hello+from+a+Micropub+client&name=Hello

IndieAuth and authorization

Knowing who someone is does not authorize publishing. IndieAuth (see Identity) helps obtain access tokens with scopes for Micropub clients. Cover identity URLs, authorization endpoints, tokens, scopes, validation, expiration, and revocation. Follow the IndieAuth Living Standard and RFC 9700.

Federated social networking

ActivityPub (W3C Recommendation, 2018) and ActivityStreams 2.0 support decentralized social networking: client-to-server and server-to-server federation; actors, objects, activities, inboxes, outboxes, followers, following, collections, delivery, and audience addressing. Mastodon and compatible apps exchange activities across servers. Operating an ActivityPub server is not the same as adding Schema.org JSON-LD to a blog. Ordinary personal sites do not automatically federate.

ActivityPub interactions and delivery

Core activities include Create, Update, Delete, Follow, Accept, Reject, Like, Announce, and Undo. Actors publish and receive activities with stable identifiers; inboxes need deduplication and careful delivery. Authentication and addressing often involve additional profiles. ActivityPub is not a drop-in Webmention replacement.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Create",
  "actor": "https://friends.joshua.example/actors/avery",
  "object": {
    "type": "Note",
    "content": "A short federated note.",
    "id": "https://friends.joshua.example/notes/1"
  }
}

Compare the interaction protocols

Implement what your publishing goals need—not a checklist for Joshternet.

Start with links, add interaction when you need it

1. Publish ordinary links — stable permalinks and meaningful hrefs.
2. Share recommendations — blogroll, links page, or webring nav.
3. Describe interactions — Microformats2 for replies, likes, syndication.
4. Send Webmentions — notify compatible targets.
5. Receive Webmentions — endpoint, verification, moderation.
6. Publish via clients — Micropub + authorization.
7. Distribute or federate — WebSub or ActivityPub when justified.

These are adoption stages, not mandatory dependencies. Operational cost rises with each layer.

Complete website implementation example

A (joshua.example) publishes /notes/lab/ and advertises rel="webmention". B (friends.joshua.example) publishes /replies/42/ with u-in-reply-to, discovers A’s endpoint, and POSTs source/target. A validates, fetches B’s HTML, verifies the link, reads Microformats2, queues moderation, and may display the reply. Later B edits or deletes the reply and re-notifies; A re-verifies. Optionally B authored the reply through Micropub—not required for the Webmention path.

Static-site implementation considerations

Static generators (Jekyll, Hugo, Eleventy, custom) can emit permalinks, Microformats2, and outbound Webmention sends at build or deploy time. Receiving Webmentions or running Micropub needs a dynamic endpoint or external service, plus storage and moderation before approved interactions re-enter the next build. Deduplicate submissions across deploys.

Moderation, privacy and publisher control

Spam, harassment, unwanted mentions, blocks, sanitization, link rot, copyright, consent, retention, and visitor privacy are operational realities. You are not obligated to display every verified mention. Prefer linking to originals over republishing restricted remote content.

Security considerations

Treat remote data as untrusted: SSRF, private IPs, DNS rebinding, redirect abuse, oversized responses, parser bombs, HTML/JS injection, CSRF, unsafe schemes, spoofed mentions, fake authorship, replays, duplicates, unsafe WebSub callbacks, missing signatures, OAuth token leakage, ActivityPub auth gaps, rate limits, and timeouts. Webmention receivers must verify the source link before acting. WebSub subscribers should verify signed deliveries when secrets are used. Micropub must enforce authorization and scopes. Follow each specification’s security sections.

Know why a connection exists

Useful provenance: source site, source URL, target URL, relation type, evidence type, observed time, verification status, last checked, updated/removed. Categories such as observed, publisher-declared, protocol-verified, reciprocally verified, and manually confirmed help readers—without inventing a universal trust system. An observed link is stronger than a shared topic and still not friendship.

Connections and the Joshternet

Links among member sites help visitors explore people, projects, and publications. Outbound hyperlinks, blogrolls, replies, reposts, syndication, and credits are different signals—not interchangeable with shared topics, Josh identity, or participation.

Joshternet’s hub records observed, directed edges between current participants only: homepage-link, content-link, blogroll, reply-to, repost-of, syndication, and credit, with observed evidence. Blogroll ads use <link rel="blogroll" type="text/xml"> (caps apply). It does not infer friendship or topic edges, does not create edges from /.well-known/josh, and does not send or receive Webmention, WebSub, Micropub, IndieAuth, or ActivityPub. Credit typing may use link-text heuristics—not independently verified collaboration. The public Connections view is evidence, not a follow graph. Details: Implement → Connections, Reference.

Validate Webmention implementations

Use the Recommendation and webmention.rocks: discovery variants, relative endpoints, query preservation, form encoding, responses, invalid URLs, redirects, source verification, duplicates, updates, and deletes. Passing one sender test does not prove a secure receiver.

Validate WebSub implementations

Use websub.rocks (verify availability) against the June 2026 Recommendation: hub/self discovery, subscribe/verify/renew/unsubscribe, delivery, signatures, duplicates, and HTTP requirements.

Validate Micropub implementations

Use micropub.rocks: discovery, authorization, form/JSON create, Location headers, update/delete where supported, media endpoints, configuration, scopes, and errors. Never treat anonymous posts as success.

Validate ActivityPub implementations

Actor documents, AS2 JSON-LD, inbox/outbox, identifiers, collections, federation delivery, deduplication, audience, auth, and update/delete behavior all matter. A valid actor document alone is not a full federated server. Use the W3C Recommendation and available interop tests.

Common mistakes

Continue through the handbook

• Semantic HTML
• Slash pages
• OPML
• Microformats2
• Feeds
• Links and relations
• Identity and authorship
• Creative media
• Validation
• Reference

Handbook navigation below follows content_nav (previous: Identity and authorship; next: Creative media).

Specifications and references