diff --git a/doc/bugs/VURL_verification_failure_on_first_download/comment_2_eca6d2515be111728b71fb19fd3557e1._comment b/doc/bugs/VURL_verification_failure_on_first_download/comment_2_eca6d2515be111728b71fb19fd3557e1._comment
new file mode 100644
index 0000000000..3349141073
--- /dev/null
+++ b/doc/bugs/VURL_verification_failure_on_first_download/comment_2_eca6d2515be111728b71fb19fd3557e1._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2025-01-03T20:59:36Z"
+ content="""
+Thinking about consequences of generalizing this from the web
+special remote to all special remotes that claim urls some more, I came up
+with this scenario:
+
+A special remote claims some urls. But it can also store arbitrary 
+keys that are sent to it by git-annex.
+
+At first, `git-annex addurl --verifiable --relaxed` is used to download one
+of the urls that the special remote claims.
+
+Later, that key gets copied back to the special remote.
+
+Then the special remote *corrupts* the content that was stored on it.
+
+Then, `git-annex get` is used to download the corrupted 
+content from the special remote. Let's say that the special remote, in this
+case, sends the object file that was stored in it, rather than looking up
+the url and retrieving that.
+
+This special remote doesn't do checksum verification itself, so
+retreiveKeyFile succeeds despite the corruption, and returns UnVerified. 
+
+Then git-annex verifies the content. And it fails verification.
+But, since `--relaxed` was used when the VURL was generated, it has no
+size. Which means any content from the special remote should be accepted.
+Even though it's corrupted!
+
+The web special remote doesn't have this problem because it doesn't store
+arbitrary git-annex objects. My conclusion is that a special remote that
+does support storing arbitrary objects in it, and also supports claimUrl,
+cannot work properly with `--relaxed` for VURLs. They could support
+`--fast` still, but this is making me wonder if learning equivilant key
+checksums for VURLs really should be generalized beyond the web special
+remote. 
+
+Maybe special remotes where that does make sense should do
+the same kind of thing that the web special remote does. Then we would be
+looking at an extension to the external special remote protocol, or some
+utility command to use to register the content of a VURL key.
+"""]]