Communities Wiki

This is a wiki beyond wikis. Beyond XanaduProject. And it's supposed to be just 'Communities'.

An interesting thought experiment, but would anyone call it the definition of a wiki?

Why not?

Salvaged from another page:

If you create a wiki engine sufficiently superior to the current crop of dreck, you can no longer tolerate using HTML for object transport, nor tolerate web browsers for rendering. Apparently, if you make a wiki really good then it's no longer a wiki, cause wikis are defined by their defects. -- rk

Or more positively, a wiki is a solution, with certain limitations, to a problem in a real-world context. It's worth considering that all interesting engineering involves finding sufficient solutions within external limitations.

That's only because most programmers don't have the imagination required to change the real world context. If you can put your own wiki client, with its own presentation layer, on every desktop then you can do away with html entirely. Meaning, if you can actually implement CommunitiesWiki in such a way that everyone buys into it then it automatically becomes a wiki.

Actually, Richard, I think that's a good idea, although you're wrong that no one has the imagination. Lots of people desire something roughly along those lines, and have been very vocal about it. No, the problem has been the scope of the work apparently required to accomplish it. The obvious ways to do it require too much work to have been finished yet, and I'm not aware of anyone having figured out a clever way to do it with a small amount of work (such that e.g. a single programmer might accomplish it in one year worth of spare time).

It's not necessarily within the scope of "ideal WikiEngine" for those reasons. After all, that extends it to ideal Internet (or rather, ideal WorldWideWeb), not just ideal wiki. But I certainly have no quarrel with anyone who wants to make such improvements. Making the world a better place is a GoodThing. -- dm

A single experienced programmer might indeed accomplish it in one year's worth of spare time. The trick is to come up with a killer app and then to build onto that base other killer features.

The killer app accomplishes two things. Firstly, it lets you overcome the inertia of the network effect. Secondly, it gets you a large enough user base that every single killer feature is popularized and increases your own momentum.

The problem with programmers is they lack the imagination to 1) realize they need a killer app, 2) come up with a killer app, and 3) sustain deep creativity for several years. So instead of constant improvement, we see one-shot efforts like this wiki.

Define "wiki".

The fundamental objects in an ideal wiki are Paragraphs, which are versioned.

Sounds a bit like PurpleWiki.

Each paragraph is individually addressable and linked to other paragraphs within Discussions, which are possibly circular directed graphs, and are versioned as well.

There is no concept of a "page" or any other form of flat text, except as the wiki client must generate retarded html for a luddite who won't give up their internet explorer; the full glory of the wiki isn't expressible in flat text.

Any paragraph can be timestamped with a Remark tag, so that you can put as many remarks as you want in a discussion, at specific locations within a discussion, and not just a single one like in UseModWiki (the single comment you can put on your edit which will appear on Recent Changes).

These Remarks can be ignored or displayed by wiki clients according to the date they were created. A user can choose to see no Remarks at all.

The RecentChanges is just a normal Discussion containing nothing but timestamped Remarks of when other Discussions were edited/deleted/created. So every user can see just as many days' worth of changes as they want (like UseModWiki), yet the object isn't anything special (unlike UseModWiki) just because it was generated by a script.

Discussions are represented by the wiki client according to a DirectManipulation framework. There do not exist separate modes for viewing and editing such as exist on current wikis.

The ideal wiki has as much security as its users want. Which means that it implements a hard security model based on the principles of capabilities, NameSpaces, separation of powers and cryptography.

Editing, deleting, creating, and rearranging paragraphs are all completely separate operations requiring separate capabilities; it's the wiki UI's job to hide the inherent complexity. A newcomer to the wiki can be given an account that only lets them create new paragraphs and edit their own paragraphs.

Any paragraph can be Signed or Encrypted. The signature is automatically fetched from the appropriate UserName/CryptoBlock? subDiscussion.

Capabilities enable people to create completely private Discussions on the public server, to be shared with only those users you've given a capability to (and that they've given a capability to, and so on in a transitive closure).

This security model enables people to have Discussions which function exactly like today's mailboxes (other people can append to them, but not read them), but within the unifying framework of a wiki. Unlike today's mailboxes they would have the advantage that you could "send" a Discussion to someone while unfinished because you could still edit it afterwards. And of course, every permutation of secure sharing between a private mailbox and a public wiki page would be possible within the ideal wiki.

A discussion can have zero to many names bound to it. Binding a name to a discussion is a power separate from other powers.

The wiki has a compiler (wikis are exactly like programming languages) that tries to bind identifiers [[like so]] to Discussions by crawling up the graph until it finds a Discussion with that name bound to it.

