As I was stuck in a traffic jam the other day (yeah. interesting place to think about MediaWiki stuff :P), an idea for adding RSS/Atom feed support for watchlists (as requested on Bug 471) came to me. I have no clue how feasible it is, so I'm just throwing the suggestion to gather comments. :)
Currently, the method the bug fixes use is to create a login cookie or something similar for the RSS feed, which then faces authentication issues. However, I thought it would be easier to provide a *previously-authenticated* session token, which then is just plugged into any feed aggregator (a la Google Calendar, to point to a similar implementation).
The way it would be done is like this:
1) Our unhappy user wants to have a create a feed for his watchlist.
2) The user clicks on [[Special:Watchlist/feed]] (or another URL), which then generates a random 128-character string. This URL is stored somewhere in the database; perhaps as a user_feed_token field in the user table.
3) [[Special:Watchlist/feed]] returns the string, and gives the unhappy user a link, of the following format: http://en.wikipedia.org/w/index.php?title=Special:Watchlist&target=%7B%7... }&token={{token}}
4) The unhappy user adds the link to his aggregator.
5) The aggregator displays the watchlist.
6) The unhappy user becomes happy.
Watchlist data is obviously private; as a result, the token should be able to be reset by the user if necessary, and only one token should be active at any time, like it is done with email confirmation tokens. Also, the strength of the token should be at least 128 characters, but it can be more if necessary. I'm not sure whether to use the username or the user ID of our happy/unhappy user; I thought the ID number would be more cryptic, but that's minor. If the token is wrong, then the request fails gracefully; no "wrong token error" is required.
Anyways, what do you all think? Comments? Flamebait?
Titoxd.
On 3/11/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
Anyways, what do you all think? Comments? Flamebait?
Titoxd.
I love the idea. I would definitely use the feed. --Mets501
On 3/12/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
Anyways, what do you all think? Comments? Flamebait?
Why restrict it to watchlists? Perhaps we could do some kind of group thing by allowing public RSS feeds of interesting groups of articles. Allow people to kill off changes from the RSS feed by "approving" them.
<dream> Imagine a sort of "watchlist ticker" that scrolls across the bottom of your screen while you're working, showing the actual changes that people are making to articles you care about. Every now and then you see the word "penis" scroll past. You click the little red X, sigh contentedly, and keep working. </dream>
Steve
Why restrict it to watchlists? Perhaps we could do some kind of group thing by allowing public RSS feeds of interesting groups of articles. Allow people to kill off changes from the RSS feed by "approving" them.
Could Categories be used for this? So you 'watch' the Category, and vicariously are also set up to watch all articles in that category.
-- Jim R. Wilson (jimbojw)
On 3/11/07, Steve Bennett stevagewp@gmail.com wrote:
On 3/12/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
Anyways, what do you all think? Comments? Flamebait?
Why restrict it to watchlists? Perhaps we could do some kind of group thing by allowing public RSS feeds of interesting groups of articles. Allow people to kill off changes from the RSS feed by "approving" them.
<dream> Imagine a sort of "watchlist ticker" that scrolls across the bottom of your screen while you're working, showing the actual changes that people are making to articles you care about. Every now and then you see the word "penis" scroll past. You click the little red X, sigh contentedly, and keep working. </dream>
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 3/12/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Could Categories be used for this? So you 'watch' the Category, and vicariously are also set up to watch all articles in that category.
Well that would be less flexible than what I suggested. But probably a lot easier to implement :)
Steve
One thing at a time, folks... otherwise we don't get anything. ;)
-----Original Message----- From: Steve Bennett [mailto:stevagewp@gmail.com] Sent: Sunday, March 11, 2007 10:56 PM To: Wikimedia developers Subject: Re: [Wikitech-l] RSS feeds for watchlists
On 3/12/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Could Categories be used for this? So you 'watch' the Category, and vicariously are also set up to watch all articles in that category.
Well that would be less flexible than what I suggested. But probably a lot easier to implement :)
Steve
One thing at a time, folks... otherwise we don't get anything. ;)
What are you talking about? Just grab a text-editor and start hacking! :)
But seriously folks, this entire suggestion can be implemented as an extension - there's no need to get approval to start development.
(And hey, if it's popular, the powers-that-be may decide to pull it into WP).
-- Jim
On 3/12/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
One thing at a time, folks... otherwise we don't get anything. ;)
-----Original Message----- From: Steve Bennett [mailto:stevagewp@gmail.com] Sent: Sunday, March 11, 2007 10:56 PM To: Wikimedia developers Subject: Re: [Wikitech-l] RSS feeds for watchlists
On 3/12/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Could Categories be used for this? So you 'watch' the Category, and vicariously are also set up to watch all articles in that category.
Well that would be less flexible than what I suggested. But probably a lot easier to implement :)
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 12/03/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Why restrict it to watchlists? Perhaps we could do some kind of group thing by allowing public RSS feeds of interesting groups of articles. Allow people to kill off changes from the RSS feed by "approving" them.
Could Categories be used for this? So you 'watch' the Category, and vicariously are also set up to watch all articles in that category.
Watch "related changes" for the category rather than "recent changes".
(If this can be gotten down to history on a single article, it would be an elegant way to make an RSS feed for the Wikipedia Signpost - just take a feed from that page.)
- d.
This feature is implemented in the WikiFeeds extension.
http://opensource.case.edu/trac_projects/MediaWikiHacks/changeset/131
Source at http://opensource.case.edu/svn/MediaWikiHacks/extensions/WikiFeeds/trunk/Spe...
If private feeds are enabled (not default behavior), the first time you go to Special:WikiFeeds, a token is generated. There is still no way to regenerate the token, but that is simple enough to implement, if enough people ask.
Enjoy.
Gregory Szorc gregory.szorc@gmail.com
On 3/11/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
As I was stuck in a traffic jam the other day (yeah. interesting place to think about MediaWiki stuff :P), an idea for adding RSS/Atom feed support for watchlists (as requested on Bug 471) came to me. I have no clue how feasible it is, so I'm just throwing the suggestion to gather comments. :)
Currently, the method the bug fixes use is to create a login cookie or something similar for the RSS feed, which then faces authentication issues. However, I thought it would be easier to provide a *previously-authenticated* session token, which then is just plugged into any feed aggregator (a la Google Calendar, to point to a similar implementation).
The way it would be done is like this:
Our unhappy user wants to have a create a feed for his watchlist.
The user clicks on [[Special:Watchlist/feed]] (or another URL), which
then generates a random 128-character string. This URL is stored somewhere in the database; perhaps as a user_feed_token field in the user table.
- [[Special:Watchlist/feed]] returns the string, and gives the unhappy
user a link, of the following format:
http://en.wikipedia.org/w/index.php?title=Special:Watchlist&target=%7B%7... }&token={{token}}
The unhappy user adds the link to his aggregator.
The aggregator displays the watchlist.
The unhappy user becomes happy.
Watchlist data is obviously private; as a result, the token should be able to be reset by the user if necessary, and only one token should be active at any time, like it is done with email confirmation tokens. Also, the strength of the token should be at least 128 characters, but it can be more if necessary. I'm not sure whether to use the username or the user ID of our happy/unhappy user; I thought the ID number would be more cryptic, but that's minor. If the token is wrong, then the request fails gracefully; no "wrong token error" is required.
Anyways, what do you all think? Comments? Flamebait?
Titoxd.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 12/03/07, Gregory Szorc gregory.szorc@gmail.com wrote:
[RSS feeds]
This feature is implemented in the WikiFeeds extension. http://opensource.case.edu/trac_projects/MediaWikiHacks/changeset/131 Source at http://opensource.case.edu/svn/MediaWikiHacks/extensions/WikiFeeds/trunk/Spe... If private feeds are enabled (not default behavior), the first time you go to Special:WikiFeeds, a token is generated. There is still no way to regenerate the token, but that is simple enough to implement, if enough people ask.
Brion, Tim: does this have >0 chance of getting into the Wikimedia wikis?
- d.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Gerard wrote:
On 12/03/07, Gregory Szorc wrote:
[RSS feeds]
This feature is implemented in the WikiFeeds extension. http://opensource.case.edu/trac_projects/MediaWikiHacks/changeset/131 Source at http://opensource.case.edu/svn/MediaWikiHacks/extensions/WikiFeeds/trunk/Spe... If private feeds are enabled (not default behavior), the first time you go to Special:WikiFeeds, a token is generated. There is still no way to regenerate the token, but that is simple enough to implement, if enough people ask.
Brion, Tim: does this have >0 chance of getting into the Wikimedia wikis?
Maybe, maybe not; no one's tried to 'sell' it and I haven't looked at it to see how much it tries to do and whether there's any problems.
(In general we prefer small extensions over big ones; single-purpose, trim and fit is better than do-fifty-things. That's part of why things like DPL2 are not getting any attention paid to them.)
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
On 3/12/07, Brion Vibber brion@pobox.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Gerard wrote:
On 12/03/07, Gregory Szorc wrote:
[RSS feeds]
This feature is implemented in the WikiFeeds extension. http://opensource.case.edu/trac_projects/MediaWikiHacks/changeset/131 Source at
http://opensource.case.edu/svn/MediaWikiHacks/extensions/WikiFeeds/trunk/Spe...
If private feeds are enabled (not default behavior), the first time you
go
to Special:WikiFeeds, a token is generated. There is still no way to regenerate the token, but that is simple enough to implement, if enough people ask.
Brion, Tim: does this have >0 chance of getting into the Wikimedia
wikis?
Maybe, maybe not; no one's tried to 'sell' it and I haven't looked at it to see how much it tries to do and whether there's any problems.
(In general we prefer small extensions over big ones; single-purpose, trim and fit is better than do-fifty-things. That's part of why things like DPL2 are not getting any attention paid to them.)
If you want to look at it, I have no problem uploading it to the official SVN and modifying the license to comply with whatever is required.
Be warned, the extension is a little on the heavy side. Some people have complained that it requires a bit of CPU. This is most likely due to the SQL queries that are used. There is probably some room for improvement. I get around the issue by caching feeds on the FS. Wikimedia would probably prefer a memcached or APC-like solution for performance reasons, but this is pretty simple to swap out.
Greg
Hi!
Brion, Tim: does this have >0 chance of getting into the Wikimedia wikis?
Nobody asked me, but I'll still intervene with my defeatist denials.
The main problem here is that RSS immediately changes access patterns, so people instead of clicking 'watchlist' when they need it, would do that periodically. Though we could try increasing indexing efficiency for the task (and we already run a dedicated database server for it), RSS refreshes would be pain to handle, and may require serious data rearchitecting.
So, the question is, do we really need it? ;-) (I know I'll be scolded for this evil attitude, but by limiting watchlist usage in some ways we actually removed huge bottlenecks in past).
I for one really welcome any external service, using IRC feeds and putting them into 'my personal watchlist rss' service.
BR,
On 3/13/07, Brion Vibber brion@pobox.com wrote:
(In general we prefer small extensions over big ones; single-purpose, trim and fit is better than do-fifty-things. That's part of why things like DPL2 are not getting any attention paid to them.)
In that spirit, how about adding the feed functionality from Recentchanges into Recentchangeslinked? Users could maintain a page in their userspace with a list of links to pages they want to watch. This would effectively allow watchlist feeds, with the proviso that it would be public, not private.
I'm not entirely familiar with the feed code for RC, but I suspect this would not be too difficult?
On 12/03/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
Anyways, what do you all think? Comments? Flamebait?
What's the problem with using the existing token mechanism, salted with a particular value, e.g. for watchlists? The salting code is there and it's all available.
Watchlist data isn't "private" in the sense that we need to protect it at all costs; if it *does* leak out, no-one's going to care that much...you're not really gaining access to anything hideously confidential, are you?
Rob Church
On 3/12/07, Rob Church robchur@gmail.com wrote:
On 12/03/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
Anyways, what do you all think? Comments? Flamebait?
What's the problem with using the existing token mechanism, salted with a particular value, e.g. for watchlists? The salting code is there and it's all available.
Watchlist data isn't "private" in the sense that we need to protect it at all costs; if it *does* leak out, no-one's going to care that much...you're not really gaining access to anything hideously confidential, are you?
I thought the same thing, which is why I never implemented private watchlist feeds in WikiFeeds until last night. Since people kept requesting it and because it was only a 10 minute patch, I decided to go ahead and do it. The default behavior is still public feeds, however.
Greg
The only problem, AFAIK, is that someone on #mediawiki said that our current token generation mechanism (User::generateToken( )) is teh crap, and suggested a better way. Otherwise, my original idea was to use the existing token mechanism, like email confirmations use.
It isn't private as user.user_realname should be; however, it still can be kept reasonably private by having a mechanism to generate a new token, even if an existing one already exists.
-----Original Message----- From: Rob Church [mailto:robchur@gmail.com] Sent: Monday, March 12, 2007 6:16 AM To: Wikimedia developers Subject: Re: [Wikitech-l] RSS feeds for watchlists
On 12/03/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
Anyways, what do you all think? Comments? Flamebait?
What's the problem with using the existing token mechanism, salted with a particular value, e.g. for watchlists? The salting code is there and it's all available.
Watchlist data isn't "private" in the sense that we need to protect it at all costs; if it *does* leak out, no-one's going to care that much...you're not really gaining access to anything hideously confidential, are you?
Rob Church
The token need not be globally unique. It just needs to be sufficiently random, since the token will accompany the username in the URL. Arguably, this is less secure than a globally unique token, but even Google's "private" feeds have the username in the URL. A sufficient "random" token can be generated by performing an MD5 against of the current time and the user id, which I have done with WikiFeeds.
Greg
On 3/12/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
The only problem, AFAIK, is that someone on #mediawiki said that our current token generation mechanism (User::generateToken( )) is teh crap, and suggested a better way. Otherwise, my original idea was to use the existing token mechanism, like email confirmations use.
It isn't private as user.user_realname should be; however, it still can be kept reasonably private by having a mechanism to generate a new token, even if an existing one already exists.
-----Original Message----- From: Rob Church [mailto:robchur@gmail.com] Sent: Monday, March 12, 2007 6:16 AM To: Wikimedia developers Subject: Re: [Wikitech-l] RSS feeds for watchlists
On 12/03/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
Anyways, what do you all think? Comments? Flamebait?
What's the problem with using the existing token mechanism, salted with a particular value, e.g. for watchlists? The salting code is there and it's all available.
Watchlist data isn't "private" in the sense that we need to protect it at all costs; if it *does* leak out, no-one's going to care that much...you're not really gaining access to anything hideously confidential, are you?
Rob Church
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Mar 12, 2007 at 01:15:54PM +0000, Rob Church wrote:
Watchlist data isn't "private" in the sense that we need to protect it at all costs; if it *does* leak out, no-one's going to care that much...you're not really gaining access to anything hideously confidential, are you?
Well, if you're the Wikipedia editor who is in the closet but has a watchlist that's disproportionately loaded with with MOTSS'y pages, then yeah, you might care.
Cheers, -- jr 'sorry, g{ua}ys; that's just the canonical example' a
Am I totally missing something, or are we talking about this? http://meta.wikimedia.org/w/api.php?action=feedwatchlist
Bryan
On 3/14/07, Jay R. Ashworth jra@baylink.com wrote:
On Mon, Mar 12, 2007 at 01:15:54PM +0000, Rob Church wrote:
Watchlist data isn't "private" in the sense that we need to protect it at all costs; if it *does* leak out, no-one's going to care that much...you're not really gaining access to anything hideously confidential, are you?
Well, if you're the Wikipedia editor who is in the closet but has a watchlist that's disproportionately loaded with with MOTSS'y pages, then yeah, you might care.
Cheers,
-- jr 'sorry, g{ua}ys; that's just the canonical example' a
Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 3/14/07, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
Am I totally missing something, or are we talking about this? http://meta.wikimedia.org/w/api.php?action=feedwatchlist
The problem with the API feeds is that they require a cookie or a non-constant token to access. It would be nice to be able to import these feeds into 3rd party feed aggregators. This currently cannot be done, as credentials have to be supplied with each request.
As far as implementing watchlist feeds on Wikipedia goes, the easy solution is to implement a "private" token as part of the API watchlist feed. This makes much more sense than deploying my WikiFeeds extension for simply watchlist feeds. If you want all the extra feed types WikiFeeds provides (per-category, per-user, etc), then it is a different story.
Greg
wikitech-l@lists.wikimedia.org