Direct linking V2

[csillag]

Linking directly to annotation as an overlay on the original source, not via an interstitial page.

Spec is here.

[csillag]

So, my first partial implementation will use the browser's local storage to store the ID of the target annotation before following the link, and recovering that info in the H implementation loading at the other, and then focusing on the wanted annotation.

Any objections?

[csillag]

For anyone interested, this is all I plan to do (minimal plan):

For now, I just want to cover the two most simple use cases:

• going to a page that has H embedded
• going somewhere with the extension switched on.

So, the plan to implement would be this:

• When clicking on the source link on an annotation card (that's displayed on the stream page, or a user stream, or the standalone page), currently we go to the actual document. I would keep the link target as it is, BUT
• I would add a hook that before we go there, we put a small package of information to the browser's local store, and
• When we deploy on a page, I want to check if the browser's local store has a "stored command' for this page, which would include the URL, the timestamp, and an annotation ID.
• If we have a stored command, and we are within the predetermined timeframe (1 min after clicking?), and the page has an annotation matching the stored id, then we would focus on this annotation.

That's all. This is the V0.

This does not interfere with via. Via could implement support for reading the same kind of "stored commands", and then we can think about what should be the default target of those links at the annotation cards.

But for now, I just want to get the basics to work.

/cc @ikreymer

[csillag]

Some background thinking:

It would be nice to specify the target annotation inside the URL; that would make it possible to save the URL, or open it on a new tab, or share it directly with someone else, etc.

However, I don't think we can just wantonly add random stuff to the URIs handled by others; many pages use the URL for encoding requests, so that's just won't do. Therefore, we need to look for an out-of-band channel for passing the information about the annotation that we want to focus at.

VIA could work around this, by encoding the wanted annotation ID and the URL separately in a common URI, and the decouple it on server side, and fetch the document itself using the "clean" URL; but I want to tackle the non-via usecase now.

So, the URL is out. What remains is

• instructions stored on the server side
• instructions stored on the client side.

I find the client side cleaner, and less prone to various unintended consequences, so I am going to go with that. Hence, browser local store it is. (For v0, at least.)

Comments are welcome, as always, but since we are having hack days, I think I'll just build it anyway :)

[dwhly]

@csillag In your referenced issues above, I think you've captured the background info that I would have linked to.

[csillag]

@dwhly, Do you mean the spec available here?

If yes, then I'll only cover a small part of it during these 2 days.

Also, it looks like

• this docs has been written before via appeared on the scene. As far as I can tell, link form 4 ("context link") is what is is most similar to via. Maybe we could revise that section to match more closely with the way via actually works?
• this docs doesn't even contain the dead simple implementation method that I want to try first. (link form 2b a.k.a. "pure source link": simply link to the target without messing with the URI, and store the info about the target annotation separately, elsewhere.) Or to be more precise, this method is only mentioned in a comment, and isn't part of the actual document.

Anyway, what I plan to implement first is only one variant of one of the 4 listed methods here. We can add the rest later.

[nickstenning]

Closing as old and out of date. Big features like "direct linking" will come down the product prioritisation and design processes.

[dwhly]

Moved here: hypothesis/vision#87