From 38e7ca20d598711eeff6b8b64ad0c59e7f4c4632 Mon Sep 17 00:00:00 2001
From: Rye <git@itsrye.dev>
Date: Thu, 7 May 2026 01:45:45 +0200
Subject: [PATCH 01/12] initial commit of draft followup MSC

Signed-off-by: Rye <git@itsrye.dev>
---
 proposals/0000-verifiable-links-in-profile.md | 281 ++++++++++++++++++
 1 file changed, 281 insertions(+)
 create mode 100644 proposals/0000-verifiable-links-in-profile.md

diff --git a/proposals/0000-verifiable-links-in-profile.md b/proposals/0000-verifiable-links-in-profile.md
new file mode 100644
index 00000000000..75a5c350e0d
--- /dev/null
+++ b/proposals/0000-verifiable-links-in-profile.md
@@ -0,0 +1,281 @@
+# MSC0000: Verifiable Links in Profile
+
+A lot of other chat platforms (like Discord) and social media platforms (like Mastodon, Sharkey, ...)
+allow you to put a list of links in your profile which then get verified.
+
+In the fediverse (e.g. Mastodon) it is simply done by crawling the linked site and searching for
+links with the `rel="me"` attribute.
+
+Matrix Homeservers could do the same and mark a link upon request by a client as verified.
+
+## Proposal
+
+### The role of the homeserver
+
+A homeserver SHOULD provide an a client-server API endpoint to verify link relationship against
+under `/_matrix/client/v1/verify_link_relationship`. The result of the link verification SHOULD
+be cached for some amount of time (*implementation detail*). The homeserver SHOULD add a `expires`
+field to the response, to indicate after what point in time a verification should be considered outdated,
+after that time a client SHOULD reverify.
+
+A homeserver MAY choose to disable the `/_matrix/client/v1/verify_link_relationship` by it's respective
+configuration. Since there can be a lot of verification requests on a big homeserver, a ratelimit may be
+applied (in which case a HTTP 429 should be returned).
+
+To prevent potentially infinite redirect loops, a restriction on the amount of redirects SHOULD be applied.
+A homeserver MAY use a blocklist/allowlist if it want's to filter what links they try to verify. However
+a homeserver MUST prevent verification requests pointing to restricted addresses
+([RFC1918](https://www.rfc-editor.org/info/rfc1918), localhost, ...).
+
+To verify a relationship it MUST match the full MXID (after normalization).
+
+As a client may wish to display additional information regarding a link (especially if the link is a
+web address) a homeserver MAY include url preview information with the response.
+
+A homeserver SHOULD allow verification request towards subpages (e.g. `https://example.org/about`), but MUST
+NOT mark the whole domain as verified for the mxid, it SHOULD as well allow multiple matrix-account-links
+per page.
+
+#### Verification Methods
+
+##### Relationship
+
+A homeserver
+
+- MAY derive the cache time from the `cache-control` http response header.
+- SHOULD upon request, with a payload defined below, fetch that link, parse, and check
+if the relationship is given
+- MAY restrict from which hosts websites can be fetched from for verification, similar
+to link previews
+- SHOULD enforce content-type (e.g. HTML only)
+- MUST parse static HTML (no JS execution)
+- MAY discard the verification and mark it as failed if the http response exceeds 1MB in size
+- SHOULD NOT regard links in `<iframe>`, even if they would pass the verification
+- MUST treat `rel` as ASCII case-insensitive
+
+A homeserver checks the verification by checking for elements of type `a` or `link` with the relationship me
+([`rel="ME"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/me)).
+A simple link (without the relationship) MUST NOT result in verifying a link relationship.
+As a reference developers could see Mastodon's approach (see
+[mastodon docs](https://docs.joinmastodon.org/user/profile/#verification)).
+
+##### DNS
+
+A homeserver SHOULD also offer DNS based link verification, by checking the domain for a
+`_matrix-verification.DOMAIN` txt record containing a comma separated list of mxids.
+If a domain has been verified by DNS record all subpages of the domain MUST also be marked as verified.
+However, if a subdomain has been DNS verified, the root domain MUST NOT be marked as verified.
+A homeserver SHOULD respect the DNS records TTL for it's caching.
+
+Example txt record for `_matrix-verification.example.org`:
+
+```
+"@alice:example.org,@bob:example.org"
+```
+
+This example should result in the homeserver verifying the whole domain for both `@alice:example.org`
+and `@bob:example.org`.
+
+For the format of a MXID, the [grammar of a user identifier in the spec](https://spec.matrix.org/v1.18/appendices/#user-identifiers) finds application.
+
+##### Matrix
+
+A relationship between matrix users SHOULD be marked as verified if they have a bidirectional link towards
+each other. In other words if `@alice:example.org` links to `@alice:example.com` the link MUST only be verified
+if `@alice:example.com` also links back to `@alice:example.org`.
+
+A homeserver would check this by requesting the profiles of both `@alice:example.org` and `@alice:example.com`,
+and checks if they link to each other. If they don't link to each other it SHOULD be treated as a failed
+verification. If a error during lookup occurs it SHOULD be treated as an erroring verification (see 
+verification with `error` as result below).
+
+#### Payload for the endpoint
+
+A client SHOULD, when wanting to check a link-user-relationship, send a payload like the following to
+the `/_matrix/client/v1/verify_link_relationship` endpoint.
+
+```json
+{
+    "link": "https://example.org",
+    "method": "m.method.dns" | "m.method.relation" | "m.method.matrix",
+    // the mxid to check against, not the mxid of the user initiating the request
+    "mxid": "@alice:example.org",
+}
+```
+
+The homeserver SHOULD consider both the
+[`matrix.to` address](https://spec.matrix.org/v1.18/appendices/#matrixto-navigation)
+(e.g. `https://matrix.to/#/@alice:example.org`) and the
+[`matrix` URI](https://spec.matrix.org/v1.18/appendices/#matrix-uri-scheme)
+(e.g. `matrix:u/alice:example.org`) scheme.
+
+A homeserver SHOULD consider when evaluating a `matrix.to` address could also be encoded (e.g. `https://matrix.to/#/%40example%3Aexample.org`).
+
+#### Response format
+
+For **successful verifications**, homeservers SHOULD respond to the client with the following:
+
+```json
+{
+    "verification": {
+        "result": "success",
+        "method": "m.method.dns" | "m.method.relation" | "m.method.matrix",
+        // expiry should be defined as the unix epoch after which to try again
+        "expires": "1778107123",
+        "scope": "m.scope.site" | "m.scope.domain" | "m.scope.account"
+    },
+    // optional additional url preview stuff
+    "preview_url": {
+        // same format as defined for url preview responses
+        // see https://spec.matrix.org/v1.18/client-server-api/#get_matrixclientv1mediapreview_url
+    }
+}
+```
+
+The scope field describes the extent of the verified relationship:
+
+- `m.scope.site` indicates verification of a specific URL (related to `m.method.relation`)
+- `m.scope.domain` indicates verification of an entire domain and its subpages (related
+to `m.method.dns`)
+- `m.scope.account` indicates verification of an account-level identifier (e.g. a Matrix user ID,
+related to `m.method.matrix`)
+
+While the `scope` and `method` fields may appear redundant, the `scope` field makes the
+extent, it however does not say anything about the strength of verification, of a verification result explicit. This allows clients to interpret verification
+results without relying on method-specific behavior (e.g. determining whether a verification
+applies to a single URL or an entire domain).
+
+Additionally, including `scope` allows for future extensibility, where new verification methods
+may be introduced without requiring clients to infer the scope from the method.
+
+For **failed verifications**, homeservers SHOULD respond to the client with the following:
+
+```json
+{
+    "verification": {
+        "result": "not_found" | "error" | "verification_failed",
+        "method": "m.method.dns" | "m.method.relation" | "m.method.matrix",
+        "expires": "1778107123"
+    }
+}
+```
+
+A failure occurs when either the number of redirects has been reached, a http error occurs (i.e. 4xx, 5xx errors),
+or a DNS resolution error occurs.
+In cases of http request failures a homeserver MAY progressively increase the time until the next try.
+In cases where the http request has been successful, the verification however wasn't the homeserver SHOULD respect
+the website's `cache-control` header and set the `verification` field to `verification_failed`.
+
+For **rate-limited** request, homeservers SHOULD respond with a 429 response like the following
+
+```json
+{
+  "errcode": "M_LIMIT_EXCEEDED",
+  "error": "Too many requests",
+  "retry_after_ms": 2000
+}
+```
+
+Note that this is the same response a client would get for a rate-limited url preview request.
+
+### The role of the client
+
+#### Storage in the user profile
+
+This proposal builds on [MSC4462: Links in Profile](https://github.com/matrix-org/matrix-spec-proposals/pull/4462)
+and extends it's `m.links` field in the user profile, with `verification_method` as an attribute describing how
+the link can be verified.
+
+Example of the extended `m.links` field:
+
+```json
+{
+   "m.links": [
+     {
+        "description": "homepage",
+        "link": "https://example.org",
+        "verification_method": "m.method.dns"
+     },
+     {
+        "description": "mastodon",
+        "link": "https://mastodon.social/@example",
+        "verification_method": "m.method.relation"
+     },
+     {
+        "description": "alt-account",
+        "link": "matrix:u/alice:example.org",
+        "verification_method": "m.method.matrix"
+     }
+   ]
+}
+```
+
+The value of `verification_method` may either be `m.method.dns`, `m.method.relation`,
+or `m.method.matrix`. If it is unset clients MAY use the same behaviour as for `m.method.relation`
+or mark the link as unverified.
+
+#### Verifying a link
+
+Clients
+
+- MUST NOT mark a link as verified unless the homeserver marks the link as verified
+- SHOULD use the format specified in "Payload for the endpoint" to request verification from homeserver
+- MAY cache the result until the `expires` date if the verification has been successful
+- SHOULD consider the verification as outdated after `expires` has passed and reverify
+- SHOULD treat outdated verification as a link being unverified
+- MAY cache failures to not overwhelm the homeserver with requests
+- SHOULD cache failed verifications until `expires` has passed
+- MAY hide unverified links from the user
+
+### Summary
+
+A link MUST only be marked as verified if a verifiable relationship exists between the MXID and the `link`,
+established via one of the supported methods.
+
+Depending on the method:
+
+- Relationship- and Matrix-based verification REQUIRE bidirectional linking
+- DNS-based verification establishes domain-level authority and does not require a backlink from the target resource
+
+Small but notable difference between the verification methods: DNS-based verification verifies domain-level authority, whereas matrix- and relationship based verification verify link-level reciprocity.
+
+## Potential issues
+
+### Single Page Sites using JavaScript
+
+Nowadays a lot of sites are heavily reliant on the execution of JavaScript for their content.
+There is a case in allowing parsing after JavaScript execution to allow more sites.
+
+However, that would open an attack vector and require a JavaScript runtime on the homeserver, therefore
+the link must be present in static HTML, or using the DNS method.
+
+## Alternatives
+
+### Verifying a link client side
+
+A verification of links in the way this proposal proposes it for homeservers to act, could also be done by clients.
+
+However, this would have considerable security implications:
+
+- fetching a arbitrary website (in that exposing the client ip to potentially malicious actors)
+- rendering a arbitrary website (could end up as an attack vector for cross side scripting)
+- a lot of requests to a website, if a lot of users look at one's profile (a homeserver could cache the verification result)
+
+## Security considerations
+
+- A website could trigger cyclic redirects, therefore a server MUST enforce a limit on redirects, see above
+- DNS-based verification proves that the operator of a domain asserts an association with a given MXID. It
+does not prove that the MXID owner controls the domain.
+
+## Unstable prefix
+
+implementations should use
+
+- `fyi.cisnt.links` instead of `m.links`
+- `fyi.cisnt.method.*` instead of `m.method.*`
+- `fyi.cisnt.scope.*` instead of `m.scope.*`
+- `/_matrix/client/unstable/fyi.cisnt.links/verify_link_relationship` instead of `/_matrix/client/v1/verify_link_relationship`
+
+## Dependencies
+
+[MSC4462 (Links in Profile)](https://github.com/matrix-org/matrix-spec-proposals/pull/4462)
\ No newline at end of file

From 6a12c9488f628854a6c60ec9e7051542b6bbb222 Mon Sep 17 00:00:00 2001
From: Rose <git@itsrye.dev>
Date: Thu, 7 May 2026 01:50:11 +0200
Subject: [PATCH 02/12] Clarify 'scope' field in verification results

Clarify the role of the 'scope' field in verification.
---
 proposals/0000-verifiable-links-in-profile.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/proposals/0000-verifiable-links-in-profile.md b/proposals/0000-verifiable-links-in-profile.md
index 75a5c350e0d..b503c3f4cf5 100644
--- a/proposals/0000-verifiable-links-in-profile.md
+++ b/proposals/0000-verifiable-links-in-profile.md
@@ -141,7 +141,7 @@ to `m.method.dns`)
 related to `m.method.matrix`)
 
 While the `scope` and `method` fields may appear redundant, the `scope` field makes the
-extent, it however does not say anything about the strength of verification, of a verification result explicit. This allows clients to interpret verification
+extent, not the strength, of a verification result explicit. This allows clients to interpret verification
 results without relying on method-specific behavior (e.g. determining whether a verification
 applies to a single URL or an entire domain).
 
@@ -278,4 +278,4 @@ implementations should use
 
 ## Dependencies
 
-[MSC4462 (Links in Profile)](https://github.com/matrix-org/matrix-spec-proposals/pull/4462)
\ No newline at end of file
+[MSC4462 (Links in Profile)](https://github.com/matrix-org/matrix-spec-proposals/pull/4462)

From c7d41746a46dfc1f7978b2aafc0cf659c4f7d120 Mon Sep 17 00:00:00 2001
From: Rye <git@itsrye.dev>
Date: Thu, 7 May 2026 04:05:50 +0200
Subject: [PATCH 03/12] updated naming in line with updates to MSC4462

Signed-off-by: Rye <git@itsrye.dev>
---
 proposals/0000-verifiable-links-in-profile.md | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/proposals/0000-verifiable-links-in-profile.md b/proposals/0000-verifiable-links-in-profile.md
index b503c3f4cf5..69fe93bd17c 100644
--- a/proposals/0000-verifiable-links-in-profile.md
+++ b/proposals/0000-verifiable-links-in-profile.md
@@ -13,12 +13,12 @@ Matrix Homeservers could do the same and mark a link upon request by a client as
 ### The role of the homeserver
 
 A homeserver SHOULD provide an a client-server API endpoint to verify link relationship against
-under `/_matrix/client/v1/verify_link_relationship`. The result of the link verification SHOULD
+under `/_matrix/client/v1/verify_profile_connection`. The result of the link verification SHOULD
 be cached for some amount of time (*implementation detail*). The homeserver SHOULD add a `expires`
 field to the response, to indicate after what point in time a verification should be considered outdated,
 after that time a client SHOULD reverify.
 
-A homeserver MAY choose to disable the `/_matrix/client/v1/verify_link_relationship` by it's respective
+A homeserver MAY choose to disable the `/_matrix/client/v1/verify_profile_connection` by it's respective
 configuration. Since there can be a lot of verification requests on a big homeserver, a ratelimit may be
 applied (in which case a HTTP 429 should be returned).
 
@@ -53,7 +53,7 @@ to link previews
 - SHOULD NOT regard links in `<iframe>`, even if they would pass the verification
 - MUST treat `rel` as ASCII case-insensitive
 
-A homeserver checks the verification by checking for elements of type `a` or `link` with the relationship me
+A homeserver checks the verification by checking for elements of type `a` or `uri` with the relationship me
 ([`rel="ME"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/me)).
 A simple link (without the relationship) MUST NOT result in verifying a link relationship.
 As a reference developers could see Mastodon's approach (see
@@ -92,11 +92,11 @@ verification with `error` as result below).
 #### Payload for the endpoint
 
 A client SHOULD, when wanting to check a link-user-relationship, send a payload like the following to
-the `/_matrix/client/v1/verify_link_relationship` endpoint.
+the `/_matrix/client/v1/verify_profile_connection` endpoint.
 
 ```json
 {
-    "link": "https://example.org",
+    "uri": "https://example.org",
     "method": "m.method.dns" | "m.method.relation" | "m.method.matrix",
     // the mxid to check against, not the mxid of the user initiating the request
     "mxid": "@alice:example.org",
@@ -183,27 +183,27 @@ Note that this is the same response a client would get for a rate-limited url pr
 #### Storage in the user profile
 
 This proposal builds on [MSC4462: Links in Profile](https://github.com/matrix-org/matrix-spec-proposals/pull/4462)
-and extends it's `m.links` field in the user profile, with `verification_method` as an attribute describing how
+and extends it's `m.connections` field in the user profile, with `verification_method` as an attribute describing how
 the link can be verified.
 
-Example of the extended `m.links` field:
+Example of the extended `m.connections` field:
 
 ```json
 {
-   "m.links": [
+   "m.connections": [
      {
         "description": "homepage",
-        "link": "https://example.org",
+        "uri": "https://example.org",
         "verification_method": "m.method.dns"
      },
      {
         "description": "mastodon",
-        "link": "https://mastodon.social/@example",
+        "uri": "https://mastodon.social/@example",
         "verification_method": "m.method.relation"
      },
      {
         "description": "alt-account",
-        "link": "matrix:u/alice:example.org",
+        "uri": "matrix:u/alice:example.org",
         "verification_method": "m.method.matrix"
      }
    ]
@@ -229,7 +229,7 @@ Clients
 
 ### Summary
 
-A link MUST only be marked as verified if a verifiable relationship exists between the MXID and the `link`,
+A link MUST only be marked as verified if a verifiable relationship exists between the MXID and the `uri`,
 established via one of the supported methods.
 
 Depending on the method:
@@ -271,10 +271,10 @@ does not prove that the MXID owner controls the domain.
 
 implementations should use
 
-- `fyi.cisnt.links` instead of `m.links`
+- `fyi.cisnt.connections` instead of `m.connections`
 - `fyi.cisnt.method.*` instead of `m.method.*`
 - `fyi.cisnt.scope.*` instead of `m.scope.*`
-- `/_matrix/client/unstable/fyi.cisnt.links/verify_link_relationship` instead of `/_matrix/client/v1/verify_link_relationship`
+- `/_matrix/client/unstable/fyi.cisnt.connections/verify_profile_connection` instead of `/_matrix/client/v1/verify_profile_connection`
 
 ## Dependencies
 

From ebb31451150299eee6e5e64720bf6620ce03f447 Mon Sep 17 00:00:00 2001
From: Rye <git@itsrye.dev>
Date: Thu, 7 May 2026 04:15:48 +0200
Subject: [PATCH 04/12] line wraps to 80

Signed-off-by: Rye <git@itsrye.dev>
---
 proposals/0000-verifiable-links-in-profile.md | 234 +++++++++++-------
 1 file changed, 138 insertions(+), 96 deletions(-)

diff --git a/proposals/0000-verifiable-links-in-profile.md b/proposals/0000-verifiable-links-in-profile.md
index 69fe93bd17c..de20e13ab52 100644
--- a/proposals/0000-verifiable-links-in-profile.md
+++ b/proposals/0000-verifiable-links-in-profile.md
@@ -1,40 +1,46 @@
 # MSC0000: Verifiable Links in Profile
 
-A lot of other chat platforms (like Discord) and social media platforms (like Mastodon, Sharkey, ...)
-allow you to put a list of links in your profile which then get verified.
+A lot of other chat platforms (like Discord) and social media platforms (like
+Mastodon, Sharkey, ...) allow you to put a list of links in your profile which
+then get verified.
 
-In the fediverse (e.g. Mastodon) it is simply done by crawling the linked site and searching for
-links with the `rel="me"` attribute.
+In the fediverse (e.g. Mastodon) it is simply done by crawling the linked site
+and searching for links with the `rel="me"` attribute.
 
-Matrix Homeservers could do the same and mark a link upon request by a client as verified.
+Matrix Homeservers could do the same and mark a link upon request by a client as
+verified.
 
 ## Proposal
 
 ### The role of the homeserver
 
-A homeserver SHOULD provide an a client-server API endpoint to verify link relationship against
-under `/_matrix/client/v1/verify_profile_connection`. The result of the link verification SHOULD
-be cached for some amount of time (*implementation detail*). The homeserver SHOULD add a `expires`
-field to the response, to indicate after what point in time a verification should be considered outdated,
-after that time a client SHOULD reverify.
-
-A homeserver MAY choose to disable the `/_matrix/client/v1/verify_profile_connection` by it's respective
-configuration. Since there can be a lot of verification requests on a big homeserver, a ratelimit may be
-applied (in which case a HTTP 429 should be returned).
-
-To prevent potentially infinite redirect loops, a restriction on the amount of redirects SHOULD be applied.
-A homeserver MAY use a blocklist/allowlist if it want's to filter what links they try to verify. However
-a homeserver MUST prevent verification requests pointing to restricted addresses
+A homeserver SHOULD provide an a client-server API endpoint to verify link
+relationship against under `/_matrix/client/v1/verify_profile_connection`. The
+result of the link verification SHOULD be cached for some amount of time
+(*implementation detail*). The homeserver SHOULD add a `expires` field to the
+response, to indicate after what point in time a verification should be
+considered outdated, after that time a client SHOULD reverify.
+
+A homeserver MAY choose to disable the
+`/_matrix/client/v1/verify_profile_connection` by it's respective configuration.
+Since there can be a lot of verification requests on a big homeserver, a
+ratelimit may be applied (in which case a HTTP 429 should be returned).
+
+To prevent potentially infinite redirect loops, a restriction on the amount of
+redirects SHOULD be applied. A homeserver MAY use a blocklist/allowlist if it
+want's to filter what links they try to verify. However a homeserver MUST
+prevent verification requests pointing to restricted addresses
 ([RFC1918](https://www.rfc-editor.org/info/rfc1918), localhost, ...).
 
 To verify a relationship it MUST match the full MXID (after normalization).
 
-As a client may wish to display additional information regarding a link (especially if the link is a
-web address) a homeserver MAY include url preview information with the response.
+As a client may wish to display additional information regarding a link
+(especially if the link is a web address) a homeserver MAY include url preview
+information with the response.
 
-A homeserver SHOULD allow verification request towards subpages (e.g. `https://example.org/about`), but MUST
-NOT mark the whole domain as verified for the mxid, it SHOULD as well allow multiple matrix-account-links
-per page.
+A homeserver SHOULD allow verification request towards subpages (e.g.
+`https://example.org/about`), but MUST NOT mark the whole domain as verified for
+the mxid, it SHOULD as well allow multiple matrix-account-links per page.
 
 #### Verification Methods
 
@@ -43,29 +49,33 @@ per page.
 A homeserver
 
 - MAY derive the cache time from the `cache-control` http response header.
-- SHOULD upon request, with a payload defined below, fetch that link, parse, and check
-if the relationship is given
-- MAY restrict from which hosts websites can be fetched from for verification, similar
-to link previews
+- SHOULD upon request, with a payload defined below, fetch that link, parse, and
+  check if the relationship is given
+- MAY restrict from which hosts websites can be fetched from for verification,
+  similar to link previews
 - SHOULD enforce content-type (e.g. HTML only)
 - MUST parse static HTML (no JS execution)
-- MAY discard the verification and mark it as failed if the http response exceeds 1MB in size
-- SHOULD NOT regard links in `<iframe>`, even if they would pass the verification
+- MAY discard the verification and mark it as failed if the http response
+  exceeds 1MB in size
+- SHOULD NOT regard links in `<iframe>`, even if they would pass the
+  verification
 - MUST treat `rel` as ASCII case-insensitive
 
-A homeserver checks the verification by checking for elements of type `a` or `uri` with the relationship me
+A homeserver checks the verification by checking for elements of type `a` or
+`uri` with the relationship me
 ([`rel="ME"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/me)).
-A simple link (without the relationship) MUST NOT result in verifying a link relationship.
-As a reference developers could see Mastodon's approach (see
+A simple link (without the relationship) MUST NOT result in verifying a link
+relationship. As a reference developers could see Mastodon's approach (see
 [mastodon docs](https://docs.joinmastodon.org/user/profile/#verification)).
 
 ##### DNS
 
-A homeserver SHOULD also offer DNS based link verification, by checking the domain for a
-`_matrix-verification.DOMAIN` txt record containing a comma separated list of mxids.
-If a domain has been verified by DNS record all subpages of the domain MUST also be marked as verified.
-However, if a subdomain has been DNS verified, the root domain MUST NOT be marked as verified.
-A homeserver SHOULD respect the DNS records TTL for it's caching.
+A homeserver SHOULD also offer DNS based link verification, by checking the
+domain for a `_matrix-verification.DOMAIN` txt record containing a comma
+separated list of mxids. If a domain has been verified by DNS record all
+subpages of the domain MUST also be marked as verified. However, if a subdomain
+has been DNS verified, the root domain MUST NOT be marked as verified. A
+homeserver SHOULD respect the DNS records TTL for it's caching.
 
 Example txt record for `_matrix-verification.example.org`:
 
@@ -73,26 +83,31 @@ Example txt record for `_matrix-verification.example.org`:
 "@alice:example.org,@bob:example.org"
 ```
 
-This example should result in the homeserver verifying the whole domain for both `@alice:example.org`
-and `@bob:example.org`.
+This example should result in the homeserver verifying the whole domain for both
+`@alice:example.org` and `@bob:example.org`.
 
-For the format of a MXID, the [grammar of a user identifier in the spec](https://spec.matrix.org/v1.18/appendices/#user-identifiers) finds application.
+For the format of a MXID, the
+[grammar of a user identifier in the spec](https://spec.matrix.org/v1.18/appendices/#user-identifiers)
+finds application.
 
 ##### Matrix
 
-A relationship between matrix users SHOULD be marked as verified if they have a bidirectional link towards
-each other. In other words if `@alice:example.org` links to `@alice:example.com` the link MUST only be verified
-if `@alice:example.com` also links back to `@alice:example.org`.
+A relationship between matrix users SHOULD be marked as verified if they have a
+bidirectional link towards each other. In other words if `@alice:example.org`
+links to `@alice:example.com` the link MUST only be verified if
+`@alice:example.com` also links back to `@alice:example.org`.
 
-A homeserver would check this by requesting the profiles of both `@alice:example.org` and `@alice:example.com`,
-and checks if they link to each other. If they don't link to each other it SHOULD be treated as a failed
-verification. If a error during lookup occurs it SHOULD be treated as an erroring verification (see 
-verification with `error` as result below).
+A homeserver would check this by requesting the profiles of both
+`@alice:example.org` and `@alice:example.com`, and checks if they link to each
+other. If they don't link to each other it SHOULD be treated as a failed
+verification. If a error during lookup occurs it SHOULD be treated as an
+erroring verification (see verification with `error` as result below).
 
 #### Payload for the endpoint
 
-A client SHOULD, when wanting to check a link-user-relationship, send a payload like the following to
-the `/_matrix/client/v1/verify_profile_connection` endpoint.
+A client SHOULD, when wanting to check a link-user-relationship, send a payload
+like the following to the `/_matrix/client/v1/verify_profile_connection`
+endpoint.
 
 ```json
 {
@@ -109,11 +124,13 @@ The homeserver SHOULD consider both the
 [`matrix` URI](https://spec.matrix.org/v1.18/appendices/#matrix-uri-scheme)
 (e.g. `matrix:u/alice:example.org`) scheme.
 
-A homeserver SHOULD consider when evaluating a `matrix.to` address could also be encoded (e.g. `https://matrix.to/#/%40example%3Aexample.org`).
+A homeserver SHOULD consider when evaluating a `matrix.to` address could also be
+encoded (e.g. `https://matrix.to/#/%40example%3Aexample.org`).
 
 #### Response format
 
-For **successful verifications**, homeservers SHOULD respond to the client with the following:
+For **successful verifications**, homeservers SHOULD respond to the client with
+the following:
 
 ```json
 {
@@ -134,21 +151,25 @@ For **successful verifications**, homeservers SHOULD respond to the client with
 
 The scope field describes the extent of the verified relationship:
 
-- `m.scope.site` indicates verification of a specific URL (related to `m.method.relation`)
-- `m.scope.domain` indicates verification of an entire domain and its subpages (related
-to `m.method.dns`)
-- `m.scope.account` indicates verification of an account-level identifier (e.g. a Matrix user ID,
-related to `m.method.matrix`)
+- `m.scope.site` indicates verification of a specific URL (related to
+  `m.method.relation`)
+- `m.scope.domain` indicates verification of an entire domain and its subpages
+  (related to `m.method.dns`)
+- `m.scope.account` indicates verification of an account-level identifier (e.g.
+  a Matrix user ID, related to `m.method.matrix`)
 
-While the `scope` and `method` fields may appear redundant, the `scope` field makes the
-extent, not the strength, of a verification result explicit. This allows clients to interpret verification
-results without relying on method-specific behavior (e.g. determining whether a verification
-applies to a single URL or an entire domain).
+While the `scope` and `method` fields may appear redundant, the `scope` field
+makes the extent, not the strength, of a verification result explicit. This
+allows clients to interpret verification results without relying on
+method-specific behavior (e.g. determining whether a verification applies to a
+single URL or an entire domain).
 
-Additionally, including `scope` allows for future extensibility, where new verification methods
-may be introduced without requiring clients to infer the scope from the method.
+Additionally, including `scope` allows for future extensibility, where new
+verification methods may be introduced without requiring clients to infer the
+scope from the method.
 
-For **failed verifications**, homeservers SHOULD respond to the client with the following:
+For **failed verifications**, homeservers SHOULD respond to the client with the
+following:
 
 ```json
 {
@@ -160,13 +181,16 @@ For **failed verifications**, homeservers SHOULD respond to the client with the
 }
 ```
 
-A failure occurs when either the number of redirects has been reached, a http error occurs (i.e. 4xx, 5xx errors),
-or a DNS resolution error occurs.
-In cases of http request failures a homeserver MAY progressively increase the time until the next try.
-In cases where the http request has been successful, the verification however wasn't the homeserver SHOULD respect
-the website's `cache-control` header and set the `verification` field to `verification_failed`.
+A failure occurs when either the number of redirects has been reached, a http
+error occurs (i.e. 4xx, 5xx errors), or a DNS resolution error occurs. In cases
+of http request failures a homeserver MAY progressively increase the time until
+the next try. In cases where the http request has been successful, the
+verification however wasn't the homeserver SHOULD respect the website's
+`cache-control` header and set the `verification` field to
+`verification_failed`.
 
-For **rate-limited** request, homeservers SHOULD respond with a 429 response like the following
+For **rate-limited** request, homeservers SHOULD respond with a 429 response
+like the following
 
 ```json
 {
@@ -176,15 +200,17 @@ For **rate-limited** request, homeservers SHOULD respond with a 429 response lik
 }
 ```
 
-Note that this is the same response a client would get for a rate-limited url preview request.
+Note that this is the same response a client would get for a rate-limited url
+preview request.
 
 ### The role of the client
 
 #### Storage in the user profile
 
-This proposal builds on [MSC4462: Links in Profile](https://github.com/matrix-org/matrix-spec-proposals/pull/4462)
-and extends it's `m.connections` field in the user profile, with `verification_method` as an attribute describing how
-the link can be verified.
+This proposal builds on
+[MSC4462: Links in Profile](https://github.com/matrix-org/matrix-spec-proposals/pull/4462)
+and extends it's `m.connections` field in the user profile, with
+`verification_method` as an attribute describing how the link can be verified.
 
 Example of the extended `m.connections` field:
 
@@ -210,18 +236,22 @@ Example of the extended `m.connections` field:
 }
 ```
 
-The value of `verification_method` may either be `m.method.dns`, `m.method.relation`,
-or `m.method.matrix`. If it is unset clients MAY use the same behaviour as for `m.method.relation`
-or mark the link as unverified.
+The value of `verification_method` may either be `m.method.dns`,
+`m.method.relation`, or `m.method.matrix`. If it is unset clients MAY use the
+same behaviour as for `m.method.relation` or mark the link as unverified.
 
 #### Verifying a link
 
 Clients
 
-- MUST NOT mark a link as verified unless the homeserver marks the link as verified
-- SHOULD use the format specified in "Payload for the endpoint" to request verification from homeserver
-- MAY cache the result until the `expires` date if the verification has been successful
-- SHOULD consider the verification as outdated after `expires` has passed and reverify
+- MUST NOT mark a link as verified unless the homeserver marks the link as
+  verified
+- SHOULD use the format specified in "Payload for the endpoint" to request
+  verification from homeserver
+- MAY cache the result until the `expires` date if the verification has been
+  successful
+- SHOULD consider the verification as outdated after `expires` has passed and
+  reverify
 - SHOULD treat outdated verification as a link being unverified
 - MAY cache failures to not overwhelm the homeserver with requests
 - SHOULD cache failed verifications until `expires` has passed
@@ -229,43 +259,54 @@ Clients
 
 ### Summary
 
-A link MUST only be marked as verified if a verifiable relationship exists between the MXID and the `uri`,
-established via one of the supported methods.
+A link MUST only be marked as verified if a verifiable relationship exists
+between the MXID and the `uri`, established via one of the supported methods.
 
 Depending on the method:
 
 - Relationship- and Matrix-based verification REQUIRE bidirectional linking
-- DNS-based verification establishes domain-level authority and does not require a backlink from the target resource
+- DNS-based verification establishes domain-level authority and does not require
+  a backlink from the target resource
 
-Small but notable difference between the verification methods: DNS-based verification verifies domain-level authority, whereas matrix- and relationship based verification verify link-level reciprocity.
+Small but notable difference between the verification methods: DNS-based
+verification verifies domain-level authority, whereas matrix- and relationship
+based verification verify link-level reciprocity.
 
 ## Potential issues
 
 ### Single Page Sites using JavaScript
 
-Nowadays a lot of sites are heavily reliant on the execution of JavaScript for their content.
-There is a case in allowing parsing after JavaScript execution to allow more sites.
+Nowadays a lot of sites are heavily reliant on the execution of JavaScript for
+their content. There is a case in allowing parsing after JavaScript execution to
+allow more sites.
 
-However, that would open an attack vector and require a JavaScript runtime on the homeserver, therefore
-the link must be present in static HTML, or using the DNS method.
+However, that would open an attack vector and require a JavaScript runtime on
+the homeserver, therefore the link must be present in static HTML, or using the
+DNS method.
 
 ## Alternatives
 
 ### Verifying a link client side
 
-A verification of links in the way this proposal proposes it for homeservers to act, could also be done by clients.
+A verification of links in the way this proposal proposes it for homeservers to
+act, could also be done by clients.
 
 However, this would have considerable security implications:
 
-- fetching a arbitrary website (in that exposing the client ip to potentially malicious actors)
-- rendering a arbitrary website (could end up as an attack vector for cross side scripting)
-- a lot of requests to a website, if a lot of users look at one's profile (a homeserver could cache the verification result)
+- fetching a arbitrary website (in that exposing the client ip to potentially
+  malicious actors)
+- rendering a arbitrary website (could end up as an attack vector for cross side
+  scripting)
+- a lot of requests to a website, if a lot of users look at one's profile (a
+  homeserver could cache the verification result)
 
 ## Security considerations
 
-- A website could trigger cyclic redirects, therefore a server MUST enforce a limit on redirects, see above
-- DNS-based verification proves that the operator of a domain asserts an association with a given MXID. It
-does not prove that the MXID owner controls the domain.
+- A website could trigger cyclic redirects, therefore a server MUST enforce a
+  limit on redirects, see above
+- DNS-based verification proves that the operator of a domain asserts an
+  association with a given MXID. It does not prove that the MXID owner controls
+  the domain.
 
 ## Unstable prefix
 
@@ -274,7 +315,8 @@ implementations should use
 - `fyi.cisnt.connections` instead of `m.connections`
 - `fyi.cisnt.method.*` instead of `m.method.*`
 - `fyi.cisnt.scope.*` instead of `m.scope.*`
-- `/_matrix/client/unstable/fyi.cisnt.connections/verify_profile_connection` instead of `/_matrix/client/v1/verify_profile_connection`
+- `/_matrix/client/unstable/fyi.cisnt.connections/verify_profile_connection`
+  instead of `/_matrix/client/v1/verify_profile_connection`
 
 ## Dependencies
 

From 5785a267b80ec8782e7de27b61b7ae1192543fda Mon Sep 17 00:00:00 2001
From: Rye <git@itsrye.dev>
Date: Thu, 7 May 2026 17:56:40 +0200
Subject: [PATCH 05/12] added unstable prefix for dns record

Signed-off-by: Rye <git@itsrye.dev>
---
 proposals/0000-verifiable-links-in-profile.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/proposals/0000-verifiable-links-in-profile.md b/proposals/0000-verifiable-links-in-profile.md
index de20e13ab52..0a830ad80ae 100644
--- a/proposals/0000-verifiable-links-in-profile.md
+++ b/proposals/0000-verifiable-links-in-profile.md
@@ -315,6 +315,8 @@ implementations should use
 - `fyi.cisnt.connections` instead of `m.connections`
 - `fyi.cisnt.method.*` instead of `m.method.*`
 - `fyi.cisnt.scope.*` instead of `m.scope.*`
+- `_mscXXXX-verification` instead of `_matrix-verification` for the DNS TXT
+  record
 - `/_matrix/client/unstable/fyi.cisnt.connections/verify_profile_connection`
   instead of `/_matrix/client/v1/verify_profile_connection`
 

From 8be2295f0e81324b918f2a76b7c7ceee15c41a08 Mon Sep 17 00:00:00 2001
From: Rye <git@itsrye.dev>
Date: Thu, 7 May 2026 23:16:13 +0200
Subject: [PATCH 06/12] clarification regarding errors and matrix backlink

Signed-off-by: Rye <git@itsrye.dev>
---
 proposals/0000-verifiable-links-in-profile.md | 29 ++++++++++---------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/proposals/0000-verifiable-links-in-profile.md b/proposals/0000-verifiable-links-in-profile.md
index 0a830ad80ae..123fd988ca0 100644
--- a/proposals/0000-verifiable-links-in-profile.md
+++ b/proposals/0000-verifiable-links-in-profile.md
@@ -68,6 +68,15 @@ A simple link (without the relationship) MUST NOT result in verifying a link
 relationship. As a reference developers could see Mastodon's approach (see
 [mastodon docs](https://docs.joinmastodon.org/user/profile/#verification)).
 
+The homeserver SHOULD consider both the
+[`matrix.to` address](https://spec.matrix.org/v1.18/appendices/#matrixto-navigation)
+(e.g. `https://matrix.to/#/@alice:example.org`) and the
+[`matrix` URI](https://spec.matrix.org/v1.18/appendices/#matrix-uri-scheme)
+(e.g. `matrix:u/alice:example.org`) scheme for the backlink.
+
+A homeserver SHOULD consider when evaluating a `matrix.to` address, that it
+could also be encoded (e.g. `https://matrix.to/#/%40example%3Aexample.org`).
+
 ##### DNS
 
 A homeserver SHOULD also offer DNS based link verification, by checking the
@@ -118,15 +127,6 @@ endpoint.
 }
 ```
 
-The homeserver SHOULD consider both the
-[`matrix.to` address](https://spec.matrix.org/v1.18/appendices/#matrixto-navigation)
-(e.g. `https://matrix.to/#/@alice:example.org`) and the
-[`matrix` URI](https://spec.matrix.org/v1.18/appendices/#matrix-uri-scheme)
-(e.g. `matrix:u/alice:example.org`) scheme.
-
-A homeserver SHOULD consider when evaluating a `matrix.to` address could also be
-encoded (e.g. `https://matrix.to/#/%40example%3Aexample.org`).
-
 #### Response format
 
 For **successful verifications**, homeservers SHOULD respond to the client with
@@ -184,10 +184,12 @@ following:
 A failure occurs when either the number of redirects has been reached, a http
 error occurs (i.e. 4xx, 5xx errors), or a DNS resolution error occurs. In cases
 of http request failures a homeserver MAY progressively increase the time until
-the next try. In cases where the http request has been successful, the
-verification however wasn't the homeserver SHOULD respect the website's
-`cache-control` header and set the `verification` field to
-`verification_failed`.
+the next try, in these cases `result` field should be set to `not_found` or
+`error` respectively.
+
+In cases where the http request has been successful, the verification however
+wasn't the homeserver SHOULD respect the website's `cache-control` header and
+set the `result` field to `verification_failed`.
 
 For **rate-limited** request, homeservers SHOULD respond with a 429 response
 like the following
@@ -254,7 +256,6 @@ Clients
   reverify
 - SHOULD treat outdated verification as a link being unverified
 - MAY cache failures to not overwhelm the homeserver with requests
-- SHOULD cache failed verifications until `expires` has passed
 - MAY hide unverified links from the user
 
 ### Summary

From bceaa6eeb2713cdc65a3615091403993078ba2f5 Mon Sep 17 00:00:00 2001
From: Rye <git@itsrye.dev>
Date: Thu, 7 May 2026 23:32:47 +0200
Subject: [PATCH 07/12] expanding on possible alternatives

Signed-off-by: Rye <git@itsrye.dev>
---
 proposals/0000-verifiable-links-in-profile.md | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/proposals/0000-verifiable-links-in-profile.md b/proposals/0000-verifiable-links-in-profile.md
index 123fd988ca0..56fbde35f79 100644
--- a/proposals/0000-verifiable-links-in-profile.md
+++ b/proposals/0000-verifiable-links-in-profile.md
@@ -301,6 +301,26 @@ However, this would have considerable security implications:
 - a lot of requests to a website, if a lot of users look at one's profile (a
   homeserver could cache the verification result)
 
+### Third Party Verification
+
+Another possible alternative would be to rely on a set of supported third-party
+verification services. However, this would require a shared trust model and
+service discovery mechanism across the federation, which would complicate
+deployment and interoperability.
+
+If a clear use case emerges, this could be added later through a new
+`verification_method` value. For example, a Discord integration could use
+`"verification_method": "m.method.discord"`. This proposal therefore leaves
+`verification_method` open for future methods. However this proposal doesn't in
+it self propose third party verification methods.
+
+### Cryptographic Proofs
+
+This is a plausible alternative. However, it would introduce additional protocol
+complexity and key-management requirements, while providing little benefit over
+the existing relationship-based approach already used by established platforms
+such as Mastodon.
+
 ## Security considerations
 
 - A website could trigger cyclic redirects, therefore a server MUST enforce a

From 52c18daa79677309aee0a2f67762ff5c75d7c6e3 Mon Sep 17 00:00:00 2001
From: Rye <git@itsrye.dev>
Date: Thu, 7 May 2026 23:51:02 +0200
Subject: [PATCH 08/12] various changes

- ranging from grammar fixes `it's` -> `its`
- expanding on security considerations
- clarifying the `result` value for failed verifications
- expanded the motivation in the introduction section

Signed-off-by: Rye <git@itsrye.dev>
---
 proposals/0000-verifiable-links-in-profile.md | 45 +++++++++++--------
 1 file changed, 26 insertions(+), 19 deletions(-)

diff --git a/proposals/0000-verifiable-links-in-profile.md b/proposals/0000-verifiable-links-in-profile.md
index 56fbde35f79..a9d1b3d9a60 100644
--- a/proposals/0000-verifiable-links-in-profile.md
+++ b/proposals/0000-verifiable-links-in-profile.md
@@ -7,14 +7,19 @@ then get verified.
 In the fediverse (e.g. Mastodon) it is simply done by crawling the linked site
 and searching for links with the `rel="me"` attribute.
 
-Matrix Homeservers could do the same and mark a link upon request by a client as
-verified.
+This proposal introduces a way for Matrix homeservers to do a relationship based
+(`rel="me"`), as known from the fediverse, but beyond that also a dns and matrix
+backlink (useful for example for alt accounts) verification. This would go a
+long way in establishing more feature parity to other popular platforms.
+
+It would also go a long way in reducing the risk of impersonation and phishing
+for a set of MSC4462 connections in profile.
 
 ## Proposal
 
 ### The role of the homeserver
 
-A homeserver SHOULD provide an a client-server API endpoint to verify link
+A homeserver SHOULD provide a client-server API endpoint to verify link
 relationship against under `/_matrix/client/v1/verify_profile_connection`. The
 result of the link verification SHOULD be cached for some amount of time
 (*implementation detail*). The homeserver SHOULD add a `expires` field to the
@@ -22,14 +27,14 @@ response, to indicate after what point in time a verification should be
 considered outdated, after that time a client SHOULD reverify.
 
 A homeserver MAY choose to disable the
-`/_matrix/client/v1/verify_profile_connection` by it's respective configuration.
+`/_matrix/client/v1/verify_profile_connection` by its respective configuration.
 Since there can be a lot of verification requests on a big homeserver, a
 ratelimit may be applied (in which case a HTTP 429 should be returned).
 
 To prevent potentially infinite redirect loops, a restriction on the amount of
 redirects SHOULD be applied. A homeserver MAY use a blocklist/allowlist if it
-want's to filter what links they try to verify. However a homeserver MUST
-prevent verification requests pointing to restricted addresses
+wants to filter what links they try to verify. However a homeserver MUST prevent
+verification requests pointing to restricted addresses
 ([RFC1918](https://www.rfc-editor.org/info/rfc1918), localhost, ...).
 
 To verify a relationship it MUST match the full MXID (after normalization).
@@ -109,7 +114,7 @@ links to `@alice:example.com` the link MUST only be verified if
 A homeserver would check this by requesting the profiles of both
 `@alice:example.org` and `@alice:example.com`, and checks if they link to each
 other. If they don't link to each other it SHOULD be treated as a failed
-verification. If a error during lookup occurs it SHOULD be treated as an
+verification. If an error during lookup occurs it SHOULD be treated as an
 erroring verification (see verification with `error` as result below).
 
 #### Payload for the endpoint
@@ -168,8 +173,8 @@ Additionally, including `scope` allows for future extensibility, where new
 verification methods may be introduced without requiring clients to infer the
 scope from the method.
 
-For **failed verifications**, homeservers SHOULD respond to the client with the
-following:
+For **failed/erroring verifications**, homeservers SHOULD respond to the client
+with the following:
 
 ```json
 {
@@ -181,15 +186,13 @@ following:
 }
 ```
 
-A failure occurs when either the number of redirects has been reached, a http
-error occurs (i.e. 4xx, 5xx errors), or a DNS resolution error occurs. In cases
-of http request failures a homeserver MAY progressively increase the time until
-the next try, in these cases `result` field should be set to `not_found` or
-`error` respectively.
+The `result` should use the following logic:
 
-In cases where the http request has been successful, the verification however
-wasn't the homeserver SHOULD respect the website's `cache-control` header and
-set the `result` field to `verification_failed`.
+- `not_found` if a http request returns `404`, or a DNS lookup returns
+  `NXDOMAIN`
+- `error` for other errors
+- `verification_failed` if the request was successful the verification however
+  wasn't (i.e. the website loaded as expected but no matching `rel="me"` found)
 
 For **rate-limited** request, homeservers SHOULD respond with a 429 response
 like the following
@@ -211,7 +214,7 @@ preview request.
 
 This proposal builds on
 [MSC4462: Links in Profile](https://github.com/matrix-org/matrix-spec-proposals/pull/4462)
-and extends it's `m.connections` field in the user profile, with
+and extends its `m.connections` field in the user profile, with
 `verification_method` as an attribute describing how the link can be verified.
 
 Example of the extended `m.connections` field:
@@ -312,7 +315,7 @@ If a clear use case emerges, this could be added later through a new
 `verification_method` value. For example, a Discord integration could use
 `"verification_method": "m.method.discord"`. This proposal therefore leaves
 `verification_method` open for future methods. However this proposal doesn't in
-it self propose third party verification methods.
+itself propose third party verification methods.
 
 ### Cryptographic Proofs
 
@@ -328,6 +331,10 @@ such as Mastodon.
 - DNS-based verification proves that the operator of a domain asserts an
   association with a given MXID. It does not prove that the MXID owner controls
   the domain.
+- When a homeserver performs a verification (especially for relationship based
+  verification) it initiates a connection to an arbitrary website, which could
+  lead to leak some meta data to the website operator (similar to homeserver
+  based url previews)
 
 ## Unstable prefix
 

From 55f917f32ef5dd1d2e70c58791e82aad294442e0 Mon Sep 17 00:00:00 2001
From: Rye <git@itsrye.dev>
Date: Fri, 8 May 2026 12:45:18 +0200
Subject: [PATCH 09/12] updated MSC to include the actual MSC number

Signed-off-by: Rye <git@itsrye.dev>
---
 ...inks-in-profile.md => 4464-verifiable-links-in-profile.md} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename proposals/{0000-verifiable-links-in-profile.md => 4464-verifiable-links-in-profile.md} (99%)

diff --git a/proposals/0000-verifiable-links-in-profile.md b/proposals/4464-verifiable-links-in-profile.md
similarity index 99%
rename from proposals/0000-verifiable-links-in-profile.md
rename to proposals/4464-verifiable-links-in-profile.md
index a9d1b3d9a60..fb3f20664ff 100644
--- a/proposals/0000-verifiable-links-in-profile.md
+++ b/proposals/4464-verifiable-links-in-profile.md
@@ -1,4 +1,4 @@
-# MSC0000: Verifiable Links in Profile
+# MSC4464: Verifiable Links in Profile
 
 A lot of other chat platforms (like Discord) and social media platforms (like
 Mastodon, Sharkey, ...) allow you to put a list of links in your profile which
@@ -343,7 +343,7 @@ implementations should use
 - `fyi.cisnt.connections` instead of `m.connections`
 - `fyi.cisnt.method.*` instead of `m.method.*`
 - `fyi.cisnt.scope.*` instead of `m.scope.*`
-- `_mscXXXX-verification` instead of `_matrix-verification` for the DNS TXT
+- `_msc4464-verification` instead of `_matrix-verification` for the DNS TXT
   record
 - `/_matrix/client/unstable/fyi.cisnt.connections/verify_profile_connection`
   instead of `/_matrix/client/v1/verify_profile_connection`

From 171288778a4aed53cc6bc1890f1710727ef8e900 Mon Sep 17 00:00:00 2001
From: Rye <git@itsrye.dev>
Date: Fri, 8 May 2026 12:56:14 +0200
Subject: [PATCH 10/12] fix: uri -> link html element

Signed-off-by: Rye <git@itsrye.dev>
---
 proposals/4464-verifiable-links-in-profile.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/4464-verifiable-links-in-profile.md b/proposals/4464-verifiable-links-in-profile.md
index fb3f20664ff..70db274351f 100644
--- a/proposals/4464-verifiable-links-in-profile.md
+++ b/proposals/4464-verifiable-links-in-profile.md
@@ -67,7 +67,7 @@ A homeserver
 - MUST treat `rel` as ASCII case-insensitive
 
 A homeserver checks the verification by checking for elements of type `a` or
-`uri` with the relationship me
+`link` with the relationship me
 ([`rel="ME"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/me)).
 A simple link (without the relationship) MUST NOT result in verifying a link
 relationship. As a reference developers could see Mastodon's approach (see

From ac5ae4c1916e344dd5c6ae04df992adf67d67b90 Mon Sep 17 00:00:00 2001
From: Rye <git@itsrye.dev>
Date: Fri, 8 May 2026 22:40:19 +0200
Subject: [PATCH 11/12] adjusted the request to the endpoint to be a GET
 request

Signed-off-by: Rye <git@itsrye.dev>
---
 proposals/4464-verifiable-links-in-profile.md | 29 +++++++++----------
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/proposals/4464-verifiable-links-in-profile.md b/proposals/4464-verifiable-links-in-profile.md
index 70db274351f..ca21fe66512 100644
--- a/proposals/4464-verifiable-links-in-profile.md
+++ b/proposals/4464-verifiable-links-in-profile.md
@@ -27,9 +27,10 @@ response, to indicate after what point in time a verification should be
 considered outdated, after that time a client SHOULD reverify.
 
 A homeserver MAY choose to disable the
-`/_matrix/client/v1/verify_profile_connection` by its respective configuration.
-Since there can be a lot of verification requests on a big homeserver, a
-ratelimit may be applied (in which case a HTTP 429 should be returned).
+`/_matrix/client/v1/verify_profile_connection` endpoint by its respective
+configuration. Since there can be a lot of verification requests on a big
+homeserver, a ratelimit may be applied (in which case a HTTP 429 should be
+returned).
 
 To prevent potentially infinite redirect loops, a restriction on the amount of
 redirects SHOULD be applied. A homeserver MAY use a blocklist/allowlist if it
@@ -117,20 +118,18 @@ other. If they don't link to each other it SHOULD be treated as a failed
 verification. If an error during lookup occurs it SHOULD be treated as an
 erroring verification (see verification with `error` as result below).
 
-#### Payload for the endpoint
+#### Request to the endpoint
 
-A client SHOULD, when wanting to check a link-user-relationship, send a payload
-like the following to the `/_matrix/client/v1/verify_profile_connection`
-endpoint.
+A client SHOULD, when wanting to check a link-user-relationship, send a `GET`
+Request to the `/_matrix/client/v1/verify_profile_connection` endpoint.
 
-```json
-{
-    "uri": "https://example.org",
-    "method": "m.method.dns" | "m.method.relation" | "m.method.matrix",
-    // the mxid to check against, not the mxid of the user initiating the request
-    "mxid": "@alice:example.org",
-}
-```
+The request should set the following query parameters:
+
+- `uri` the uri a client wants to verify (example: `https://example.org`)
+- `mxid` the mxid to check against, not the mxid of the user initiating the
+  request (example: `@alice:example.org`)
+- `method` the verification method to use (accepted values: `m.method.dns`,
+  `m.method.relation`, or `m.method.matrix`)
 
 #### Response format
 

From 01c904c795af565ac7fe2282fa971e91448701eb Mon Sep 17 00:00:00 2001
From: Rose <git@itsrye.dev>
Date: Wed, 20 May 2026 20:26:08 +0200
Subject: [PATCH 12/12] Fix expires field format in verification object

---
 proposals/4464-verifiable-links-in-profile.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proposals/4464-verifiable-links-in-profile.md b/proposals/4464-verifiable-links-in-profile.md
index ca21fe66512..4c0b1cd4a38 100644
--- a/proposals/4464-verifiable-links-in-profile.md
+++ b/proposals/4464-verifiable-links-in-profile.md
@@ -142,7 +142,7 @@ the following:
         "result": "success",
         "method": "m.method.dns" | "m.method.relation" | "m.method.matrix",
         // expiry should be defined as the unix epoch after which to try again
-        "expires": "1778107123",
+        "expires": 1778107123,
         "scope": "m.scope.site" | "m.scope.domain" | "m.scope.account"
     },
     // optional additional url preview stuff