Bug generating Bluesky post facets when text includes [ ] brackets

[snarfed]

Original:

• https://flipboard.social/@TechDesk/113595595024808829
• https://browser.pub/https://flipboard.social/@TechDesk/113595595024808829

Bridged:

• https://bsky.app/profile/TechDesk.flipboard.social.ap.brid.gy/post/3lcimk7zy2gy2
• https://atproto-browser.vercel.app/at/TechDesk.flipboard.social.ap.brid.gy/app.bsky.feed.post/3lcimk7zy2gy2

[Tamschi]

That's two bugs in one. Any Markdown control characters need to be escaped (because otherwise it'll break for posts that contain e.g. [a](https://example.com/) as plain text), and it seems the Markdown-to-Bluesky conversion doesn't behave like most Markdown processors would.

Fortunately, it seems like fixing the first one would obscure the second.

[snarfed]

it seems the Markdown-to-Bluesky conversion doesn't behave like most Markdown processors would

Hmm! We don't currently expect or parse any external data as Markdown afaik, our use of Markdown is entirely a (small) internal implementation detail that shouldn't cause externally-visible bugs like this.

[Tamschi]

it seems the Markdown-to-Bluesky conversion doesn't behave like most Markdown processors would

Hmm! We don't currently expect or parse any external data as Markdown afaik, our use of Markdown is entirely a (small) internal implementation detail that shouldn't cause externally-visible bugs like this.

No, Bridgy Fed does in fact parse all external content as Markdown right now since it doesn't escape Markdown control characters.
As I wrote, doing so will likely hide irregularities with the implementation though, as long as it handles those escape sequences well.

This is about the same issue as #1380 where no HTML escape is performed when converting to HTML for ActivityPub.

[snarfed]

Oh, I thought you meant deliberately parse Markdown, as in expect it anywhere inbound. Unintentionally, on the other hand, yes. 😁