Cross-site authenticated RSS

Or: How we can make it so that people can read friends-only entries on other sites from their DW reading page.

I dump in an email I wrote in order to kick off the conversation:

Syndicated feeds are treated like any other account -- each item in the feed
is given its own entryID in the syndicated account, and that behaves just like
any other entry (in terms of building the friends page, etc). Now, there's a
mechanism in RSS to authenticate to the server providing the feed, and LJ
treats that authenticated RSS like they would if you were logged in; if you'd
see the entry on someone else's journal, you'll see it in their RSS feed while
you're using RSS authentication.

The easy-but-evil solution would be for us to use someone's authentication
credits to pull down the RSS feed of a journal, store all the FO entries
locally, and then every time someone who had that feed friended reloaded their
FP, check against the feedowner's friends list on LJ to see if the local
viewer was permitted to see that entry. That's the evil way to do it. We
aren't going to do that.

Now, the idea that I'm currently fronting to solve the problem is instead to
create a new type of account -- call it an aggregation account or whatever.
Users can then give us the list of people who have them friended on LJ (or
wherever, assume that I mean any LJ-based site when I say LJ, it's easier) and
also give us their login credentials for LJ, or give us their LJ OpenID or
whatever, any way that we can get the authentication done, I'm not a coder,
blah blah. The aggregation account would then poll those RSS feeds at a MUCH
slower rate than for the regular RSS feed (to prevent LJ from banning us for
hitting them too often -- because with a regular syndication account for just
the public entries, you only have to check once; to check for FO entries, you
have to check with every single person's separate credentials to see if they
have entries they can see) and see if there are any FO entries that they can
see.

If there is a new entry, and it's FO/filtered, and the person whose login
credentials are being supplied can see it, we insert an item into the
aggregation account that says "your friend $friendname posted a friends-locked
entry that you can see. Its URL is: $url".

The aggregation account will then insert that item into the actual reading
list, so that notification will appear on your DW readlist -- not the
*content* of the entry, but the fact that someone *posted* it, along with a
link. Sure, there's a chance the poster will have re-filtered the entry by the
time the person gets to it, especially since we'd *have* to make the
polling-for-FO-entries a very slow thing (probably only once every 12 or 24
hours), but we could still introduce the fact that there *was* an entry into
your reading list. You could then go click the link and open up the entry in
another tab, another window, etc.

--Rahaeli 10:27, 30 January 2009 (UTC)

Alternate Presentation

This presentation seems clunky to me (or rather, I personally detest URL only RSS feeds.) I wonder if we could gracefully reference the desired text (possibly in ?format=light) in an iframe. I know iframes aren't usable with screen readers and the like, but in the case where the browser doesn't support frames, doesn't the standard have a NOFRAME where we could put just the "your friend $friendname posted a friends-locked entry that you can see. Its URL is: $url" line. This would have to be aware of all lj-clone sights so we would know to append ?format=light to some URLs and not others. --Zvi-likes-tv 14:32, 2 February 2009 (UTC)

Persistent Login

My base assumption is that only Bad Guys want me to give them my password to another account. I am just sayin'. --Zvi-likes-tv 14:32, 2 February 2009 (UTC)

Make it DW-only and customizable

It seems to me that we'd be better off designing this so that different DW-based sites can read friends-only locked posts from one another on the friends page, and then provide an API that other sites (LJ) could use if they wanted to support it. That way we can make it work right, instead of trying to hack around an implemenation that isn't designed to do what we want it to do.

For instance, you could get a reasonably elegant solution if you just extended OpenID and RSS a little bit. If you extend OpenID so that you could send a request authenticated as multiple users (I assume you can't do that now), then a DW server could connect to a feed and authenticate as all of the local users who watch that feed. Then, you could use an extended RSS namespace (which is already supported in RSS 2.0) to add in a list of the authenticated users who could access each of the entries, or show them as pubic if anyone can read them. Then you store the privacy settings for each entry in the feed, and only show locked entries to the appropriate users.

There's already a preference setting saying how to format your RSS feed (title only, summary, full post), so it wouldn't be that bad to extend it to have a separate setting for locked posts. That way if a user is ok with sharing their full posts with the remote servers, they can, and if not, they can just send a link.

The RSS namespace extension would be easy. Storing the allow list for locked feed entries shouldn't be _too_ bad. Extending OpenID might be a bit trickier... --Allen 22:18, 3 February 2009 (UTC)