Channels

[dwhly]

Annotations are already happening widely. Starting from any webpage we might want to see the discussion, annotations, and thoughts about it happening elsewhere: Reddit, Twitter, Google Scholar, StackOverflow, etc.

---

Allow people to create (via a plugin architecture perhaps) and users to subscribe to one of potentially many channels they'd like to listen to as they browse in order to see if there are any [conversations / mentions / data] about the page they're on. This could include Reddit, HackerNews, Twitter, Facebook, Wordpress, Tumblr, maybe Rap Genius (if a canonical URL is discoverable)... even potentially archive.org WayBack page version histories, etc.

@tilgovi refers to this as "Persistent Ambient Search".

[csillag]

So... let me see if I get this right.

The idea is to allow the users to subscribe to some of the available channel factories (like Reddit, HN, Twitter, etc), and then when they visit a given URI and deploy H on it, we would use the configured channel factories to derive actual channels for the URI, which would bring in the news about the given URI?

Besides the channel / channel factory thing, this would also involve building the ability to auto-generate annotations out of Reddit / HN / Twitter / whatever mentions / posts - right?

[tilgovi]

I have no idea where the word "factory" comes in to this. The way you've stated things, it sounds like you have a 1:1 correspondence between pages and channels, but if Hypothes.is is a channel right now that's obviously not true.

[csillag]

I have no idea where the word "factory" comes in to this.

Let me explain. A channel is something which has a well-defined content stream. (The definition is probably a set of filter rules.)

In this sense, saying that "Twitter is an annotation channel" would mean that we generate annotations from everything that happens on Twitter, and do something with it.

But I don't think we want to do that (for obvious reason); we just want to create a channel from a subset of traffic happening on Twitter; for example the tweets mentioning a given URI, or maybe a given set of URIs.

When we apply that filter to twitter, we might gate a sane level of traffic, and so we can start to actually create annotations from the tweets matching that filter, then we have an actual annotation channel.

Hence, (if I understand what you want correctly) our Twitter application layer would not be an annotation channel itself (since we would not generate annotations from all twitter traffic); it would just make it possible to create channels for some URIs on demand.

That's why I called it a channel factory.

[tilgovi]

Oh I think it's complicating things to even draw a distinction. There's a Twitter firehose of all tweets, and there are other streams which are smaller (user tweets, list tweets, hashtag streams, etc). All of these are channels. Is there a user interface or technical motivation for a new construct?

[csillag]

There's a Twitter firehose of all tweets, and there are other streams which are smaller (user tweets, list tweets, hashtag streams, etc). All of these are channels.

Yes, because they are all delivering actual, real, already existing tweets.

In contrast, our planned twitter adapter layer would not be a channel, because it would not deliver any annotations by default, because I think we don't want to create annotations from every tweet in the universe. In theory, we could, and then that would really be an annotation channel. But I guess we only want to start to generate actual annotations from tweets when there is a request to generate annotations from a given subset of tweets - and when that happens, then we have an annotation channel, which starts to deliver annotations.

Is there a user interface or technical motivation for a new construct?

That's not really a construct; it's just a concept.

• An annotation channel is something that delivers actual annotations to subscribers. (In our case, it also creates them first.)
• An annotation channel factory is something which makes it possible to create annotation channels.

Looking at the technical level, we will only have one serious construct; the incoming signal adapter layers, which will make it possible to configure various annotation channels, to satisfy various request.

I am calling the adapter layers themselves channels factories instead of channels to emphasize that they are not real channels themselves, because they don't actually deliver content themselves, by default, since we don't want to have a full-fledged "twitter channel", only some sub-sets of it.

If you don't care about this distinction clear while talking about this, you can consider all this to exist in my head only - it probably won't influence what we implement, because I think you want the same thing, you just describe it differently.

[tilgovi]

I'm not understanding still.

because I think we don't want to create annotations from every tweet in the universe.

Details. Unnecessary details. Not needed for this conversation. So the Twitter Channel doesn't have an annotation for every existing tweet. Does that make it any less a channel? Is it now a channel factory? I just don't see what you mean.

[tilgovi]

Oh, I think I see. The wording is just strange to me.

You're saying some adapter service is like a channel factory the same way you might say that something like waffle.io is a kanban board factory because it creates the boards for the GitHub repo you ask rather than them all existing always. The data comes from GitHub, so the content is in GitHub.

I guess. Maybe.

I don't yet see how it's relevant yet to a high level discussion of the user experience of channels.

[csillag]

I just don't see what you mean.

