Come back, c2.com, we still need you
wiki.c2.com
wiki.c2.com
Anecdotes: Ward (My dad) and I recently moved c2 off a server in a colo where it had lived for over a decade because the colo was closing. Now it lives in a cloud provider. It will live on. Eventually I envision It will get moved like the Agile Manifesto to a static site for long lived prosperity as a relic of the early internet.
I owe Ward stuff.
I'm linking to a bit earlier in time because on web.archive.org every hyperlink takes you a bit further to the future, eventually (sometime in 2016) ending up on a redirect to the JS version.
Edit: Here is a mirror that is now functional again: https://kidneybone.com/c2/wiki/WelcomeVisitors. In particular, it has a working search page: https://kidneybone.com/c2/wiki/FindPage
See https://news.ycombinator.com/item?id=35952055 if you want to create your own mirror.
https://www.w3.org/Provider/Style/URI
If you simply must redesign a site, make sure all the existing URLs still work and take someone visiting to the same equivalent in your new site.
If you're going to drop a site before its redesign is ready... what the hell are you doing?
looking at you, vmware
Right now I'm focusing on simple, automated link checking in a closed free alpha with a few users, but the killer feature I want to implement by the end of this month is notifying users if they redesign their website and forget to set redirects to old content. [1]
I would love to have more alpha testers, and the plan is to make it available for free to open-source projects and documentation sites, like c2.com. If you join the waitlist, I'll let you straight in.
--
1: I am redoing my personal website, trying different static generators, and I cringe at the thought that I am completely unaware if I break someone's bookmarks, or the RSS feed URL changes and I lose the couple followers I have. Bernard exists first and foremost to solve this problem for me, and I hope it might be useful to others that care about this issue.
Here's a copy of the entirety of C2 from https://archive.org/details/c2.com-wiki_201501
And an implementation of a server to run it (search indexing and such) https://github.com/adamnew123456/wiki-server
It is like being able to go back and be a fly on the wall in https://en.wikipedia.org/wiki/Bohr–Einstein_debates# for physics (one can debate about the degree of significance of the topics and individuals - but I'm trying to get back a "this is where things where happening at the time.")
As an aside, there was a community-fork of c2 where part of the community was more interested in communities rather than code. That site is still available - http://meatballwiki.org/wiki/ ( http://meatballwiki.org/wiki/MeatballBackgrounder ) which has a lot of the same charm as c2.
The thing with other great debates - there aren't any transcripts of them. C2 is the best that we have of the early "trying to figure out is now called agile".
if ($word =~ m/[:upper:]+[:lower:]+([:upper:]+[:lower:]+)+/) {
$word = "<a href=\"${somePrefix}${word}\">${word}</a>"
}
or something to that effect.Wdym
So, you limit the text that user generated content is allowed to use. And yet, you still need to figure out a way to allow links between pages within the site - but not allow the person to use an <a> tag.
The way c2 did it was with MixedCaseWords that were easy for a regex to pick out and create link targets to.
MixedCaseWords required no additional special characters to be used or worry about unmatched character pairs.
[[[a link] with some more text and [[something else]]
Getting into parsing means more complex code and with that complexity comes for the possibility of bugs.This was also at the time of the Cambrian explosion of Web 2.0 and user content. Lots of different sites took different approaches to handling it. The CamelCase link approach reads kind of clunky but is likely elegantly simple in implementation.
C2 was from the very early days and something that works, well, it works. Going to a full on sanitizer and larger set of allowed html leads forever chasing bugs and implementing features.
Compare also HN and the rather limited feature set. It is better to have something that works and move on rather than forever implementing features (often with backwards compatibility breaking cases).
It’s a small world. The more you know.
Also I have enjoyed listening to people complain about our [[creation]] for decades.
We had reasons. We already had clean syntax for [https://uri text description] and [https://uri] for numbered citations as footnotes and [#anchor] for named anchors that fit this format of square brackets for everything.
The double square brackets made it clear the inner tokens were not to be parsed at all but were the link itself. Plus they are fast to type and very easy to identify (they look like a [[button]]) and read cleanly as part of a sentence.
<noscript>
<center>
<b>notice</b>
<p>javascript required to view this site</p>
<b>why</b>
<p>measured improvement in server performance</p>
<p>awesome incremental search</p>
</center>
</noscript>They're not exclusive, smaller server loads doesn't mean the experience is better for the client.
For instance the server might just stop doing server-side template rendering. Instead it sends one static page, then the client requests and render the JSON for the article, or maybe the page only contains the JSON for the article instead of the rendered one.
Then the template rendering cost stops showing up on the server, because it's not performed on the client, and serialising to JSON is almost certainly cheaper than rendering an ad-hoc and half-assed template format.
But now the client has to perform a bunch of extra requests (to fetch the javascript and possibly the json) and it pays the cost for the template rendering, and that might be even halfer-assed, and more expensive, because it's out of sight of the server loads / logs.
The result is that the server has gone from, say, 80ms CPU to 40ms CPU per page (which definitely qualifies as a "measured improvement in server performance"), but the client now needs an additional 300ms to reach loading completion.
Depends on your definition of rightfully. This is a ad-free, cost-free website. If they want to reduce server load or prioritize something other than non-JS experience, it’s their prerogative.
Especially when the complaint is “it’s slower on my client” and not “I can no longer access the data without JavaScript”
> Worse, they essentially get taunted.
Please explain?
Accessibility isn't any more of a problem than it is with HTML. For screen readers, et al it's still something that needs to be deliberately incorporated into the document structure, and modern frameworks are more than capable of handling it. What about older browsers with crappy JS implementations? Front-end frameworks have tools designed to extend support to much older browsers with limited JS support. The percentage of people who have access to a web browser but can't use javascript applications is vanishingly small. When I've worked with people making publicly-funded tools for which accessibility must accommodate people with very limited technical means-- unhoused people, for example-- developers tend to skip the web interface altogether and go with SMS combined with telephone or in-person service. JS is not the barrier.
Obviously that 50MB binary is hyperbole, but the baseline Vue include is 16k. It's certainly easier to make make front-end JS heavy and unreliable than plain static HTML, but it's pretty easy to avoid it, and design that poor would probably fuck up plain-old HTML and CSS just as bad. The fact is that most users do appreciate the dynamic features and responsiveness that is only possible with js. If you don't, and want to exclude yourself from modern web functionality, then be my guest. I think it's pretty strange that you'd expect other people to go out of their way to accommodate your rather uncommon preferences to make an experience most users consider worse and doesn't work towards satisfying any tangible business needs.
I didn't. I said that accessibility is no more of a problem for js-fueled pages than HTML pages, which was not always true.
> Dont even bother telling me that this use case is no longer supported
Then don't say people are making websites wrong when by common practice you're using the wrong tools to interact with them.
> I know that. That doesn't change my technical opinion that JS is way too much of a gun for documents.
Like I said, feel free to opt out of the modern internet. It's your life. It's just flatly absurd to be in your position and accuse developers of having poor practices when they provide an objectively better experience for probably 9999 out of 10000 other users by using widely accepted, standard, reliable practices that often require less development time.
I can’t count the number of SPAs that manage to break basic browser functionality like links, back/forward navigation and scrolling. It’s insane.
No. Not without knowing the use case, the requirements, the users, and all of that. Sometimes I don't need anything beyond a text editor for something I make. Use the right tool for the job.
> I can’t count the number of SPAs that manage to break basic browser functionality like links, back/forward navigation and scrolling. It’s insane.
Yes. With more powerful tools you can fuck more things up, more thoroughly than with less powerful tools. That's not a problem with tools, that's a problem with bad development and design. Assuming that the person who fucked it up that badly would have made a better experience with less powerful tools is almost certainly wrong.
Have a nice day, and enjoy your eye-sight.
I still think it's ridiculous to say that developers are doing something wrong by using modern practices just because it doesn't fit your use case. You can have your opinion all you want to and I can have my opinion about it.
Of course, some people might want additional functionality, and to facilitate that functionality, we have many technological tools at our disposal which make the process of implementing that functionality simpler than not using them. What you deem to be simple enough without being too simple is based on your use case and preferences.
I mostly browse sites with JS disabled (with lots of exceptions of course) to get rid of those awful Euro cookie banners. Are those required in US now for some reason? My browser doesn't save the cookie that says they can save cookies, so they constantly prompt me.
Almost all modern browser compromise is via JS.
Much easier to do that supporting both HTTP and JS for both read and write.
It is an interesting change, to a more federated style.
I ended up doing a small project inspired by this change, at https://github.com/dexen/tlb
Though... that particular implementation seems to not handle unwinding the stack very well. And as the classic web2 adage goes, if you think your animation is "just right", knock another 3rd off it at least.
[1] https://tiddlywiki.com/ (haven’t looked at the homepage in years, the current one seems kind of awful and not really bite-sized unfortunately).
It seems empty. Or am I not grasping what this is?
Linking to a specific topic.
Archiving the site.
Do they not know back button and tabs exist in browsers ?
what does "federated" mean in this context? do you mean decentralized segmented "peer to peer" storage, or something?
unfederated wikipedia is not helpful in defining federated:
Federated content is digital media content that is designed to be self-managing to support reporting and rights management in a peer-to-peer (P2P) network. Ex: Audio stored in a digital rights management (DRM) file format. https://en.wikipedia.org/wiki/Federated_content
The idea is essentially to follow the way email (and partly the Web) works: users aren’t tied to one server (centralized), but neither are they required to each run their own one (peer-to-peer), instead there’s a narrower group of server operators who host users, but those users can cause the server software to connect to a server it doesn’t know about if they mention it explicitly.
Of course, if the protocol is too weak in allowing the operator to control those connections (in either direction), it will evolve informal means for that which will make all but the largest servers extremely unreliable, much as email did. On the other hand, the experience of Mastodon shows the dangers of operators exercising too much control (where e.g. Mozilla seems eager to defederate with any server that has anyone post anything even slightly offensive or objectionable to anybody whose opinion Mozilla considers valid).
The federated wiki idea as promoted by Ward seems to be to have the federation (network of servers) be able to browse each other’s pages—so far so Web—but then to allow each user to clone and edit any page anywhere, storing the clone on their own server. The original page isn’t affected, except I think there’s a provision for some sort of backlinking (referral spam? what’s that?). It doesn’t sound unreasonable, but I’m not sure it can support anything interesting either—for a large pool of collaborators you’d need a Torvalds-like full-time merge BDFL, and I haven’t even seen a discussion of pull requests or anything similar.
Links to the JSON-formatted pages (thanks, fellow HNers!) don't seem to work either:
https://c2.com/wiki/remodel/pages/EgolessProgramming
https://proxy.c2.com/wiki/remodel/pages/
I really love(..d?) the "stream of consciousness" nature of the c2 discussions. It is easily among the greatest intellectual rabbit holes of oldschool internet. The extremely minimal, kind of robust formatting probably also contributed to why it was such a compelling read at times. Content over form, for sure.
The C2 wiki is on of the foundational relics of the old web that need to be preserved for the future.
I picked an arbitrary older date and it seems to be working for me (pre-redesign).
Before the C2 WikiWikiWeb, few web sites had experimented with making it possible for its users to alter the site's contents. Granted, there were many sites with messaging forums you could post to, and there were places where you could add review or contribute new content entries, but not anything I can remember where you could edit the fabric of the site itself. Sites back then were 'published' by someone who owned them, and any contributions would go through a moderation process before they would be accepted and published, so there was no immediacy to such edits.
The C2 wiki wiki web allowed any user to immediately make an edit or create a new page, and it the site relied upon its persistent history to roll back changes that the community deemed destructive. I remember feeling quite excited by the concept because it was so alien at the time -- that someone was willing to allow anonymous users to put stuff on a site they were ultimately publishing.
The C2 WikiWikiWeb experiment is what ultimately lead to the creation of Wikipedia: an encyclopaedia that could be edited by the end users, hence the name. (In turn, the WikiWikiWeb was named from the Hawaiian word 'wikiwiki' meaning 'quick', which alluded to the lack of any moderation steps in its edits.)
https://everything2.com/title/Everything+Engine
Aside from E2, it is likely that PerlMonks is the other still active site - https://www.perlmonks.org ( https://en.wikipedia.org/wiki/PerlMonks )
The others seem to have fallen into disrepair if they are still up at all.
https://en.m.wikipedia.org/wiki/Interpedia
I remember participating in the discussion.
<center>
<b>notice</b>
<p>javascript required to view this site</p>
<b>why</b>
<p>measured improvement in server performance</p>
<p>awesome incremental search</p>
</center>
It does load faster now that it doesn't display anything.FWIW, the snapshot of c2 that this runs off of is somewhat dated (https://archive.org/details/c2.com-wiki_201501), so the last ~7 years of updates after the move to the federated wiki aren't present.
Does anyone know where these original pages ended up in fedwiki after the migration?
For those reading the comments here, https://kidneybone.com/c2/wiki/CategoryCategory is a great place to start browsing.
I'm more upset with the new design choices than the architecture choice. The old site was ugly in a retro-cool way. The new site is just ugly.
page does not existC2 was a utopian vision of well-informed, kind, co-operative people working together in a radically open and egalitarian way. And it really did work, for a while. Unfortunately, the reasons why C2 ultimately died have been obscured by a well-meaning process of pruning that I think is meant to remove the "bad stuff" and leave only the "good stuff" for posterity. This is a shame, because the truth really is instructive - a few very prolific, toxic, borderline delusional people started dominating the wiki to the extent that more reasonable contributors just moved on. The C2 community started with an assumption that everyone could be reasoned with, and tried to handle the situation kindly and rationally. It was amazing to see the damage a very small number of people - basically just two - could do to a whole community of hundreds of well-meaning but naive people. It got to the point where there were pages dedicated to trying to think about the problems these people posed, with endless discussions about the paradox of tolerance and handling things through openness and kindness, and small factions arguing for permanent bans. Ultimately I think both badd actors _were_ banned, but by then it was too late - all the air was sucked out of the community. Watching the death of C2 unfold really darkened my view about the prospects of truly open societies, and deeply informed work that I've done on building communities since.
Today, nearly all signs of the way this devastation played out have been erased from history. If you search for the names of the malignant characters there are a few mentions here and there, but there's no way to piece together the true sequence of events. I think an important part of C2's story, and one that is more relevant today than ever, has been lost as a consequence. I'm sure Ward has the full edit history of the wiki around, and I think he should publish it, complete and unvarnished, so we can study it and learn from it.
What an abomination. JavaScript is ruining the internet.
You might find http://wiki.c2.com/?WelcomeVisitors a good place to start if you are curious.
https://en.m.wikipedia.org/wiki/WikiWikiWeb
Has a bit of a focus on coding, with pages/discussions for various programming patterns and terms, like:
Collaborative editing: With the GPT backend, you can allow visitors to temporarily rewrite the wiki page to their liking. This enables collaborative editing, where multiple users can contribute and modify the content while ensuring a history of changes is maintained.
Intelligent refutation: You mentioned the ability to issue a disagreement and instruct the system to refute the previous content. By integrating GPT, you can prompt it to generate counter-arguments or provide alternative perspectives to foster a balanced discussion.
Personalization and anticipation: Over time, the GPT backend can learn from user interactions and get to know individuals personally. This can enable it to anticipate their preferences, interests, or even the types of content they are likely to contribute. Such personalization can enhance the user experience.
Aesthetic improvements: You can instruct the GPT backend to optimize or rewrite its own code to make the wiki front end more aesthetically pleasant. This may involve generating CSS styles, layout modifications, or even interactive design elements based on user preferences.
Intelligent linking: By leveraging the GPT backend's language generation capabilities, you can automate the process of hyperlinking important terms, concepts, or keywords in the wiki content. The system can identify relevant sources, explanations, or further reading materials and dynamically add hyperlinks for easy access to additional information.
Every c2 link I have ever followed was just an incoherent blob of text arguing with itself.
The TvTropes of the programming community, and just as much of a waste of time too.
That's exactly why I find it valuable. Little to no pretense of looking good and a bunch of perspectives in little space. An occasionally useful starting point to get the lay of the land.
Kinda like HackerNews but from before someone invented modern threading and quoting, yeah?
Not sure what you were expecting, but that was very much what some of us were looking for.