OpenWetWare:Software/Private Pages

There have been requests and questions about having content on OWW that is not public, not indexed by Google, not editable by everyone on OWW, etc. This page aims to discuss this policy.

There seem to be 2 major methods of implementation:

1. Groups + access control (rumors MediaWiki may be working on this).
2. Encryption. I have implemented an extension which does this. It's available here on the development site for anyone who wants to play around with it.

A third option: Wiki farm.

Discussion Questions:

Private Wikis

See Subwikis --Austin Che 15:00, 6 December 2006 (EST)

Proposal for Private Page Policy (P^4)

Jasonk 11:47, 5 May 2006 (EDT): So there has been some great discussion on this issue, though it has slowed down of late. I wanted to submit a proposal for a policy on the issue of private or encrypted pages on OWW to clarify the issue/start discussion again.

Background

From the discussion below. Private pages have the potential advantages of:

1. increasing collaboration among subsets of the community
2. increasing the user base by overcoming one of the common concerns of new users
3. "almost" getting more content, e.g. private content can be easily made public, so maybe private page users will be willing to do so over time thus increasing the overall content contribution.

It has the potential disadvantages of:

1. OWW becomes responsible for ensuring security if we claim pages are private (if not legally then from a PR standpoint)
2. OWW becomes less open

Lastly, Sri spoke at the last steering committee meeting about an OpenWetWare Mediawiki "distribution". This distribution would be simply the latest stable version of Mediawiki bundled with the custom extensions that have been developed for the OWW community. There was a fair bit of debate over how much work this would entail and what OWW gets out of it. I bring it up because I think it may help us deal with the private pages issue.

Proposal/Justification

In thinking about private pages more, I've gotten concened about a new site visitor browsing OWW labs and bumping into blocked pages. The message sent by a "viewing of this page restricted" or by a page full of encrypted text is not a great one in light of what OWW stands for. That scenario, helped crystallize (for me anyway) that a central tenet of OWW is that someone should be able to browse anywhere on OWW and read everything. What remains then is that we need to come up with a technical solution to enable our users to have a feature they want, specifically: private pages that can be viewed by a subgroup of the community and easily moved into OWW at a later time, but don't reside on OWW itself.

By encouraging people who want a personal wiki (e.g. for a lab notebook) or a private wiki (e.g.for a lab writing a paper or a group of labs on a grant sharing ideas) to use the OWW distribution and create their own, separate wiki we could gain the advantage of providing that service in a (somewhat) accessible fashion, while still keeping OWW completely open. Additionally, for a new lab that will only "join" if they can have a private site, we are giving them an OWW-branded version of that -- I think this will significantly increase their chances of moving their site onto OWW in the future since (1)they'll be using the same software (2) they'll be "indebted" to OWW for the distribution and (likely) for occaisonal support.

I would even suggest that we consider offer hosting for these wikis, just to bring them closer to the fold. For instance, you could imagine signing up a new lab who wants a private wiki, every account made on that wiki could automatically generate an OWW account as well. Again lowering the barriers for their eventual move to OWW. As a first pass we could offer this to a couple labs and see how it turns out.

OpenWetWare's (PROPOSED) Policy on Private (read-restricted) Wiki Pages: We understand the need for privacy at various stages in the research process of academic labs. However, enabling private pages on the site would run counter to our mission of enabling free and open sharing of information. As an alternative we encourage you to start a private wiki on your servers (or ours maybe) using the OpenWetWare MediaWiki distribution. This distribution contains all the software tools and customizations that we have developed for OpenWetWare.

OK, just throwing this out there. Let me know what you think. Also, the distribution and accompanying support type stuff may not be feasible with our current "technical staff" of volunteers, but I was trying to figure out the "best" solution independent of whether we had the resources to implement it right now.

