
Wiki creator reinvents collaboration, again - mgunes
http://www.infoworld.com/article/2880204/collaboration-software/wiki-creator-reinvents-collaboration-again.html
======
eitland
For the more pragmatic ones you might want to look into Fossil SCM by Dr
Richard Hipp, author of SQLite.

    
    
      * Distributed VCS, tickets and wiki
      * You can link artifacts together
      * Single statically linked binary
      * Works on Linux, Mac and Windows
      * Not dependent on Javascript
      * Easily themeable, looks good (important, this means you 
        can slap in the logo and colors from the company web 
        site and avoid lots of questions.)
      * Easily hackable
    

(That said, I don't think the template system is aiming for any awards in the
near future.)

~~~
lrem
> Works on Linux, Mac and Windows

That's quite some understatement, it freakin' runs on toasters (i.e.
~everywhere where you can run SQLite, the only hard requirement I'm aware of
is there has to be a C compiler for the platform).

------
pjungwir
It seems like almost every project I work on could benefit from a general-
purpose library for storing JSON documents along with a change history,
including the change timestamp and author. Also the ability to merge two
divergent branches and flag merges that need manual attention. I feel like
this has been re-invented again and again. It's a bit like embedding git in
your application---and maybe that's even the best way to go. It would sure be
useful! So I wonder if this Wiki project will have some way to extract just
that bit of functionality. The distributed nature makes me thing probably not,
but who knows?

~~~
robterrell
Check out PouchDB. That's exactly what it's designed for: JSON document
storage with remote synchronization capabilities.

~~~
kolev
Isn't that tightly-coupled with CouchDB though?

~~~
ssutch3
PouchDB uses the CouchDB sync protocol to sync to multiple servers (or other
PouchDB databases). PouchDB is also planning on offering a lightweight server-
side PouchDB that runs in Node.

FWIW any database could potentially implement the CouchDB sync protocol.
[http://dataprotocols.org/couchdb-
replication/](http://dataprotocols.org/couchdb-replication/)

~~~
nolanl
There actually is a PouchDB Node server already:
[https://github.com/pouchdb/pouchdb-
server/](https://github.com/pouchdb/pouchdb-server/). Installing it is as easy
as `npm install -g pouchdb-server`

Also, Drupal recently announced that they're going to offer a CouchDB-
compatible server. So yeah, anybody can implement the sync protocol. :)
[http://wearepropeople.com/blog/a-content-staging-solution-
fo...](http://wearepropeople.com/blog/a-content-staging-solution-for-
drupal-8-and-more)

~~~
kolev
Thanks! How did I miss this?

------
hliyan
I was hoping the next generation of wikis (especially as used by wikipedia)
would introduce an underlying 'fact unit' [1] layer on which articles are
built, effectively separating edit wars from verification wars.

[1] Not the same as a 'knol', which as defined by Google was _not_ a unit. A
real knol would be a single atomic fact.

~~~
AndrewOMartin
Try listing the atomic facts (ignoring, for simplicity's sake, their
underlying facts, or any references to authoritative sources) for the
following statement. As an exercise that may possibly illuminate why that
hasn't happened.

"37 minutes ago hilyan was hoping that the next generation of wikis
(especially as used by wikipedia) would introduce an underlying 'fact unit'
[1] layer on which articles are built, effectively separating edit wars from
verification wars.

[1] Not the same as a 'knol', which as defined by Google was not a unit. A
real knol would be a single atomic fact."

I will interpret a lack of responses as evidence for failure. ;)

~~~
harperlee
This should be compiled to a flat list of facts:

    
    
        (declare hilyan-hope)
        (declare footnote-constraint)
        
        (let [t universal-timestamp]
             (said AndrewOMartin t
                   (status hoping hilyan
                                  (- t (minutes 37))
                                  hilyan-hope))
                   (said google (undefined-past)
                         (let [knol (gensym)]
                              (not (unit knol))))
                   (let [knol (gensym)]
                        (single-atomic-fact knol)))
        
        (def hilyan-hope
             (let [next-wiki-generation (gensym)
                   fact-unit (gensym)
                   article (gensyn)]
                     (introduces next-wiki-generation fact-unit)
                     (underlies next-wiki-generation fact-unit)
                     (footnote-constraint fact-unit)
                     (underlies fact-unit article)
                     (cause fact-unit (separate verification-wars edit-wars))))
        
        (def footnote-constraint [fact-unit]
          (let [knol (gensym)]
               (!= knol fact-unit)))
    

The DSL could be improved :)

Edit: So a couple of things about this exercise: yes, it took me more time
(and space) than your phrase. On the other hand, I specified some extra
information. Some ambiguities about your phrase needed to be explicit, so
that's a win for a more formal language. Also, there's some more effort
involved, so I could have the time to think more about what I say. It would be
great to have an interactive tool to think and write in a more formal
language, even if it is not meant to be compiled to assembler.

I have a side project that touches this tangentially (the code is made up,
though!), but I can't find a lot of time for it :(

Does anybody know if something like this exist? Somethig like a
wiki/REPL/mindmap sandbox for concepts.

~~~
tunesmith
Take a look at Attempto Controlled English.

~~~
sitkack
I need an IDE for this.

------
skimmas
I always have a little weird felling about local storage. I can save stuff on
my computer but I don't know where it is going, so I can't back it up nor can
I keep it if I format the computer.

~~~
couchand
To be clear, the use of local storage in this context is expressly intended to
be temporary, to store a draft locally while editing, then you publish to a
stable server.

But your comments about Local Storage are spot on. Use it as a cache, not a
file system.

------
neovive
Great Project!! The user experience on the page is quite nice--a bit like
Trello crossed with GitHub; turning traditionally static wiki content into
interactive content.