I want mental telepathy RIGHT NOW.

[tilgovi]

Aside: this whole idea of "channels" is orthogonal to what I call "persistent ambient search". Channels are about normalizing data sources, deriving annotations from other kinds of data. Persistent ambient search is about presenting that data passively in the periphery as the user moves around the Web.

[csillag]

So the Twitter Channel doesn't have an annotation for every existing tweet. Does that make it any less a channel?

No. The fact that it does not create (or deliver) any annotations (by default), makes not not a channel.

You're saying some adapter service is like a channel factory the same way you might say that something like waffle.io is a kanban board factory because it creates the boards for the GitHub repo you ask rather than them all existing always.

Pretty close.

The data comes from GitHub, so the content is in GitHub.

When we start to convert data, then we do have an annotation channel; I just wanted to use language that conveys that our ability to convert tweets to annotations is not yet a channel by itself, until we actually turn it on with a concrete request, and start generating annotations.

When we do that, then it's channel (which we have generated for the given request). Since we will probably generate many such channels, I called the source a factory.

I don't yet see how it's relevant yet to a high level discussion of the user experience of channels.

I did not say it has anything to do with the user experience. I just tried to interpret the feature description to verify that I understand it correctly.

[BigBlueHat]

Other useful phrases/nouns related to this:

• subscriptions
• feeds
• content federation
• streams

[bridgespotter]

Thinking about Twitter and other social media. I seems a good idea to put a share button on H so that annotators and readers could share an annotation with Twitter and other social media. It would be a good incentive for potential annotators to annotate and would advertise H.

[dwhly]

I seems a good idea to put a share button on H so that annotators and readers could share an annotation with Twitter and other social media.

We have an issue for this here: https://github.com/hypothesis/h/issues/122

@RawKStar77 and I were just discussing this today.

[bridgespotter]

@dwhly Thnx. I'll check it out

[bridgespotter]

A question about the reply button. Traditional comments on websites are often swamped by abusive replies that clutter the comments. It might be useful to develop a function that allows annotators to enable or disable replies on an annotation.

[dwhly]

I've thought about this.

It might make sense on private, or "link only" (issue h/#424) annotations. In other words, if you're putting something in the public channel, I'm not sure you should be able to prevent replies. You can imagine that a counterpoint to reply spam is spam or trollng in the form of annotations where replies are prevented.

However, if you create an annotation that isn't public, but is visible in a "link only" mode-- because you're sharing it with your social circle, or somehow otherwise creating a separate anthology of annotations that you want to have control over-- then you probably should be able to control whether there are replies or not.

[bridgespotter]

The difference between annotation spam and reply spam is that annotation spam can be blocked whereas reply scam cannot. If the right to reply on an annotation is removed altogether or blocked as an option then people can always reply by writing their own annotations. Annotation spam can be blocked by:

• selecting to view annotations only from particular individuals or groups, or
• If you decide to implement it, by allowing users to block selected individuals from their stream. The right of reply to an annotation will still be visible on the "all annotations" stream for the page.

I think you could probably do away with the reply function altogether but at least it could be optional.

[tilgovi]

Replies are annotations so they're really more or less the same. Dealing with spam and abuse will take careful consideration around filtering, subscription, discovery, and notification.

I suspect it doesn't make sense to prevent the reply from happening, though it almost certainly makes sense not to show all replies to all users all the time.

[bridgespotter]

Gerben asked me to have a think about why users would use H. So I have put a document up for people to consider. I hope it is useful. Bridge https://drive.google.com/file/d/0ByOVyI5HPHGvYnRWbmplLVpsV2M/view?usp=sharing

[aron]

@bridgespotter thanks for putting this together I enjoyed reading it, theres some really good stuff in there and it's most definitely useful. I hope you don't mind I've converted (poorly) the document to html and thrown it up online with H embedded so that folks can comment on it*. I've left a couple of comments myself.

http://jsbin.com/hecule/quiet

I'm not sure this issue is the best place for the discussion, it would very much be worthwhile to post it in the Hypothesis forum where I'm sure many people would be interested in reading it.

• We don't support annotating the Google Docs preview yet.

EDIT: I updated the jsbin url I didn't realise the preview expires now if the bin is created anonamously.

[dwhly]

@bridgespotter I want to thank you as well, there's a tremendous number of insights in here. I'd also encourage you to post it to the forum. I'll read through more carefully later.

[bridgespotter]

@dwhly @aron Thanks Guys, I have posted it to the forum. I forgot it was there. Bridge