• Austin 14:23, 5 May 2006 (EDT): I'm not sure how encouraging separate private wikis would be useful. If your primary concern is people browsing a page on OWW and getting a 'page restricted' error, then it is just as easy to instead get a 'page not found' error so they don't see the page at all. I don't see how else an easy move to OWW would be implemented. You'll have possible page name conflicts and things like that using a separate wiki on merging entire wikis. Consider the following use scenario (requires major technical work): People are allowed to create private pages which are not readable by others. Other people cannot in any way figure out that this page exists. Links to it don't exist, searches don't find it, etc. At any time, there's the notion of the "most recent public version" which is what the "public" sees. If someone follows a link to a page which they don't think exists (but it does privately) and edits it publicly, then that version becomes the latest public version. Some way to handle what the private view is after this public edit needs to be determined. At any time, all previous private versions can be easily made public. Future edits can be either continue to be made public or be made private again. This essentially allows any edit to be made private while remaining on OWW and completely concealing the fact that there is a private page.

• Jasonk 15:00, 5 May 2006 (EDT):Seperate private wikis would be useful because it will enable groups to collaborate on projects that are not yet ready for public consumption. I'm pretty certain groups are going to do this no matter what (whether they make their own wiki (e.g. alpha project, sorger lab) or whether they set up a writely document (e.g. our iGEM team), etc. The purpose of having an OWW-branded private wiki is that when they are ready to publicize projects they may be more likely to do so on OWW. For instance, you could include a link on the sidebar saying "Publish this to OpenWetWare". I think a "page not found error" is pretty much as bad as a "page restricted error". If you could get rid of the link like you suggest above, that might be a decent solution, but you'd still have the issue or "merging" the public and private versions when you wanted to "go public" with a private page. I thought we had a scheme for doing a wiki merge, so long as the whole thing went under a new unique "XXXXX:"?