The compiler begins its search at a user's Home Discussion, which generally links upwards to all Public Discussions. Making a Discussion public is as simple as creating a downwards link to Public Discussion.

Making a subgraph of Discussions have their own NameSpace, separate from the public NameSpace, is as simple as denying the compiler the right to traverse up the graph from the chosen point.

The compiler also appends the edit to whichever RecentChanges Discussion it hits by crawling up the subgraph. So you can keep track of Recent Changes in your private NameSpace within your own private Recent Changes Discussion.

Of course, a user may embed a link to another Paragraph or Discussion directly into their own paragraph or discussion, enabling them to sidestep the compiler. The wiki client's DirectManipulation UI permits this.

The wiki is completely integrated with a UniversalCatalog, so that a Discussion could talk about a movie and a link at some point may give you access to that movie. And vice versa, so that when someone finds an object in the Universal Catalog, they immediately see the Discussions which surround it.

Sorry, it's late and that's all I can remember off the top of my head.

[Any name for it?]

Communities.

Re: the name

No - A community is a group of people. Described above is some kind of technology / piece of software. -- ms

Blind people's reliance on flat text.

the full glory of the wiki isn't expressible in flat text

What about the blind? How will they access this info?''

Someone will have to come up with a virtual touch interface system. Hey, what about you?

What are the intended touch differences between displayed components?

See above about Communities being built from a directed graph of paragraphs. How about you just wait till Communities is built before bugging its implementors about your add-on?

The cited "above" is nearly absent of content that would detail the use of virtual touch, unless it means the trivial spacing of versions in a plane, which hardly seems revolutionary, given that its included in nearly every version control system with a GUI

Great! Since you've determined that there is no useful information in the graphical aspect of Communities then that means you can skip making a virtual touch system to interpret the 3D directed graph of objects that sighted people would see. Your job is done, aren't you happy now?

: Touchy, touchy. All that was stated was that the referenced section did not contain enough data to determine your intent.

(I really don't need to explain anything at all. I already specified the interface you're gonna have to deal with; a directed graph of paragraph objects in 3D. What it's for doesn't matter. If you don't want to invent a virtual touch system to represent those objects then that's your business.

: So it's just the positions of the paragraphs in 3D that is the concern? For that you're quibbling over a virtual touch system?
: Hey, feel free to not implement it. Anytime.

Besides, there's plenty of information in the above for an open-minded person to figure out what I'm talking about. Anyone who persists in applying their own preconceptions to a revolutionary system will be incapable of understanding, no matter how much explanation they're given. The particular preconception here is that Discussions are linear.)

: Nonlinear discussions? Newsreaders have handled that since trn/slrn, nearly a decade ago. They didn't have a point&click navigation, of course, but they were text-based. Besides, you are either needlessy complicating things with a 3D graph, or horribly oversimplifying with a 3D graph, depending on the criteria for versioning - it either can be mapped onto 2-space, or it has arbitrarily many coordinates.
: Who said all versions are going to be visible simultaneously? And who said all the objects in the system are going to be shown simultaneously? And if they aren't shown simultaneously, then who cares whether it maps to 3 or N dimensions globally?
: As for newsreaders, I still remember trn. And contrary to your impression, trn did not have non-linear discussions. It didn't even have discussions. It had posts, individual snapshots of discussions. The dinky little map of threads in the corner that let you move from one post to another hardly counts for jack. If any newsreader had ever displayed more than a single post, it would not have been necessary to quote everything you need in every single post.
: If only a subset is shown, then why go to 3D? Why not 2D, and then flat text becomes viable again. Use of 3D just for marketing buzzword compliance is gauche
: And as should be obvious from the use of terms nobody understands, like "text compiler" and "capabilities",, the primary impetus of this project is buzzword compliance. Besides, what the hell are you talking about? Flat text is 1D, not 2D!
: Here's a clue, while a good interface doesn't have to show everything, it does have to show a bit of every single thing. So if it has versions, then it must show at least the last two. It doesn't have to clutter the screen with the 400 versions since the discussion began, but it does have to provide a direct way to access those previous versions. And that would be clicking on the previous version (not a button called "previous version"). So yes, you absolutely need 3D.
: In fact, you need 3D even without versions because interconnected discussions simply cannot be properly displayed in just 2 dimensions. At least, not without shortening the horizon to the point where the interface is absolutely useless. The only reason Usenet could be displayed in 2D is because it's pathologically broken; you can only append new posts. No, wait, you can't display even Usenet in just 2D, no matter how broken it is. You need 1 dimension just for the chain of paragraphs in the post itself, another dimension to display any follow-up paragraphs, and then yet another dimension to differentiate different follow-ups. So that's 3.

CategoryWikiImplementation