Don't limit sharing to users who just happen to be members of the same
service. Instead, accept subscriptions to feeds of shared links from
both local and off-site users. There are features of both RSS feeds and
the new JSON Activity Streams format that can help facilitate this.
For a hosted feed reader, the cool thing would be to allow "share"
subscriptions to both local users and "share" feeds from off-site. That
way, the sharing can be decentralized and even inclusive of competing
feed reader services.
Here's the quick sketch I posted over on the other list:
* Take a feed, call it a "source" feed (eg. from CNN, blogs, etc)
* Take someone's feed containing shared links, call it a "share" feed.
(eg. generated internally from local users, from a self-hosted feed
reader like Tiny Tiny RSS, from pinboard.in, etc)
* Allow subscriptions to both "source" and "share" feeds. Maybe
something in the "share" feed identifies it as such for auto-detection,
or maybe the subscription UI helps out.
* Whenever "share" feed items are found whose links match an item in a
"source" feed, those "share" feed items get collated and displayed as
comments on that "source" feed item. Think of it as a relational join:
Each "source" item gets joined on "share" items, if any.
--
l.m.o...@pobox.com
http://decafbad.com
{web,mad,computer} scientist
I'll probably get around to building at least a prototype of what I'm
thinking of. So, as long as sharebro.org spits out feeds of shared
items, it's still keen as far as I'm concerned.
> I don't think your distinction between source feeds and share feeds is
> useful except at a semantic level -- like how a person would categorize
> their own feed to other people, but not technically.
It's useful at a presentation level and has data model implications.
"Source" feed items are what would appear in the main list / river /
stream. They're the primary social objects.
"Share" feed items are what would appear as notes after source feed
items - ala old-school Google Reader. They're annotations on the primary
social objects.
In my scenario, the "share" feed items would rarely, if ever, appear in
the main reading stream. In fact, I'd say if you ran into a "share" item
without a corresponding "source" subscription, you'd go out and fetch
the "source" feed on the spot to get the corresponding item.
> E.g. most blogs
> these days contain links to and excerpts from other blogs and news
> sources, and that doesn't make them any less or more sources in and of
> themselves.
Sure, but some feeds are specifically for sharing. Like my pinboard.in
feeds, or the old-school Google Reader shared items, or maybe whatever
feeds sharebro.org produces.
These can be treated differently than "source" feeds and marked as
"share" feeds in subscriptions, and so presented differently.
Alternatively, where the <source> element appears in any RSS feed, you
could find the corresponding source item and do the display-as-note join
there. That would work for mixed purpose feeds - ie. blogs with both
original content and shares.
>> * Whenever "share" feed items are found whose links match an item in a
>> "source" feed, those "share" feed items get collated and displayed as
>> comments on that "source" feed item. Think of it as a relational join:
>> Each "source" item gets joined on "share" items, if any.
>
> Now that's an interesting idea. But again, it could apply to any feed.
That's the main idea. It could apply to any feed, especially given the
<source> element. But, indicating that some feeds are primarily meant
for sharing can help make implementation easier.
> By the way, I think you just described "trackbacks" which have been
> around in several incarnations for years.
It's a lot like "trackbacks". The key difference, though, is that
"trackbacks" go back to the original site. The relation between "source"
and "share" items gets joined at any reader's end - that's the
distributed part.
--
m...@lmorchard.com
http://decafbad.com
{web,mad,computer} scientist
On 11/7/11 10:03 PM, Emmanuel Pire wrote:
> I understand more the "source" and "share" feeds concept now.
> How do comments integrate in that ?
The items in share feeds are the comments or notes on source feed items.
So, you might have something like:
* Source feed
* http://rss.cnn.com/rss/cnn_topstories.rss
* Share feeds
* http://feeds.pinboard.in/rss/u:deusx/
* http://static.reallysimple.org/users/dave/linkblog.xml
* http://sharebro.org/users/example_user/rss
Now, say the CNN feed publishes up a headline like:
"Life found on Mars!"
Then, the users behind the share feeds post the URL to the CNN article
with notes:
pinboard.in - "Finally!"
reallysimple.org - "I'm still a skeptic."
sharebro.org - "I'm not surprised"
In a feed reader with distributed sharing, say newsblur.com for example,
you'd see something like:
* CNN.com: "Life found on Mars!"
* deusx: "Finally!"
* dave: "I'm still a skeptic."
* example_user: "I'm not surprised"
News and notes, distributed between 5 different sites.
> As I saw it first, it was: source feed provides items with a unique id,
> as specified in RSS standards. Share service then aggregate comments in
> some way, all linked to a unique item from a source feed, and provide it
> to reader clients. In my first definition, source feeds are also public
> feeds (provided by sharebro.org <http://sharebro.org> or any RSS supplier).
>
> My 2 cents.
Well, in what I'm thinking, the share service just publishes the feed
for individual users' shared items. A feed reader can aggregate notes
from share feeds.
But, a single site could be both a sharing service (as output) and a
feed reader (as input).
For what it's worth, I don't want to totally flood the list with this
idea. So, this'll be my last post on it for awhile :) I'll just take my
show over to decafbad.com when or if I start actually hacking.
Cool. I know I can ramble on about an idea when I get enthusiastic. That
gets annoying if it turns out to be a cruddy idea. :)
> Your idea is very interesting but I'm not sure it's anthropologically
> valid, i.e. corresponds to the way people do use or want to use existing
> tech. For instance, many "notes" are miles long and contain links in
> themselves, often several links, and to different sources.
Yeah, that's true. I think this is mostly suited to feeds with quick
one-liner or at least < 3 paragraph responses. But, that's more cultural
than technological.
Someone could totally share content longer than the original source item
if they wanted to, and it would be up to the feed reader UI to decide
how to display it. (eg. like Google+ truncates and offers "more" links
to reveal)
> Slightly off topic, the difference between "comment" and "note" in
> Reader has always seemed artificial to me. Like, ok, maybe it makes
> sense to put the first comment on top, but not really; the privilege of
> being the one who shared this thing this time should be enough for you
> to be FIRST!!! without reifying Note over Comment.
I think in the scheme I described, the main difference is you really
only get one note per item per person.
It doesn't really lend itself to threaded comments with replies. I mean,
you could probably get that by repeatedly sharing the same item to
indicate subsequent replies over time - but that just seems annoying.
Otherwise, we'd probably be talking about an extension to RSS to
indicate additional comments in the same share. Though, having said
that, I'm pretty sure I was on some mailing list threads back around
2002 or so talking about that exact thing :)
Slightly off topic, the difference between "comment" and "note" in Reader has always seemed artificial to me. Like, ok, maybe it makes sense to put the first comment on top, but not really; the privilege of being the one who shared this thing this time should be enough for you to be FIRST!!! without reifying Note over Comment.
So in this hypotehtical world there could be feed readers, and comment
aggrigators. The comment aggregators could just consume activity
streams.
So you and all your friends would be on a given comment aggregator,
and people could use whatever feed reader they wanted.
On Wed, Nov 16, 2011 at 3:03 PM, Saliency <sali...@gmail.com> wrote:
> agree.
>
> --
> The Sharebro Google Group: for http://sharebro.org and related development
> http://groups.google.com/group/sharebro for archives and options
>
--
The Sharebro Google Group: for http://sharebro.org and related development
http://groups.google.com/group/sharebro for archives and options
I think not. I want the old Reader back! In the old Google Reader a
separate comment *thread* was made for each item+sharer dyad.
I think you just described Notes, not Comments. Comments are a
conversation. Notes are all from a single person.
Or... if others could post their comments to "my" comment feed then
the system you described would be a complete mess, mixing comments
from different people on different items into a single "thread" (more
like a ball of yarn, since you couldn't tell who was replying to
what), but *not* including comments made by the same people on items
shared by other people...
And how, in an RSS Reader, would you subscribe to one of these comment threads?
Slipping into sharbro dev mode now... I'm learning a lot about the
Google Reader API. Most of it is not going away. I believe that *if*
there were a way to add a comment from inside Reader, I could create a
new feed and then subscribe users to it and put that feed in each
user's subscriptions list. But where would I put it? In a new folder
called "Comments" (or "Comment View") that's far beneath the "Shares"
(or "People you follow") folder, and thus far removed from the actual
item that has the comments on it?
Also each subscription would need a good title... would the title
include the full name of the original item? e.g.
Comments on "Why Strawberries Are Objectively Superior To
Raspberries, Part 3" from 'Berry Blog'
Problems like these are why I've been punting on comments for now. I
think the only solution will end up being a browser plugin/userscript
so that each dyad feed can be spliced in beneath the text of the item
in Reader. And I think, like Alex K, that the server-side data format
of comments will look more like an Activity Stream and less like RSS.
Server-side I think we're making good brainstorming progress.
Client-side we've still barely restored People You Follow (1000+), let
alone put comments back in.
- A
"I think not. I want the old Reader back! In the old Google Reader a
separate comment *thread* was made for each item+sharer dyad.
I think you just described Notes, not Comments. Comments are a
conversation. Notes are all from a single person."
Nope inside of the RSS reader it is conversation. The RSS reader does need to do the work of assembling the conversation. This is why you need to subscribe to your friends comment feeds.
...without a lot of smarts built in to the feed reader. Which is fine
if you're building a reader but we're not doing that... yet. Though
Francis is -- see http://yfrog.com/h2aziip -- but I'd like to try to
make something that works inside Google Reader.
And ideally through many reader apps if they want to use our API
instead of their own database. (And speaking as a developer of apps
that is a tough sell.)
The user base of Google Reader is going to be (1000+) times more than
of any 3rd party feed reader, especially since I believe Peak RSS may
have happened around 2008 or so.
> or RSS feed only comments.
...especially since RSS 2.0 is still kind of behind the times in terms
of source and identity metadata. Atom may be better. JAS definitely
is.
When you're writting a feed aggregator, you need to write three different layers :
Layer 1 : The layer that parse feeds. It's not the easiest job. "But, it's just xml, it should be easy". It's not. It's just xml. It's just 10 differents and incompatible xml formats (9 RSS formats according to Mark Pilgrim and 1 Atom format). You also perhaps need to understand all non standard feeds that mix some features from differents standards.
Layer 2 : The database layer. Once you've parsed your feed, you need to store it in a database, and and interesting things like "items read", etc.
Layer 3 : The user interface.