8 ms·

Wiki creator reinvents collaboration, again

177 points by mgunes 12y ago

hga 12y ago
"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 12y ago
  wow, I was trying to quote the exact same sentence! It's the key of the whole article.
  - pen2l 12y ago
    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 12y ago
      Nothing wrong but maybe Ward Cunningham wants a platform that does not converge toward consensus too much.
      - pen2l 12y ago
        Why is it bad to converge toward consensus? Or rather, consensus from the scientific community (which more often than not is the wiki-writers).
        agumonkey 12y ago
        Just found that : http://i.imgur.com/rTt5qiP.jpg http://i.imgur.com/rTt5qiP.jpg 'Without deviation from the norm, progress is not possible.' https://www.youtube.com/watch?v=DjMO_ewZxIQ https://www.youtube.com/watch?v=DjMO_ewZxIQ
        pbowyer 12y ago
        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 12y ago
        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.
        Retra 12y ago
        Well, everyone can agree on the facts, and opinions are just facts about what people have said. So consensus can still be reached on what the opinions are.
- misuba 12y ago
  But one of the big reasons wikis are unpopular (with those who aren't already fans) is the chorus of voices. The relentless-consensus part is seen as just a symptom of that larger disease. I guess it's still not clear to me what the real use case is for Federated Wiki.
neovive 12y ago
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.
- slasaus 12y ago
  for Single Page Apps it definitely is. Though I wonder if every website will end up as some sort of (single page) app.
- wtbob 12y ago
  > 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 12y ago
    Try http://c2.fed.wiki.org/view/welcome-visitors/view/topic-based-subsets http://c2.fed.wiki.org/view/welcome-visitors/view/topic-base... 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 12y ago
      > Try http://c2.fed.wiki.org/view/welcome-visitors/view/topic-based-subsets http://c2.fed.wiki.org/view/welcome-visitors/view/topic-base... 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)
skimmas 12y ago
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 12y ago
  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.
- dflock 12y ago
  All browsers, that I know of, treat localstorage as part of your profile and store this inside your home directory somewhere - which is where all your other stuff is, so if you're not backing that up... I can't help you. For example, Chrome stores it here: on Windows: %LocalAppData%\Google\Chrome\User Data\Default\Local Storage on Linux: ~/.config/google-chrome/Default/Local Storage/
hliyan 12y ago
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 12y ago
  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 12y ago
    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.
yaw 12y ago
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.
msutherl 12y ago
There's a bit of late 00's-style chrome junk in the default design – would love to see this smoothed out.
- aros 12y ago
  Your comment is useless without elaboration.
  - msutherl 12y ago
    Do you mean to say that you would like me to elaborate?
pjungwir 12y ago
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 12y ago
  Check out PouchDB. That's exactly what it's designed for: JSON document storage with remote synchronization capabilities.
  - kolev 12y ago
    Isn't that tightly-coupled with CouchDB though?
    - ssutch3 12y ago
      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/
      - kolev 12y ago
        Thanks! This would definitely make it vastly more popular!
      - nolanl 12y ago
        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-for-drupal-8-and-more http://wearepropeople.com/blog/a-content-staging-solution-fo...
Terr_ 12y ago
> Wiki creator reinvents collaboration, again [!!!!!!] [Insert prior-art reference probably involving PARC here]
- SwellJoe 12y ago
  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.
  - agumonkey 12y ago
    The only thing that comes to mind is Douglas Engelbart mother of all demo. It features a collaborative edition of a distributed document. Other than that, it seems Cunningham was the sole soul behind wikis.
  - Terr_ 12y ago
    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 :)
eitland 12y ago
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 12y ago
  > 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).
- thunderbong 12y ago
  This is my favourite VCS. I can carry it on a USB. And it's a complete system, with it's own server, ticketing system, Wiki pages, and a very, very helpful timeline visualization[0]. And the entire program in a single file! [0]http://fossil-scm.org/index.html/timeline?y=ci http://fossil-scm.org/index.html/timeline?y=ci
