Discovery is
the first step.
A public profile check answers a useful, narrow question: can this service discover and read the profile your server advertises?
1. Find the profile
For a full handle, we request WebFinger information from its server and look for an ActivityPub profile link. For a website URL, we try public ActivityPub data or an advertised ActivityPub link in the page. Not every website advertises its profile this way, so a full handle is usually the best starting point.
2. Read the public information
We check whether the advertised address returns a recognizable ActivityPub actor, with an identifier and an inbox address. An inbox is where federation messages are sent; its presence does not prove the server will accept or process messages.
3. Explain the result
A successful result means discovery worked from our checker at that time. An unsuccessful result may reflect incomplete setup, a server that blocks automated requests, a temporary outage, or an address that doesn’t advertise a profile. It is not proof that federation is disabled.
What we do not test
- We do not send follow requests, posts, replies, or other federation messages.
- We do not verify HTTP message signatures or moderation compatibility between servers.
- We do not establish that posts reach followers, or that every app renders them the same way.
- We do not certify identity, ownership, privacy, or server security.
Public addresses only
The checker accepts public HTTPS addresses. It validates DNS answers and redirects, restricts response sizes, and limits request time. Private network addresses and local hosts are rejected.
Close the loop with a real delivery test.
Follow from a separate server, publish a new public post, and inspect what arrives.
Test your first post →Protocol references: W3C ActivityPub and Mastodon WebFinger documentation.