Make sure links to messages work with OneBox

[plexus]

Discourse (which Clojureverse runs on) uses the onebox Ruby gem to render links. If we can make sure that onebox renders our links, then that would be a really useful thing for Clojureverse.

For starters we could simply add oEmbed or Open Graph to the page, but individual messages are addressed with url fragments, which aren't visible to the server.

We could change that though, so each message has its own "proper" url. The main downside is that it blows up the address space, and thus the amount of caching needed.

We could also extend OneBox to parse these message links including the fragment, and pull out and render the right message (or thread). Not sure if we can get that upstream, but we could probably do it in a discourse plugin that we load separately.

[Odie]

It looks like it's possible to customize Discourse on a per-install basis by adding custom plugins.
https://gist.github.com/cfstras/8824566
shows an example of adding support for additional sites. We shouldn't have to worry about getting that added upstream.

However, enabling embedding on a per message or per thread basis via oEmbed seems nice though. Other apps, hopefully, automatically gain the ability to embed content from the log.

[Odie]

So, I played around with adding a dummy oEmbed response to the app to see if the onebox lib can fetch it.

Here's the full flow that needs to be implemented for oEmbed to function correctly:

1. A user needs to be able to get a hold of a permalink for a specific message
2. An external service/app will use the permalink to fetch just the message itself.
   For the purposes of embedding, the content of this response is unimportant. All that is need is for a "application/json+oembed" link to be present in the html head element.
3. The external service will use the json+oembed in step 2 to fetch a json response
   The json response should contain some metadata and some html fragment wrapped in an iframe for embedding.

What we really want an external service to get access to is 3. But to get there, we need to embed a discovery link in 2. And to get there, we need to implement 1. It's a bit unfortunate, but that's what's needed to let other services to be able to embed content from the log-app. Alternatively, if we just want embedding to work on clojureverse, we can certainly just write a small Discourse plugin and be done with it.

Anyway, if we want to add oEmbed to the log-app, we need to discuss the following:
a. What should the permalink format be? Does it need to be generated?
b. How will the user get a hold of the permalink?
c. If the user tries to load the permalink in a browser, what should he see? The message? The entire thread?

[plexus]

Permalinks could simply be /channel/date/slack-ts. We do need to keep the anchors so that existing links don't break, i.e. /channel/date#formatted-timestamp.

A user can get a permalink by clicking on the message time, same as now.

I would maybe do OpenGraph first, since that's pretty straightforward (just some extra tags in the [:head]), and it's widely supported thanks to Facebook's dominance, including by Discourse. Adding Twitter cards would be easy as well.

A link to a single message should just render that message (with avatar, timestamp, channel, etc). If it's the start of a thread it should render the thread, but maybe limited to a few replies. If it's a reply I would render the message, and then "in reply to ", or something in that vein.

[Odie]

Permalinks could simply be /channel/date/slack-ts. We do need to keep the anchors so that existing links don't break, i.e. /channel/date#formatted-timestamp.

Making sure existing links don't break sound reasonable. Is it okay to keep using timestamps though? Feels like this would sometimes accidentally break when two messages have the same ts. It probably makes little to no difference when displaying the entire log for the day, since having an identical ts can be taken to mean that order doesn't matter.

But if we're linking to a single message, wouldn't it make sense to make sure it actually does uniquely identifies a message? Even something simple that records, say, the import order of the messages would help to make sure ts collisions are not possible.

[Odie]

I would maybe do OpenGraph first, since that's pretty straightforward (just some extra tags in the [:head]), and it's widely supported thanks to Facebook's dominance, including by Discourse. Adding Twitter cards would be easy as well.

That sounds straight forward. Should have a PR ready before too long. (Though I do think being able to control the exact presentation is nice.)

[plexus]

Is it okay to keep using timestamps though? Feels like this would sometimes accidentally break when two messages have the same ts.

Slack's "ts" is used in Slack's API as a sort of primary key, it is guaranteed to be unique within a channel. It has a very fine resolution so I suppose they twiddle with those nanoseconds when two messages do arrive at the same time.

[Odie]

Okay...

After playing with this for a bit, here's what it looks like in the FB open graph debugger.

And here's what it looks like when onebox embeds the message in Discourse:

The layout is dictated by the default template that comes with onebox. I'll try to open a PR with this in a bit. Unfortunately, it's not super straightforward to play with and test the output at the moment. I'm using the onebox library to generate the html fragment and manually insert it into the page via Chrome DevTools.

[plexus]

Very cool! Are you starting from current master? Those <@USERNAME> bits should be parsed and rendered properly by now.

[Odie]

Yeah, I'm working from master. I was just pulling out the targeted :message/text as a test. There is still a bit of work to clean things up. Will try running the message through slack-messages/render-hiccup.

[plexus]

Thanks a lot @Odie, it's been really great to have this.