cmd/bsky-webhook: add support for facets

[Erisa]

Reference: https://docs.bsky.app/docs/advanced-guides/post-richtext
Fixes #9

Tested working with links, mentions, and tags. Seeking a quick review to ensure I didn't commit any Go crimes in the process.

[creachadair]

An optional general suggestion:

For parameters in small scopes where their meaning is close to its use, it's fine (and indeed conventionally preferable) to choose less verbose names. Since the type is right here, this could be message or even simply msg, there is only one message involved here.

In particular, I recommend against re-stating the type of a declared variable in the name, unless for some reason it makes a distinction (e.g., "fooString" vs. "fooBytes" if we had both formats to deal with)

[creachadair]

return cmp.Compare(a.Index.ByteStart, b.Index.ByteStart)

[creachadair]

Though if you really care about stability, maybe what we want here is a tie breaker, e.g.,

if c := cmp.Compare(a.Index.ByteStart, b.Index.ByteStart); c != 0 {
   return c
}
return cmp.Compare(b.Index.ByteEnd, a.Index.ByteEnd)

or something like that (so they have proper nesting order within the ties)

YMMV.

[creachadair]

By convention these should be URI and DID.

[creachadair]

Do we need the names explicitly here? It appears we only use these for decoding, and the JSON decoder does a case-insensitive match anyway. (We do need $type because of the spelling difference, but I mean the others)

[creachadair]

Maybe a comment noting the expected format? (Is this RFC3339 or something?)

[creachadair]

Could maybe have bskyMessageToSlackMarkup handle this case so you don't have to check for it here? (Actually I think it might already)

[creachadair]

I think this loop could be simplified quite a bit with a helper method:

func (b BskyFacet) featureURI() string {
   for _, feat := range b.Features {
      switch feat.URI {
      case "app.bsky.richtext.facet#link":
         return feat.URI
      case "app.bsky.richtext.facet#mention":
         return fmt.Sprintf("https://bsky.app/profile/%s", feat.DID)
      case "app.bsky.richtext.facet#tag":
         return fmt.Sprintf("https://bsky.app/hashtag/%s", feat.Tag)
      }
   }
   return ""
}

Then the whole body of the (outer) loop can be something like:

for _, frag := range fragments {
   if uri := frag.featureURI(); uri != "" {
      fmt.Fprintf(&sb, "<%s|%s>", uri, frag.Text)
   } else {
      sb.WriteString(frag.Text)
   }
}

(Note as illustrated here, you can use the builder as an io.Writer and format directly into it)

[creachadair]

I don't think this needs to say so much, there's only one string builder here:

var sb strings.Builder

[creachadair]

If I understand correctly, the delicate dance with indices here is something to do with the fact that facets are specified by offsets into the base text?

Given that you went to the trouble of ordering them above, maybe this could be turned into a helper that uses slices.BinarySearch (or even just scans them linearly—there aren't going to be that many, we don't need to worry about asymptotics I think) to find the relevant fragment for each facet? (Even if we do care, we already spent O(n lg n) to sort them, so spending another n lg n to probe them won't affect the underlying shape)

I am sort of convinced this does what I described above, but index dancing is hard to follow, so I would suggest we try to be more obvious here.

(Then too, I think maybe we don't need to do any additional appending, since the facet decorations could be glued directly into place on the facet fragment they belong to I think?)