I've asked an LLM to analyse that events raw data regarding my issue. Here is its helpful and correct answer:
"The event itself is fine. Judging from the raw data, the problem is most likely in the client, and the comma in the middle of the URL is a prime suspect.
The event itself is clean
The ID and signature are valid, so the event is exactly as the author published it.
The [content] is a normal string. The line breaks ([\n\n]) are escaped correctly.
The URL sits on its own line, with no spaces before or after it and no trailing punctuation.
The URL contains no non-ASCII or invisible characters (no zero-width space, no non-breaking space). The umlauts appear only in the body text.
One oddity: the comma in the URL
The URL contains [2014-,panoramaarchiv277.html]. A comma is allowed in URLs, and NDR evidently uses it in its archive links. But many clients detect links with their own regex, and some exclude the comma because at the end of a sentence it is usually just punctuation. I simulated this:
With a regex like [https?://\S+], the whole URL is recognized.
With [https?://[^\s,]+] or a character class without the comma, the URL is cut off at […Mai-2014-]. The link then points to a page that doesn't exist, or only part of it is rendered as a link.
That would match what you observed: the event is correct, but the client cuts the URL in the wrong place when parsing it.
How to narrow it down
Check whether your client marks only part of the URL as a link (up to […2014-]). If so, the comma is the trigger.
Test with another client (e.g. Damus, Primal, Amethyst, Snort) to see whether the full link is displayed there.
Post a test event with a URL that has no comma. If that one renders correctly, the comma is the cause.
If the link is recognized in full but the page doesn't load: I can't check that, because my attempt to fetch the NDR page was blocked. Open the link directly in a browser. NDR archive pages from 2014 may have been moved or removed, in which case neither the event nor the client is at fault.
If you tell me which client it is and what exactly is displayed (truncated link, no link at all, an error page), I can narrow down the cause further.
Chris Krause
npub15d…ug5zv
2026-10-13 07:05:41 UTC
in reply to nevent1q…xuj5
Author Public Key
npub15dccx7yuxu6gs5ak4elylwxzgxucxy6qdm3ztlfmluwfr7n2u9hq4ug5zvPublished at
2026-10-13 07:05:41 UTCEvent JSON
{
"id": "f8874637d878496486c5283fb8f67421ba9c4208f291ce9e6f2e91add2f63799",
"pubkey": "a37183789c37348853b6ae7e4fb8c241b98313406ee225fd3bff1c91fa6ae16e",
"created_at": 1791875141,
"kind": 1,
"tags": [
[
"e",
"540be26ffb93d754746acb9483e8155a5865eb11775ca9ef2a38bbef8725df97",
"",
"root",
"a37183789c37348853b6ae7e4fb8c241b98313406ee225fd3bff1c91fa6ae16e"
],
[
"p",
"a37183789c37348853b6ae7e4fb8c241b98313406ee225fd3bff1c91fa6ae16e",
"wss://nostr.wine/"
],
[
"client",
"nostria"
]
],
"content": "I've asked an LLM to analyse that events raw data regarding my issue. Here is its helpful and correct answer:\n\n\"The event itself is fine. Judging from the raw data, the problem is most likely in the client, and the comma in the middle of the URL is a prime suspect.\n\nThe event itself is clean\n\nThe ID and signature are valid, so the event is exactly as the author published it.\nThe [content] is a normal string. The line breaks ([\\n\\n]) are escaped correctly.\nThe URL sits on its own line, with no spaces before or after it and no trailing punctuation.\nThe URL contains no non-ASCII or invisible characters (no zero-width space, no non-breaking space). The umlauts appear only in the body text.\n\nOne oddity: the comma in the URL\nThe URL contains [2014-,panoramaarchiv277.html]. A comma is allowed in URLs, and NDR evidently uses it in its archive links. But many clients detect links with their own regex, and some exclude the comma because at the end of a sentence it is usually just punctuation. I simulated this:\n\nWith a regex like [https?://\\S+], the whole URL is recognized.\nWith [https?://[^\\s,]+] or a character class without the comma, the URL is cut off at […Mai-2014-]. The link then points to a page that doesn't exist, or only part of it is rendered as a link.\n\nThat would match what you observed: the event is correct, but the client cuts the URL in the wrong place when parsing it.\n\nHow to narrow it down\n\nCheck whether your client marks only part of the URL as a link (up to […2014-]). If so, the comma is the trigger.\nTest with another client (e.g. Damus, Primal, Amethyst, Snort) to see whether the full link is displayed there.\nPost a test event with a URL that has no comma. If that one renders correctly, the comma is the cause.\nIf the link is recognized in full but the page doesn't load: I can't check that, because my attempt to fetch the NDR page was blocked. Open the link directly in a browser. NDR archive pages from 2014 may have been moved or removed, in which case neither the event nor the client is at fault.\n\nIf you tell me which client it is and what exactly is displayed (truncated link, no link at all, an error page), I can narrow down the cause further.",
"sig": "f11e4c1105536f8315d423548cd0f9b7cd6ce8abc2375c2dc4bbcccbf0ef6e6bfa63412b1fef2b4d8e46e11a8cd296485835c94baa03be1b8f565f8e5347623d"
}