Eventually, the aim is to explore the concept of LiquidityOfTrust. Some related ideas are described on WebOfTrust, TrustMetric, WebOfTrustModeration, FunctionalAccessTrustMetric, and there's also an early external [exposition]. The basic idea is to create an accounting system up to the task of recording and communicating the information needed for people to make informed decisions about whom they can trust, and in what ways they can trust them.
In addition to pages on this wiki, there is a ConceptMap [here]; a blog [here]; a dormant wiki [here]; and post about a possible implementation of TeaRoom?s on FriendFeed? [here].
The first project was a wiki which uses BranchedHistory? for its pages instead of the LinearHistory? model used in other wikis; a test wiki is [online] (it's a proof-of-concept, missing some necessary features).
In the aftermath of the first project, it introduced some new ideas for discussion. To be clear, these concepts are not yet implemented, with the exception of BranchedHistory?.
These concepts facilitate:
What I really meant was a BranchMess?, where the different branches get too disorganized to contemplate; in any case, ConceptMaps seem like a valuable tool. What I'm currently contemplating is that the viewer should be able to choose his or her own visualization solution, and that it makes a lot of sense for the server to simply present the raw data, and to have the summarization and visualization be done client-side. The data should be in machine- and human- readable format, so for a small or inactive wiki just reading the raw data would be feasible. I've written more on the [TeaTime wiki page], while Meatball was down, but it's a little disorganized and scattered. -- NathanielThurston
Your statement that... ...it makes a lot of sense for the server to simply present the raw data, and to have the summarization and visualization be done client-side... resonates with some of the (AjAx?) TiddlyWiki concepts I've been working during the past couple of years. Combined with meta-data (and MicroContent?) techniques, I've become quite committed to pushing the envelop I find constraining most of the data processing systems I encounter, out a bit further.
In the long term, I think it inevitable that Individuals will take custody of their own data, rather than relying on data stores owned and managed by Corporate or Goverment third parties with conflicting vested interests. I expect the first application systems that will move in this direction will be the Health and Medical applications, if only because it is increasingly evident that Electronic Heath Records combined with Expert Systems technologies, can outperform the traditional medical practitioner who relies merely on paper, personal experience and mental faculties. I even expect this trend to accelerate as the costs of "traditional" approach continue to escalate and financial resources continue to become ever more constrained. If medical records follow this path, the switch to "electronic" financial records and assets will also accelerate. Obviously, I believe the next couple of decades are going to be quite fascinating to watch.
I certainly agree with you that a "BranchMess?" could develop quite easily, but then managing that kind of complexity is precisely why once should strive to automate the process.
I'm not at all sure that these comments will appear to be anything other than a bit of a "ramble", but it seemed to me that I should at least offer a bit of encouragement to you in your pursuit of TeaTme?.
Hans, thanks for the encouragement.
Regarding custody of data, my speculation is that this will wind up being a community effort rather than an individual one, with a small and technically-competent group within the community taking responsibility for security, system maintenance, and keeping current with technology. I also imagine that the switch will take place in just a year or two, once there is a technology platform with all of the right properties (easy-to-use, attractive, ultra-compatible, and free software all seem necessary).
I'm in the throes of throwing together a basic implementation, based on the UseMod wiki. I'm looking for a place to host it; the main requirement is to have a public git repository which can be used from the perl CGI script.
I suspect that the issue of "individual"" versus "community" is not material, especially if one allows for a very small group. The distinction I was trying to make is that the current "large" corporate and government repositories are not likely to be the ultimate repositories of anything other than one (of many) copies of the "authoritative" data. There are many independent forces actively pushing things in this direction, but that is unlikely to be appropriate content within this page. I, for one, do not want to trust the current custodians of data about me. They make far too many mistakes and take far too many liberties with it, for my comfort. But then, having worked for one of the largest banks in the world, I learned just how important it is to check each and every one of the transactions they process against my account(s)! I'll add a smilie :-) because I know most people simply don't bother and simply think that I'm either strange or paranoid.
I've been watching a couple of wiki-git projects for the past few months (especially the OddMuse based effort) and I do get the impression that it's sufficiently promising to attract quite a bit more attention. Good luck with your endeavors!
I'm thinking about a 'Revert' button to use for de-spamming for the TeaTime wiki, and I was intrigued by Radomir's comment about its non-advisability. The way I imagine it working:
Would such a scheme be an improvement?
Nathaniel, yes, it is a pleasure to see how your scheme can help to reduce Spam and Vandalism by a TechnologySolution. To fire up the motivation of Wikizens to actually use these technological gems, I suggest to give vested/weighted users the opportunity to incorporate their free Google:PaypalFrontstore on their WikiHomepage (perhaps even additionally on dedicated SharedOpenbusinessWikipages?). The social Mega-community http://MySpace.com already offers such widgets on profile-pages of their members. Benefit: WikiNomics aware and practising wikizens will defend their Wiki with much more commitment, then casual/part-time/hobby wikizens. -- FridemarPache
PS.: There is even a Wiki:GoogleStorefront lurking in the grass.
Fridemar, this would certainly be an acid test of TeaTime, as it seems to me that the front store would be a prime target for vandals, trolls, and thieves (modify the storefront to point it elsewhere...). I'm not sure I like the notion of classifying who's vested and who's not; what's the harm in allowing anyone to have a storefront? Also, I'd suggest that any payments made be voluntary gifts, after the service has been performed, in the spirit of PredominantlyGiftEconomy (also to ease legal concerns). On balance, I think I like the idea, and I'm contemplating an implementation with DalPay? soon after the public launch of the branched wiki software. -- NathanielThurston
Chris, I'm delighted you're starting to get it. The concept has been taking shape (EditClusters? aka TeaRoom?s are a recent addition). I'm still in the process of teasing out some other concepts, including PendingEdits? and WeightedConsensusVoting. -- NathanielThurston
Chris, thanks for AuthorizedCopy/AuthorizedView.
I think I may have chosen poorly with the name "PendingEdits?" -- it's not that the edit starts out "pending", but that it's possible to move an edit to the pending state, as "needing more discussion". The idea is that SilentAgreement in a TeaRoom? is the usual practice, and that the voting procedure is only used on rare occasions. There's no way to customize the approval mechanism, but each TeaRoom? has its own AuthorizedCopy of the VotingPower? page, and so the voting power can be adjusted. Thinking it over, I now realize that it might be wise to have a policy page (subject to AuthorizedCopy) which specifies whether everyone can post edits into the "Yes" state, or just people with voting rights... this gets more complex than I first thought; see below.
A TeaRoom? contains only modified pages, and is backed by implicit links to the parent TeaRoom?, so changes to unmodified pages are automatically seen. TeaRoom?s exist with the assent of the parent TeaRoom?, so the existence of an ongoing fork would be a matter of community policy and/or decision. In the wiki I'm designing for my own use, there will be a number of "disconnected" TeaRoom?s, with TeaRoom?s for various mostly-unrelated projects I'm working on.
Finally, I hope that the "AuthorizedCopy" in the exposition of BranchedHistory? will, in most cases, be "StableCopy". The consensus mechanism is different -- to disagree, you must revert the change (or mark it as pending, or move the change into a child TeaRoom? for discussion), but the intent is that consensus should be present before the edit is accepted. The difference is that it becomes possible to make edits after the agreed edit without upsetting the consensus process. -- NathanielThurston
These are problems with wiki in general, and TeaTime doesn't provide a complete answer. Two possibilities:
Another solution is to mark the disputed edit as "pending" (would "undecided" be a better name?), and start a meta-discussion explaining your point of view and why the community might agree with your opinion that the edit should be reversed. In this way, you can say that you personally disagree with the edit without expressing an opinion about what the community will wind up deciding. How often does this sort of thing come up? -- NathanielThurston
About the "permission to speak" questions: "who is permitted to post a pending edit?" and "who is permitted to move an edit from pending to accepted?", Chris started a train of thought: In the long run, I imagine having a MinimumSalience? setting for a TeaRoom? or a page in a TeaRoom?, so that only edits which were prepared in a subroom and had been "voted salient" to a specified threshold (using the WeightedConsensusVoting procedure) were granted entry -- and if a TeaTime wiki grew to the size of Wikipedia, this may be appropriate. However, I'm worried about creating yet another flawed TrustMetric, and I think we can safely ignore this possibility when thinking about coding the next iteration of implementation. -- NathanielThurston
Nathaniel, your CherryPicking? alternative minimizes the bureaucratical overhead, especially if we work on super-lean wiki-pages, aka cmaps. This reminds me faintly of ViewPoint. -- FridemarPache PS.: By the way, a modern wiki should make the cmap protocol links clickable and imbeddable in bracket notation :-)
My criticism of TeaTime is straightforward. You've planned a hundred steps ahead of where you are. Where are the people? Focus on building TheAudience (aka the market), rather than building the technology.
Upon reflection, my feeling is that I don't need anything special -- the only change I would really make right now is to start using a RSS aggregator so that I don't have to choose between checking all of my micro-wikis daily or settling infrequent updates.
Another TeaTime-like project: http://friendfeed.com/dango-project. It has the advantage of actually being implemented in beta form, and it seems like it's well on the way to making a federated social network a reality.
Sunir, the reason I planned so much with TeaTime is that I needed confidence that the communities I enjoy the most will be able to scale as needed without destroying their character. I guess it boils down to "don't start something you won't want to finish".