• Austin 16:26, 5 May 2006 (EDT): How is a page not found error any different from the page actually not being there? I actually am suggesting that from the point of view of the general public, there is absolutely no way of knowing that private pages exist whatsoever. If a link from a public page goes to a private page, then the link will appear to be a non-existent page. There's no point to remove these links anymore than we have plenty of links right now pointing to non-existent pages. I really don't know how a "publish this to OWW" would actually work. Does it just copy the one page with its history (to which page)? Wiki merge is possible but not absolutely simple given things like users, general pages (e.g. what happens to stuff under the Help namespace?). It also requires shell access to the server (i.e. a decent amount of technical experience, and probably requires the help of someone on the OWW end, especially for things like images for which conflicts are difficult to handle). If using unique prefixes, it would be identical to putting your pages under that prefix and the chances of some random public person editing it is essentially zero. As for merging public/private versions, the easiest to implement and I think makes the most sense is to simply take the newest version. When looking at a page, everyone always sees the newest version that they can see. Thus, for the public, they see the newest public version (ignoring any newer private versions). The private people see the newest version regardless of public/private. Compared with encryption on OWW, this method provides less security but is more wiki-like. But for most cases, I can envision that this is good enough security. The only potential problem I see with this (and the encrypt methodology) is that of the images. It is always theoretically possible to directly access the url of an image (no script can get in the way and prevent access). One disadvantage of this approach vs. a separate wiki or encrypt method is that it becomes necessarily to invent some sort of group or access control mechanism. With a separate wiki, we assume some external access control and with encryption we assume common knowledge of a key. With this, there has to be some way of granting access to users, but that's probably just implementation details right now... I personally like this method the best, but it is also much more difficult to ensure correct implementation compared with encryption. Every point in MediaWiki that accesses a page content needs to be checked (for example page text shouldn't appear in searches). By encrypting, you are ensured that these other MW accesses will only get garbage.
  • Jasonk 17:03, 5 May 2006 (EDT): I agree that there are implementation details no matter which approach we take. (some will obviously be more complicated than others). If we ignore the implementation details for a second and imagine we could implement anything we wanted, what would be the best solution for the community? The point I was making above is that in that "perfect-world" scenario we would not want to have either "page not available" or "page non accessible to you (or encrypted)" links prevelent on OWW. I like Austin's idea of an implementation where you can make private pages that don't come up in searches, dont show up as links, etc (e.g. basically a private wiki hiding in OWW that ensures when(if) it "goes public" later there won't be name conflicts with OWW). I think the completely seperate private wiki is another solution, but you'd have to deal with the name conflicts. However there are technical issues in both (hiding links/ensuring security in one, wiki merging/name conflicts in the other), but in essence both are creating private wikis (though in Austin's case we explicitly host them on OWW).

Is it in OWW's "open" or "wiki" nature to have pages that are private in any form?

1. • Sri Kosuri 17:15, 20 April 2006 (EDT): I think that this could be a useful excercize. I think one of the problems is that once people start using it, there is no turning back... we have to continue to support it.
   • yeem 20:31, 21 April 2006 (EDT): I believe that there should be a free flow of information, and that encrypted pages are a barrier to said exchange. If a lab requires a private page, perhaps it should be taken to an external site that requires certificates or another access method. As far as I can tell, there is no harm in being indexed by Google, and I don't know of a whole lot of ways to circumvent it. The page would have to be deleted and kept deleted until Google's next cache purge. Non-editable pages should only be reserved for pages that are critical to the continued functionality of the wiki, such as things in the "Special:" namespace.
   • Austin 21:50, 21 April 2006 (EDT): We also need to be practical. Free flow of information is good but isn't always practical. I wrote this extension because we needed it. We were interviewing people and required a mechanism for communicating our notes between us and email is very cumbersome relative to the wiki. As you say, there's always private wikis (which we did end up using), but it would have been much more convenient for us to do it on OWW as related non-private stuff was on OWW. A different practical case could be the idea of publishing work. People may want to collaborate on the wiki using an encrypted form and after publication or after some time, to "declassify" it by removing the encrypt tags. The benefit of this method of encryption is that it is really easy to go from private to public (and basically impossible to classify something that's already public). By forcing people to use other wikis, you lose the time that people would spend on OWW (which could be used for sharing stuff), and the possibility of easily "declassifying" portions and making it public. The main potential drawback of enabling an encryption extension is if people encrypt something they wouldn't have encrypted otherwise. However, it is still OpenWetWare, and people who are on here, by and large, want to contribute. It's only those cases (like ours) where we cannot make something public. Given that we are the ones running OWW, it seems to make sense to me to run it in any way that's useful for us. As a side comment, I'd like to point out that unlike the noedit idea, enabling encryption could in some sense increase collaboration. It's really shared wiki encryption where everyone with the key can edit the page. So it's still a wiki just with a controlled group of people. People who would not have used the wiki otherwise may collaborate/edit if it's encrypted. It doesn't hurt anyone else on the wiki unless information which would have otherwise been public is encrypted (which as I said, I think is unlikely).
   • Jasonk 13:07, 23 April 2006 (EDT): I wanted to seperate two issues: (1)Research Information (e.g. protocols) and (2) Personal Research Projects (e.g. someone's thesis). The reason for this is that I think there is little value to OWW users for keeping (1) private, but there is some value to keeping (2) private.
   • First dealing with (1), contributions in the "public research information spaces" of OWW - materials, protocols, etc. As I see it, there are 4 types of users:
     1. Only use wiki if it can be completely private to their lab, never contribute to public areas.
     2. Make everything they do (within reason) public, even if access restriction was available
        • e.g. steering committee types ;)
     3. Will contribute more to public areas of OWW if access restriction was available
        • e.g. I'll join OWW if I can plan my research there in secret, but will put up all my protocols in the public area. However, if I can't have private pages I wont join at all since site is useless to me.
     4. Will contribute less to public areas of OWW if access restriction was available
        • This group is the people who without the restrictions would have eventually gotten over a fear of putting up stuff in public, but since the restrictions are available they go with their initial instinct to make everything private.
   • We can ignore the first two groups in this discussion since their actions are unaffected by having private pages available. In particular, though the first group would appear "parasitic" they really wouldn't hurt anything other than space/bandwidth which I think we should pretty much not worry about now. (and they might come over to the good side eventually) So the real question is what is the ratio of group 3 to group 4? My guess is that 3 outnumbers 4, but dont have much to back it up.
   • Secondly, referring to "personal research projects" now - not having private pages may lower the capability of OWW to encourage collaboration, since it's fair to expect people to plan some projects in private. Since part of OWW's mission is to provide an online space to better enable collaboration, we may be hurting ourselves by preventing private pages.

What's the "right" way to do encryption

1. • Austin 16:38, 20 April 2006 (EDT): The current implementation allows users to put <encrypt> tags around any text they wish to encrypt. Keys are stored via users' preferences. Text is automatically encrypted/decrypted on views/edits if a proper key is found. File uploads (images) are not encrypted. This could be another issue.
     • Sri Kosuri 17:15, 20 April 2006 (EDT):Can you store multiple keys?
     • Austin 17:47, 20 April 2006 (EDT): Not right now, but definitely what I had been envisioning. Each user would have a list mapping page names to keys.

How would people likely use such features? Would the majority of their content be public or not?

1. • Austin 16:38, 20 April 2006 (EDT): My belief is that anything to get people on to OWW is good even if some of the content is private.
   • Sri Kosuri 17:15, 20 April 2006 (EDT): I think if we use the encryption extension that Austin made, most of the content will remain open, if only it is much more cumbersome to close it. I am probably for this option.

Encryption vs. Access control

1. • Encryption can provide greater comfort of security (even administrators may not be able to access page content)
   • Encryption doesn't technically provide more than what users can do currently (i.e. in theory, anyone can put any encrypted text on a page, it's just not particularly easy).
   • Encryption does not provide anything other than secrecy (i.e. cannot control someone else from messing up with your page, even if that someone else has no idea what they are messing with).
     • Johncumbers 22:16, 20 April 2006 (EDT) This looks good Austin. The main concern that people have at Brown, when I tell them about OWW is that somebody will edit their user page/protocol whilst they are not looking. So whilst I don't think that I'd use encryption like this that much at the moment(we have just set up a private wiki for the lab fly stocks/vectors/research) if the protect tab could be developed to prevent editing by other users then this would be most useful and also in the unlikely event would prevent encrypted pages being edited. I do see the point that once we go down this road there is no turning back however. It is a difficult situation.
     • Devin 11:55, 21 April 2006 (EDT) I like the idea of <encrypt> tags a lot. Having entire pages as private content seems to defeat the purpose of OWW by making it more like a hosting service and less like a collaborative effort. Tags allow for some private content but, it would seem to me, are just inefficient enough to prevent wholesale hiding. One thing which might be useful for addressing John's point about protocols is a <noedit> tag that would only allow the creator to modify the protocol. Others could still view it and comment on it, but not mess it up.
     • Austin 12:28, 21 April 2006 (EDT): I don't like the idea of a noedit tag as that really goes against the idea of a wiki. Perhaps if the tag was an advisory tag rather than a mandatory tag (perhaps an extra "are you sure you want to edit this page that someone said shouldn't be edited"). For the cases where people want to publish information publicly but would rather others not edit it, are they not satisfied (or don't know) that they can watch those pages and be notified by email on any changes? It's easy to revert unwanted changes.
     • Devin 16:47, 21 April 2006 (EDT) Granted, it goes against the idea of a wiki, but the starting point of this discussion is that perfect wikiness is not totally satisfactory for OWW. There need to be some trade-offs made, and it is reasonable to think that there is some content that shouldn't be edited by everyone. I may want to make a protocol available, but not want to check the page history every time I refer to it. If a lot of people take interest in the protocol, I or someone else can promote it to the main protocols section with full access. Thinking about the encryption more, I am skeptical of the idea that it would be advisable for anyone to place private content on OWW, or that it would be advisable for OWW to make any claim as to the security of the info. What if valuable, sensitive info was leaked? The depositor would have given up control over the security of the information to OWW, but they would have no legal recourse. In my view, noedits are a more minimal solution and much less damaging to the collaborative spirit than encryption. In fact, I take back my initial enthusiasm for encryption and place it in the camp of noedits. (Assuming of course that they are technically feasible.)
     • Sri Kosuri: Just to point out, you can always point to a particular version of a page/protocol, such as this one [1] if you are worried about people editing it in the future. That particular version is not changeable by anybody (including administrators). So if you have a set of protocols that you want to use, you can just links to the current history files of your particular pages. So there is a way to do this, it is just cumbersome. The question is do you want to make it easier with a noedit tag. My initial thoughts on this is that it is not worth the hassle right now. W.r.t security, I agree with Devin, that we cannot guarantee any level of security (as everything, from passwords to data will be sent over the net in clear text). The encryption will protect against indexing by sites like google, and reasonable levels of security (I think to some extent, that's all that many people want). People should never put really private things on any kind of public website.
     • RS 14:01, 22 April 2006 (EDT): It's funny that Devin changed his mind because I actually agree (mostly) with what Devin has said in his original comment. OWW is a collaborative effort rather than a hosting service. Frankly, I am still unsure whether we should enable any sort of encryption or access control on OpenWetWare since the purpose of OWW is to be open. But given a choice between encryption and access control, I prefer encryption for a few reasons. (1) As Devin and Sri have said, encryption tags are hopefully just inconvenient enough that people won't use them by default. (2) Enabling pages that are world-readable but user-writable turns OWW into a webpage hosting service. Ideally, I would like to see encryption tags only used by users who have contributed a lot of open content to the site and just need to hide a bit of stuff relevant to a project. I agree with Austin that advisory no edit tags are preferable to enforced no edit tags. I am not convinced that adding access controls will get us that many more users and even if it does, I am not sure how much value would get added to the information base of OWW.
     • Jasonk 13:07, 23 April 2006 (EDT): I agree with Reshma, I think we get little value from the edit-access restrictions. In my experience the concern over someone editing "your stuff" can usually be pretty easily dealt with (page histories, userIDs, no vandalism thus far, etc). It's a knee-jerk fear from a lot of new users but I think most people get over it after using the site a little. The issue of read-access restrictions should remain the focus of this discussion I think. This is a problem where I think the usefulness of OWW for collaboration may be lowered by not having private pages (i.e. I may not be willing to use OWW to plan a project between 3 OWW labs if I cant keep the pages private to just those labs). see my post at the top.
     • yeem 02:57, 25 April 2006 (EDT) I would also agree with Reshma, and echo Jason's points. If people are afraid of vandalism, they really shouldn't be. Probably more than 98% of Wikipedia's vandals are anonymous IPs, and the remaining couple percents are throwaway accounts created for the express purpose of vandalism. Since we're already restricting who can edit OWW, and also controlling who can receive an account, the potential for vandalism is slim to none.
     • Devin 12:46, 24 April 2006 (EDT) This is a very interesting discussion, and I think there are a lot of good points. I'll just reiterate a few of mine, then be done with it: First, I agree that edit-access restrictions are of maginal utility and probably not worthwhile. Second, and more importantly, I think that encryption capability does profoundly change the nature of the wiki in a way that is worth thinking about: If a new group joins OWW on the understanding that they will be able to keep some pages secure, then OWW has assumed some level of responsibility for maintaining that security. The contract between OWW and the user is very different in this circumstance. Groups that collaborate in secret do so presumably because they have some material interest in keeping the info from their competitors. A security breach would damage OWW's reputation, and possibly expose it to a lawsuit. Is this really something that OWW should take responsibility for? I argue no.
     • Austin 13:54, 24 April 2006 (EDT): OWW should definitely not take responsibility for security but I'm sure we can (legally if need be) dispel any notion of a contract with users for security (get some lawyer working on OpenWetWare:General disclaimer). With encrypted pages, the weakest point is also definitely not in the encryption but the network itself (OWW isn't https so everything is as secure as normal email). In any case, I think we don't want to market an encryption feature as NSA-secure.
     • Devin 19:47, 24 April 2006 (EDT) Wow, this is fun. Austin, I think this is a very difficult line to draw. You say above that, "Given that we are the ones running OWW, it seems to make sense to me to run it in any way that's useful for us." I think OWW passed that point already. For better or worse, OWW is a service that outside users are coming to depend on, and you can bet your bottom dollar that they feel that there is a contract between "you" and them. It may or may not be legally enforceable, but people's reputations are surely at stake. Furthermore, I don't think you can any longer count on the average user to understand the fine points of internet security. If OWW offers a service like secure pages that it cannot stand behind, then...I don't know, but it's bad news, man.

Earlier discussion

Last week I've had an interesting email discussion with Sri, and one conclusion was that local levels of privacy inside of a given wiki site that could be easily modified by clicking on a specific tab would be a good thing to have. So far I see 3 levels which might be more or less appropriate depending on the page contents:

1. everyone can edit without restrictions, like in Wikipedia or Wikiomics.
2. only verified users can edit, like in OWW. Verification can be made by a human like right now or by verifying the email address, but the latter might still be a problem (some people can have an infinity of email addresses for a given domain so they don't mind being banned for one address).
3. password-protected page, i.e. nobody can even read the page unless this person belongs to a given group of people.

Concerning technical limitations, MediaWiki does not provide the following features at the moment AFAIK:

• automatic account creation that requires email verification (it exists for email notifications, but it doesn't prevent from creating and using an account for editing)
• the "total privacy" feature is not available in MediaWiki
• switching from one mode to another for individual pages is not implemented either

The difficulty I guess would be to maintain these extensions without forking MediaWiki, i.e. by maintaining a patch for the mainstream version of Mediawiki or better get these changes incorporated into MediaWiki. --MartinJambon 21:30, 18 January 2006 (EST)

I think the idea of local levels of privacy is a decent one so long as the overarching purpose of them is to encourage collaboration. For instance, having a page which is only viewable/editable by a subgroup is usefull for collaboration on a project that is not ready to be "released" publicly yet -- so that's good. However, having pages be only editable by a subgroup so that I can "protect" my lab pages from being edited by OWW vandals/miscreants (that don't exist) is bad. So the issue becomes, how do you offer varying levels of privacy without labs falling into the knee-jerk -- "set all our pages to only be edited by our lab or else something bad will happen" -- response? One way is to specifically not offer the option (which you didn't list) of world-readable/specific member list editable. That way if you think that no OWW member should edit it, then it better be something that no one can see either. (ugh, on 2nd thought I don't like that -- see second comment on option (3) below.) My last concern is that adding different levels of privacy may make the process of contributing more confusing, i.e. how do I make sure I don't accidently set a page to be editable by anyone so I end up with spam on my lab website? If that's a point of confusion for new users they are going to be more hesistant to contribute(this is less of a problem if you drop level (1) above I suppose).

• Speaking of level (1), on wikiomics how many contributions did you get from anonymous users? Also, what level of spam did you have to combat -- I have a strong concern about the level of that kind of stuff that lab heads will put up with before losing faith in the project. For instance, if someone comes accross a Viagra ad in the middle of a protocol it would do some damage to the credibility of the site.

I would say half of the edits are made by anonymous users, and it's true that these edits are usually short but yet useful: adding a link to some resource, rephrasing sentences or fixing typos (many people like me are very bad at writing in their native language, and even worse in English, which makes these edits very useful). Look at any page in Wikipedia: I believe new contributors feel really good when they discover that they can contribute immediately, even if their contribution is just to fix a typo.

About vandalism, you seem to confuse spam (Viagra kind of links) and manual, subtle degradation of detail-sensitive information (say add a zero in some quantity in a protocol):

• Today's spam is effectively fought using the SpamBlacklist extension of MediaWiki (uses a blacklist of URL patterns). Occasionally, new spam waves occur so you might have to revert a few changes manually, but the goal of these people seem to be improving their ranking by search engines rather than destroy wikis (although it probably doesn't work). Anyway, so far so good, I don't have to complain too much about spam since I installed SpamBlacklist on Wikiomics. What can happen and reportedly happened on other sites, is that some evil robot made by a frustrated reader clears all the pages of the wiki (let's say several thousands). In this case, the best thing to do is restore the last sane backup of the MySQL database - that's not a big deal if backups are frequent. Specific heuristics can be used to limit this kind of problems, such as quotas of edits per hour or stuff like that. So I am prepared for that kind of accidents and have no fear.
• email notification is a great tool to watch the edits made by other people: I often check the diffs, especially if I don't know the author. I am not familiar enough with lab protocols to judge anything here, but computer programs are similar in the sense that they are detail-sensitive and we might be afraid of that. However some people do post short programs on public wikis, and it seems to work okay in practice (see for intance Metawikipedia:Category:Mediawiki_Extensions). --MartinJambon 03:44, 21 January 2006 (EST)

• Although I think this is a good idea, I understand Jason's concerns. One of the things that makes this is a useful community is users trusting one another. If people resort to editability restrictions on their pages, in place of community trust would be bad. However, I don't think that's what will happen. (and plus, we can make it such that discussion pages are always public)
• Actually , I'm very worried about option (3) as well. I can easily see a lab joining and deciding that all their protocols should fall into this category. I.e. they should be viewable/editable only by people in the lab, and as a result OWW just becomes a free hosting service for intra-lab wikis. How do we avoid that fate while enabling a way for people to collaborate on more "secret" projects (whatever those are)? Jasonk 22:33, 18 January 2006 (EST)

I enjoy working with a private wiki for my own research, and the idea is that people are more likely to convert private stuff into public stuff if they only have to press a button (or two). Of course the opposite is also true, but the net result is more freedom. Farms of free private wikis already exist (e.g. http://pbwiki.com), so if people want to keep things private, they will do it anyway. But anyway, one of the main problems is the standardization of the wiki markup: even very basic things like hyperlinks vary from one wiki engine to another, and I am not even talking about images or tables.

I am not worried about the cost of private subwikis: we can impose quotas on the size (in bytes or/and in words), place Google ads, or uglify the page if it remains private too long.

--MartinJambon 03:44, 21 January 2006 (EST)

• No ads. --Sri Kosuri 18:38, 22 January 2006 (EST)

• I agree with Martin here, I think the more options the better. However, we may want to make it automatic to publish as is, and provide ways for users to make something private access or public editable. We could always police ex-post facto. Could try as an experiment, and see how many people actually use it for private purposes. --Sri Kosuri 18:38, 22 January 2006 (EST)

Yes, but this is not a cheap experiment since it requires non trivial changes in the source code of MediaWiki: we really need faith in what we are doing here. I am still very much attracted by the idea, but extending MediaWiki, due the nature of PHP, is painfully slow. Anyway, people who only know this kind of programming languages won't complain, so it's okay. But not for me; and I hate suggesting things that I wouldn't do myself --MartinJambon 21:29, 22 January 2006 (EST)

Maybe we would be better off focusing on interwiki/interformat transfers, rather than make MediaWiki even more complicated than it is already. Being able to transfer some material from one family of wikis to another would be nice. If someone would develop a polyglot wiki language converter, and each wiki engine would use it to import/export material using a central format, that would be cool. Still, I won't do it myself because I am too busy doing other things. --MartinJambon 21:44, 22 January 2006 (EST)