esfandia 12y ago
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/p2pedia http://www.nmai.ca/research-projects/universal-peer-to-peer/... 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.
chrisdotcode 12y ago
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

177 points by mgunes 12y ago

hga 12y ago

"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 12y ago
wow, I was trying to quote the exact same sentence! It's the key of the whole article.
- pen2l 12y ago
  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 12y ago
    Nothing wrong but maybe Ward Cunningham wants a platform that does not converge toward consensus too much.
    - pen2l 12y ago
      Why is it bad to converge toward consensus? Or rather, consensus from the scientific community (which more often than not is the wiki-writers).
      - agumonkey 12y ago
        Just found that : http://i.imgur.com/rTt5qiP.jpg http://i.imgur.com/rTt5qiP.jpg 'Without deviation from the norm, progress is not possible.' https://www.youtube.com/watch?v=DjMO_ewZxIQ https://www.youtube.com/watch?v=DjMO_ewZxIQ
      - pbowyer 12y ago
        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 12y ago
        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.
        Retra 12y ago
        Well, everyone can agree on the facts, and opinions are just facts about what people have said. So consensus can still be reached on what the opinions are.
misuba 12y ago
But one of the big reasons wikis are unpopular (with those who aren't already fans) is the chorus of voices. The relentless-consensus part is seen as just a symptom of that larger disease. I guess it's still not clear to me what the real use case is for Federated Wiki.

neovive 12y ago

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.

slasaus 12y ago
for Single Page Apps it definitely is. Though I wonder if every website will end up as some sort of (single page) app.
wtbob 12y ago
> 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 12y ago
  Try http://c2.fed.wiki.org/view/welcome-visitors/view/topic-based-subsets http://c2.fed.wiki.org/view/welcome-visitors/view/topic-base... 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 12y ago
    > Try http://c2.fed.wiki.org/view/welcome-visitors/view/topic-based-subsets http://c2.fed.wiki.org/view/welcome-visitors/view/topic-base... 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)

skimmas 12y ago

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 12y ago
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.
dflock 12y ago
All browsers, that I know of, treat localstorage as part of your profile and store this inside your home directory somewhere - which is where all your other stuff is, so if you're not backing that up... I can't help you. For example, Chrome stores it here: on Windows: %LocalAppData%\Google\Chrome\User Data\Default\Local Storage on Linux: ~/.config/google-chrome/Default/Local Storage/

hliyan 12y ago

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 12y ago
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 12y ago
  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.

yaw 12y ago

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.

msutherl 12y ago

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

aros 12y ago
Your comment is useless without elaboration.
- msutherl 12y ago
  Do you mean to say that you would like me to elaborate?

pjungwir 12y ago

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 12y ago
Check out PouchDB. That's exactly what it's designed for: JSON document storage with remote synchronization capabilities.
- kolev 12y ago
  Isn't that tightly-coupled with CouchDB though?
  - ssutch3 12y ago
    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/
    - kolev 12y ago
      Thanks! This would definitely make it vastly more popular!
    - nolanl 12y ago
      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-for-drupal-8-and-more http://wearepropeople.com/blog/a-content-staging-solution-fo...

Terr_ 12y ago

> Wiki creator reinvents collaboration, again [!!!!!!] [Insert prior-art reference probably involving PARC here]

SwellJoe 12y ago
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.
- agumonkey 12y ago
  The only thing that comes to mind is Douglas Engelbart mother of all demo. It features a collaborative edition of a distributed document. Other than that, it seems Cunningham was the sole soul behind wikis.
- Terr_ 12y ago
  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 :)

eitland 12y ago

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 12y ago
> 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).
thunderbong 12y ago
This is my favourite VCS. I can carry it on a USB. And it's a complete system, with it's own server, ticketing system, Wiki pages, and a very, very helpful timeline visualization[0]. And the entire program in a single file! [0]http://fossil-scm.org/index.html/timeline?y=ci http://fossil-scm.org/index.html/timeline?y=ci

esfandia 12y ago

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/p2pedia http://www.nmai.ca/research-projects/universal-peer-to-peer/... 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.

chrisdotcode 12y ago

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