Hello,
When someone using Matrix uploads an image into an IRC channel, the image is uploaded to the Matrix servers, and a link is pasted into the IRC channel. This link contains the image inside angle brackets. That confuses some URL catchers (like the Sakura terminal emulator) and think that the angle bracket is part of the URL.
Could you please change it to include spaces between the angle brackets and the URL, or something else that won't append random characters?
Thanks!
This is a follow-on from https://github.com/matrix-org/matrix-appservice-irc/issues/258#issuecomment-357493849. That one's closed, so let's continue the discussion here.
Agreed that < http://foo > would be better.
sorted :)
The spaces are actually somewhat problematic; using _exactly_ angle brackets to delimit URIs in context is standard practice laid out in the RFCs, and the additional spaces inside introduce ambiguity relative to that.
Specifically, clients can no longer use the angle brackets to say "Okay, the inside is _definitely_ a whole URI with no junk at the ends." (Incidentally, problems arising from that - such as "not linkifying the closing parenthesis in Wikipedia links" - are why the angle brackets are there at all, rather than being left off entirely).
The issue here should probably be reported to Sakura upstream, as they are not in concordance with the relevant specifications, and 5c97f364ff74abf2c1be4a16b4bf4229aabaf254 possibly reverted.
Most helpful comment
The spaces are actually somewhat problematic; using _exactly_ angle brackets to delimit URIs in context is standard practice laid out in the RFCs, and the additional spaces inside introduce ambiguity relative to that.
Specifically, clients can no longer use the angle brackets to say "Okay, the inside is _definitely_ a whole URI with no junk at the ends." (Incidentally, problems arising from that - such as "not linkifying the closing parenthesis in Wikipedia links" - are why the angle brackets are there at all, rather than being left off entirely).
The issue here should probably be reported to Sakura upstream, as they are not in concordance with the relevant specifications, and 5c97f364ff74abf2c1be4a16b4bf4229aabaf254 possibly reverted.