Difference between revisions of "Cross-site authenticated RSS"
From Dreamwidth Notes
(New page: Category: Brainstorming 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...) |
(now with added line breaks) |
||
Line 5: | Line 5: | ||
I dump in an email I wrote in order to kick off the conversation: | I dump in an email I wrote in order to kick off the conversation: | ||
− | <pre>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. | + | <pre>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. | + | 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. | + | 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". | + | 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.</pre> | + | 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.</pre> | ||
--[[User:Rahaeli|Rahaeli]] 10:27, 30 January 2009 (UTC) | --[[User:Rahaeli|Rahaeli]] 10:27, 30 January 2009 (UTC) |
Revision as of 10:29, 30 January 2009
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)