On a related note, I'm curious to hear what others think about the trend of
sending data over-the-wire and rendering HTML on the client. I just started
working with Meteor, coming from a traditional web development background, and
I see major benefits regarding multi-device rendering and real-time updates.
However, I'm still on the fence regarding this paradigm and continue building
new projects with traditional server-side rendering and DOM manipulation.

Playing with federated wiki is very convincing that data over-the-wire is the
future.

~~~
wtbob
> The user experience on the page is quite nice

I wonder if we used the same page. I just got a welcome page. When I input
'patterns' into the search box and hit return, nothing happened. When I
clicked on 'Recent Changes' I see a gray bar reading 'activity,' with no
contents.

It appears to be a broken test site to me.

> On a related note, I'm curious to hear what others think about the trend of
> sending data over-the-wire and rendering HTML on the client.

I think it's evil, given that it requires me to allow code execution in order
to read content.

~~~
edwintorok
Try [http://c2.fed.wiki.org/view/welcome-visitors/view/topic-
base...](http://c2.fed.wiki.org/view/welcome-visitors/view/topic-based-
subsets) It can take a while for the individual pages to load [1], some
progress notification would be nice.

[1]
[https://news.ycombinator.com/item?id=8989943](https://news.ycombinator.com/item?id=8989943)

~~~
wtbob
> Try [http://c2.fed.wiki.org/view/welcome-visitors/view/topic-
> base...](http://c2.fed.wiki.org/view/welcome-visitors/view/topic-based-
> subsets)

Nope, that just results in a vertically-divided blank white page, with the
non-functional dark-grey bar below. It remains blank after minutes.

(This is probably because the wiki doesn't work without JavaScript, making it
useless to anyone use lynx, links, elinks, emacs-w3m or NoScript, which is to
say anyone concerned with security)

~~~
edwintorok
Indeed, doesn't work without Javascript.

~~~
TeMPOraL
Welcome to the future.

Seriously though, C2 people were the last I'd expect to move toward
JavaScript-powered thingies apps, especially when it's uncalled for.

------
chrisdotcode
You can find the previous discussion about this (from last month) here:
[https://news.ycombinator.com/item?id=8983158](https://news.ycombinator.com/item?id=8983158)

------
yaw
The side by side articles reminds me of TiddlyWiki - a self-contained personal
wiki.

It's a feature I would like to see more use of, as the context of a subject is
often spread across multiple pages.

------
esfandia
We've been working on a similar idea for a few years now. We have a
distributed version called P2Pedia: [http://www.nmai.ca/research-
projects/universal-peer-to-peer/...](http://www.nmai.ca/research-
projects/universal-peer-to-peer/p2pedia)

and a centralized version as a Moodle plugin called Social Wiki:
[http://www.nmai.ca/research-projects/socialwiki](http://www.nmai.ca/research-
projects/socialwiki)

You can try out Social Wiki online (there's a link to a demo site on the above
link).

The UI needs work, but I'd say Social Wiki is functional. Just need to install
Moodle first.

------
Terr_
> Wiki creator reinvents collaboration, again [!!!!!!]

[Insert prior-art reference probably involving PARC here]

~~~
SwellJoe
Please do insert prior art reference, if you have one.

As far as I know, no one disputes the creation story of the first wiki as
being by Ward Cunningham.

~~~
Terr_
Mostly it's a knee-jerk reaction that all popoular things are usually just the
tip of a huge iceberg of incremental improvements and other attempts at
virtually the same stuff... But I did find something PARC-related:

[http://dl.acm.org/citation.cfm?id=215706](http://dl.acm.org/citation.cfm?id=215706)

Note the use of collaborative editing of text, and optimistic concurrency
control for local changes.

> As far as I know, no one disputes the creation story of the first wiki as
> being by Ward Cunningham.

Nor that the first Model T Ford was created by Henry Ford :)

------
hga
" _A conventional wiki, says Mike Caulfield, is "a relentless consensus
engine." A federated wiki may eventually yield consensus, but it promotes what
Ward Cunningham calls a chorus of voices._"

~~~
est
wow, I was trying to quote the exact same sentence! It's the key of the whole
article.

~~~
pen2l
I don't see what's wrong with that, though. For the most parts, relentless
consensus (by Wikipedians, who usually are smart folks) is reasonable
information.

~~~
agumonkey
Nothing wrong but maybe Ward Cunningham wants a platform that does not
converge toward consensus too much.

~~~
pen2l
Why is it bad to converge toward consensus? Or rather, consensus from the
scientific community (which more often than not _is_ the wiki-writers).

~~~
pbowyer
In a field with some form of rigorous proof underlying it* converging towards
consensus is good, though I still enjoy reading the outliers (not the cranks,
the ones who could be the next Pauli).

But imagine if you're trying to converge towards consensus about a historical
event. Every historian has their own interpretation and different emphasis.
The facts should be the same for all, but the reading of the event and its
meaning isn't. And for that reason, support for tracking diverging views would
be very useful.

* For various definitions of science

~~~
Turing_Machine
_I still enjoy reading the outliers (not the cranks,_ _the ones who could be
the next Pauli_ _)._

(emphasis added)

Yes. If everything operated on a pure consensus basis, progress would come to
an end.

This doesn't even have to be at the fringe; for decades, just about every
textbook claimed that normal human cells have 24 pairs of chromosomes. The
correct number (or maybe I should say the currently-accepted number) is 23.
This was even stated in textbooks that had accompanying photographs that
clearly showed 23.

Consensus is a useful tool, but it's not infallible, and sometimes it goes
spectacularly wrong.

------
msutherl
There's a bit of late 00's-style chrome junk in the default design – would
love to see this smoothed out.

~~~
aros
Your comment is useless without elaboration.

~~~
msutherl
Do you mean to say that you would like me to elaborate?

