Hi,
I have two common requests from users of MediaWiki at my site:
1. Being able to communicate via instant messenger *through the site*, where the chat gets recorded in the related article's Talk page.
2. Being able to edit articles by email, where the entire article gets emailed back and forth, and emailed changes to the article get saved as new versions.
I can imagine a technical solution for (1) being an integration of an instant messenger server with MediaWiki which would save the IM conversation to the relevant Talk page; and for (2) a mailing list integrated with MediaWiki that would extract and clean up the article from the mail (removing any indents) and save it as a new version.
My question: has anyone implemented anything like this before?
Robert.
There was some dialog recently regarding the latter, email option - with various proposals and quite a few detractors. I haven't heard anyone request IM integration.
I don't like either of the two proposed options. The following is my personal feeling regarding these requests (and does not necessarily reflect that of the community or anyone else).
There are two basic forms of internet communication: Send-Receive and Publish-Subscribe. Instant Messaging, Chat Rooms and Email belong to the former, while Wikis, Forums and Blogs belong to the latter.
Conversion between these two models is possible, and sometimes makes sense. For example, a subscriber to a wiki or blog might be sent an email when a change has occurred. Using a Send-Receive mechanism as an implementation of a subscriber tends to work out pretty well.
Going the other way, that is, using a Send-Receive mechanism to implement the Publish in Publish-Subscribe, makes less sense. There are different barriers to using IM vs Email as Wiki publication methods, which I outline below:
1) Instant Messaging is a communication method which occurs between two (or more) entities in more-or-less real time with no particular categorical or topical imperatives. There is an expectation that the conversation which occurs over IM is intended only for the participating audience, and not for general publication. Tying directly to a wiki page (talk or otherwise) violates this expectation, except in the case where all parties are knowingly using the integrated wiki chat. But if everyone's already using the wiki, why not just edit the talk page?
2) Email, like IM, carries an expectation of confidentiality with the recipients - though to a lesser degree since forwarding is common practice. Email carries another debilitating feature - that the author of any particular message is trivial to forge. Thus integrating an email conversation into a wiki page raises questions of content legitimacy.
Finally, in both the IM and Email cases, race-conditions become a serious issue. How do you determine which publishing entity (IM, Email client, or wiki user) got there first? Using a standard interface (the wiki) alleviates this problem.
That said, there are ways to automatically publish the contents of Email conversations as static web-pages. For example, all messages posted to this list ultimately winds up on Gossamer Threads:
http://www.gossamer-threads.com/lists/wiki/wikitech/
Using a mailing-list-to-webpage facility may help with the Email option, though admittedly this is not what you've asked for.
-- Jim R. Wilson (jimbojw)
On 2/19/07, Dr. Robert P. Biuk-Aghai robertb@umac.mo wrote:
Hi,
I have two common requests from users of MediaWiki at my site:
- Being able to communicate via instant messenger *through the site*,
where the chat gets recorded in the related article's Talk page.
- Being able to edit articles by email, where the entire article gets
emailed back and forth, and emailed changes to the article get saved as new versions.
I can imagine a technical solution for (1) being an integration of an instant messenger server with MediaWiki which would save the IM conversation to the relevant Talk page; and for (2) a mailing list integrated with MediaWiki that would extract and clean up the article from the mail (removing any indents) and save it as a new version.
My question: has anyone implemented anything like this before?
Robert.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 2/19/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Finally, in both the IM and Email cases, race-conditions become a serious issue. How do you determine which publishing entity (IM, Email client, or wiki user) got there first? Using a standard interface (the wiki) alleviates this problem.
Can you elaborate on this? Presumably at the server end there are IM, email and web interfaces to the wiki database. How is the question of an IM and an email "update" command arriving simultaneously any different from that of two web POST commands arriving simultaneously?
I would love it if there was an email-to-wikipedia interface, mainly because my mobile phone gives me unlimited email for free (whereas web browsing is ridicously expensive - go figure). There do appear to be a lot of fairly significant hurdles though: authentication, parsing email (stripping out signatures, demangling character conversions, avoiding accidental changing of whitespace etc), and of course the potential for significant lag between receive and update - is merging really a safe option when the article may have been downloaded 6 hours earlier?
Incidentally, is there by any chance a read-only email fetch mechanism for Wikipedia?
Steve
Can you elaborate on this? Presumably at the server end there are IM, email and web interfaces to the wiki database. How is the question of an IM and an email "update" command arriving simultaneously any different from that of two web POST commands arriving simultaneously?
In retrospect, my phrasing may have made it seem like a bigger issue then there really is, but here is my understanding of the problem:
When a POST submission arrives, it's tagged with information regarding when the originating form was generated. I'm not sure where all this information is stored. It may be session or hidden form vars - I can't be sure without digging. In any case, the server then checks to make sure that the article hasn't changed since the time the form was created and alerts the user if this is the case with as "Page has been changed" message.
In the case of IM or Email, there is no "originating form" - so resolving which submission came from which previous version becomes an implementation detail. In the case of Email, I suppose you could put in the email a hashcode of some kind to establish a "session" of sorts - then remember to which article and which revision that hashcode corresponds. (I'm just thinking aloud here - I'm sure others here have more info on how this could be done).
Because of the very asynchronous behavior of SMTP/POP/IMAP, chances of this kind of collision are much more likely then with the wiki's web interface. The resolution is to send more emails explaining the condition and providing a resend request - or direct the colliders to the web interface.
Anyway, that's just my understanding of the problem - I reserve the right to be wrong on all points :)
Incidentally, is there by any chance a read-only email fetch mechanism for Wikipedia?
I don't know, but there used to be Email-a-Webpage services whereby you could Email a URL as the subject line to some entity and get a response which was the requested page. I'm having trouble locating one now though ... Googling for "webpage by email" doesn't produce anything useful :(
On 2/19/07, Steve Bennett stevagewp@gmail.com wrote:
On 2/19/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Finally, in both the IM and Email cases, race-conditions become a
serious
issue. How do you determine which publishing entity (IM, Email client,
or
wiki user) got there first? Using a standard interface (the wiki) alleviates this problem.
Can you elaborate on this? Presumably at the server end there are IM, email and web interfaces to the wiki database. How is the question of an IM and an email "update" command arriving simultaneously any different from that of two web POST commands arriving simultaneously?
I would love it if there was an email-to-wikipedia interface, mainly because my mobile phone gives me unlimited email for free (whereas web browsing is ridicously expensive - go figure). There do appear to be a lot of fairly significant hurdles though: authentication, parsing email (stripping out signatures, demangling character conversions, avoiding accidental changing of whitespace etc), and of course the potential for significant lag between receive and update - is merging really a safe option when the article may have been downloaded 6 hours earlier?
Incidentally, is there by any chance a read-only email fetch mechanism for Wikipedia?
Steve
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 2/20/07, Jim Wilson wilson.jim.r@gmail.com wrote:
When a POST submission arrives, it's tagged with information regarding when the originating form was generated. I'm not sure where all this information is stored. It may be session or hidden form vars - I can't be sure without digging. In any case, the server then checks to make sure that the article hasn't changed since the time the form was created and alerts the user if this is the case with as "Page has been changed" message.
I don't think that's the case. As I understood it, MediaWiki just checks to see if the content that's changing has been changed. The following sequence of events is acceptable:
User A starts modifying article User B starts modifying article User B submits changes which only affect section 1 User A submits changes which only affect section 5
No warning messages of any kind are given.
Because of the very asynchronous behavior of SMTP/POP/IMAP, chances of this kind of collision are much more likely then with the wiki's web interface. The resolution is to send more emails explaining the condition and providing a resend request - or direct the colliders to the web interface.
Well, much like the current edit conflict resolution.
I don't know, but there used to be Email-a-Webpage services whereby you could Email a URL as the subject line to some entity and get a response which was the requested page. I'm having trouble locating one now though ... Googling for "webpage by email" doesn't produce anything useful :(
Bugger, thanks for looking though :)
Steve
On 2/20/07, Jim Wilson wilson.jim.r@gmail.com wrote:
... I don't know, but there used to be Email-a-Webpage services whereby you could Email a URL as the subject line to some entity and get a response which was the requested page. I'm having trouble locating one now though ... Googling for "webpage by email" doesn't produce anything useful :(
Google for "web-to-email", or take a look at this list:
http://www.oscar.org.uk/about/webtoemail.htm
A lot of those are no longer in operation, but I know that web@pagegetter.com works well.
-- John
On 2/20/07, Steve Bennett stevagewp@gmail.com wrote:
I don't think that's the case. As I understood it, MediaWiki just checks to see if the content that's changing has been changed. The following sequence of events is acceptable:
You're probably right - I haven't dug through EditPage in a long time. :(
On 2/19/07, John Vandenberg jayvdb@gmail.com wrote:
Google for "web-to-email", or take a look at this list:
http://www.oscar.org.uk/about/webtoemail.htm
A lot of those are no longer in operation, but I know that web@pagegetter.com works well.
Thanks for looking this up, John - I couldn't remember what it was called. Good to know.
-- Jim
Steve Bennett wrote:
I would love it if there was an email-to-wikipedia interface, mainly because my mobile phone gives me unlimited email for free (whereas web browsing is ridicously expensive - go figure). There do appear to be a lot of fairly significant hurdles though: authentication, parsing email (stripping out signatures, demangling character conversions, avoiding accidental changing of whitespace etc), and of course the potential for significant lag between receive and update - is merging really a safe option when the article may have been downloaded 6 hours earlier?
Incidentally, is there by any chance a read-only email fetch mechanism for Wikipedia?
Steve
If i had such free service, i'd set a server doing it for me :P If it's a 'private' service, things gets easier: -Authentication: Use a variable account name as password. -Stripping out signatures: You use the same email ssystem -> Always the same signature.
Is merging really a safe option when the article may have been downloaded 6 hours earlier? If it hasn't changed, yes ;) If it's a poppular article, probably not. But merging could wait until i sit in front of a proper computer.
On 2/20/07, Platonides Platonides@gmail.com wrote:
If i had such free service, i'd set a server doing it for me :P If it's a 'private' service, things gets easier: -Authentication: Use a variable account name as password.
A "variable account name"?
-Stripping out signatures: You use the same email ssystem -> Always the same signature.
Well, not strictly true. Friend of mine puts his server's uptime in his sig...
Is merging really a safe option when the article may have been downloaded 6 hours earlier? If it hasn't changed, yes ;) If it's a poppular article, probably not. But merging could wait until i sit in front of a proper computer.
The more I think about the way the current merging algorithm works, the more I think it's probably ok. Because if I'm not mistaken, the system compares what you originally saw with what you're submitting now, and applies those *changes*. So if the original text you're modifying read like this:
John is happy. John is rich.
And you submit this text: John is happy. John is extremely rich.
And meanwhile someone has modified the text thusly: John is sad. John is rich.
Then the final text looks like this: John is sad. John is extremely rich.
(though I think the actual granularity is much higher, like paragraph level).
So depending on the frequency of updates, this may be ok. Certainly I edit many pages which don't receive as much as an edit a week, and the few they receive are predominantly typos, interwiki links, categories, new stub tags...
Steve
Steve Bennett wrote:
If i had such free service, i'd set a server doing it for me :P If it's a 'private' service, things gets easier: -Authentication: Use a variable account name as password.
A "variable account name"?
I didn't explain well. If today you need to post by sending an email to wikipost5de133e7d@example.com, tomorrow to wikipostc9ece41a19@example.com and so on, it's higly difficult to impersonate you (without being a man-in-the-middle, which could catch your password on http, too).
Thanks for all the replies to my initial post. I still see value in an IM and/or email integration with MediaWiki, simply because both of these communication tools are so much part of people's lives nowadays, and while wikis are strong in supporting collaboration through the jointly created article, they are weak in terms of communication (just have a look at how little discussion there is on many of the discussion pages in Wikipedia, which I believe is due in no small part to the clumsiness of this communication tool). I'll try to find someone to develop this, probably starting with an IM integration as this seems easier.
Robert.
Platonides wrote:
Steve Bennett wrote:
If i had such free service, i'd set a server doing it for me :P If it's a 'private' service, things gets easier: -Authentication: Use a variable account name as password.
A "variable account name"?
I didn't explain well. If today you need to post by sending an email to wikipost5de133e7d@example.com, tomorrow to wikipostc9ece41a19@example.com and so on, it's higly difficult to impersonate you (without being a man-in-the-middle, which could catch your password on http, too).
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ok, well, if you're going to go for it anyway, I have these suggestions:
1) Batch Edits - Please batch together IM dialog as a single edit rather than having each new statement in a conversation be a new "Edit" to the page. This is to prevent flooding of the Recentchanges as well as the pages edit histories.
2) Consent - It would probably be good to have a way for your users to "consent" to having their IM conversations logged as wiki pages since this amounts to a sort of cyber-monitoring system.
3) Bot Edits - Depending on popularity, it would probably be a good idea to attribute these automatic edits to a bot user. This is to limit flooding of Recentchanges and watchlist emailings (if they're enabled).
That's what I can think of off the top of my head. Good luck!
-- Jim
On 2/22/07, Dr. Robert P. Biuk-Aghai robertb@umac.mo wrote:
Thanks for all the replies to my initial post. I still see value in an IM and/or email integration with MediaWiki, simply because both of these communication tools are so much part of people's lives nowadays, and while wikis are strong in supporting collaboration through the jointly created article, they are weak in terms of communication (just have a look at how little discussion there is on many of the discussion pages in Wikipedia, which I believe is due in no small part to the clumsiness of this communication tool). I'll try to find someone to develop this, probably starting with an IM integration as this seems easier.
Robert.
Platonides wrote:
Steve Bennett wrote:
If i had such free service, i'd set a server doing it for me :P If it's a 'private' service, things gets easier: -Authentication: Use a variable account name as password.
A "variable account name"?
I didn't explain well. If today you need to post by sending an email to wikipost5de133e7d@example.com, tomorrow to wikipostc9ece41a19@example.com and so on, it's higly difficult to impersonate you (without being a man-in-the-middle, which could catch your password on http, too).
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks for your thoughts.
In fact, I have in mind that there will be a Jabber server with an interface from/to MediaWiki. On the discussion page there will be a "Chat" link (next to the "edit" and "+" links), so that clicking on it will launch the IM program (such as GAIM) with a session that is archived in the discussion page from where the session was started/joined. That is, the logging of conversations will be implicit as users will start up their chats from within wiki. There will also be a list of other online users in the page and a way of inviting them to a chat session.
Regarding your comments:
- Batch Edits - Please batch together IM dialog as a single edit rather
than having each new statement in a conversation be a new "Edit" to the page. This is to prevent flooding of the Recentchanges as well as the pages edit histories.
Hmm, these are valid considerations. One would hope that conversations are not too long. If you have IM sessions that are still alive after a couple of hours then those outside the session might miss quite a bit of the pending discussion page update.
- Consent - It would probably be good to have a way for your users to
"consent" to having their IM conversations logged as wiki pages since this amounts to a sort of cyber-monitoring system.
As mentioned above, the IM conversation is launched from within the wiki making the logging implicit, but you're right that users should be made aware of this. "Use implies consent to archiving of the conversation in this page" sort of thing.
- Bot Edits - Depending on popularity, it would probably be a good idea to
attribute these automatic edits to a bot user. This is to limit flooding of Recentchanges and watchlist emailings (if they're enabled).
Kind of same as above. If an entire IM conversation gets saved by the bot and assuming that there won't be more than a couple of these per day then a flooding is not too likely. Of course an entirely different case may exist on chat-crazy sites.
That's what I can think of off the top of my head. Good luck!
Thanks Jim!
Robert.
wikitech-l@lists.wikimedia.org