[hack day] Search sharing (with VIA)

[csillag]

It would be nice to be able to share a page (via VIA) with a specific set of annotations selected.

Specification is here.

Being implemented here by @csillag, @ikreymer and @gergely-ujvari, as per the feature request by @emvincent, with input from @jeremydean and @tilgovi.

Parts needed:

• Server-side API to save and retrieve search queries - @gergely-ujvari is working on this
• VIA: ability to take a parameter from the URL, and pass it to embed.js - @ikreymer can tackle this
• H embed code: ability to take a parameter from the URL
• H client side:
  • Share this search feature - @csillag
  • Share this selection feature - @csillag
  • Ability to load and execute a selected search or selection - @csillag
  • Extra emphasis for selected annotations (See PR) - @csillag

[judell]

A possible simplification: No server-side API, just pass annotation ids (trivially, a single one) through via.

#2215
#2012

[tilgovi]

I think we quickly run into a situation where we have to pick a deliberately strange and obfuscated thing to tack on the end of the URL hoping that it won't be ambiguous with respect to an actual query parameter for the original page.

And then we have to ask ourselves why we shouldn't just use local storage or something.

[ikreymer]

I think there are two options as far as via. I think thus far we've been leaning towards 1) (I haven't had a chance to add it yet).

1. https://via.hypothes.is/<ID>/http://example.com/
   Via parses server side and passes in to javascript as part of the inject script.
   This requires some server-side changes but not much.

2. https://via.hypothes.is/http://example.com/#<ID>
   This requires essentially no server side changes, but is a bit more tricky, as the embed script should essentially strip of the <ID> first thing, in case there is an existing anchor and the site will use the anchor in some way. Care must be taken to ensure <ID> is actually is part of hypothesis and not the site's own anchor. But I think it is doable, since the inject script runs first thing. I think, however, option 1) has been preferred thus far, and is probably safer overall.

In both cases, <ID> is opaque and could represent either a single annotation ID that requires no further lookup, or some server side ID that maps to multiple annotation IDs.. You could support both by using different semantics for the iD. I think that is separate from how the <ID> is actually delivered to the client.

[judell]

*just use local storage *

It wasn't immediately clear to me how that would work, I'm capturing
@tilgvovi's explanation from elsewhere:

It wouldn't require via. Given an URL like:

hypothes.is/p/XyZAbC

we'd have "a page load within which to save that information"

On Wed, May 6, 2015 at 3:59 PM, Randall Leeds notifications@github.com
wrote:

I think we quickly run into a situation where we have to pick a
deliberately strange and obfuscated thing to tack on the end of the URL
hoping that it won't be ambiguous with respect to an actual query parameter
for the original page.

And then we have to ask ourselves why we shouldn't just use local storage
or something.

—
Reply to this email directly or view it on GitHub
#2193 (comment).

[csillag]

A possible simplification: No server-side API, just pass annotation ids (trivially, a single one) through via.

The feature request (by @emvincent) that sparkled this work needs at least a list of user IDs. Just working with one annotation ID (or a list of IDs) won't cut it.

[csillag]

I think we quickly run into a situation where we have to pick a deliberately strange and obfuscated thing to tack on the end of the URL hoping that it won't be ambiguous with respect to an actual query parameter for the original page.

We can put it to a different place inside the VIA url, instead of the end of the URL for the original place. (For example, before the URL.)

And then we have to ask ourselves why we shouldn't just use local storage or something.

That was my original proposal, too. We have discussed that at length. (See here.)

We decided against it, because passing a single ID via VIA (before the URL, not appended to it) seems to be an easy and clean way, and then we can store an arbitrary long and complex data structure at the server side (identified by the ID), which is easier than trying to squeeze all the info into the URL somehow.

[tilgovi]

Right now #2215 tracks a piece of this work and hypothesis/vision#43 describes the greater goals in user-facing terms. If there are individual pieces you'd like to work on, I suggest opening separate issues. As this doesn't really constitute an issue or bug in the h repo right now, I think I'm going to close this and suggest that discussion about how to implement this move to the mailing list.

[tilgovi]

Also hypothesis/vision#142