2023-10-08 Phoebe lessons learned for Oddmu

In 2020, I was very interested in Gemini. I felt that the web was failing me and that swiching back to Gopher might be an answer. I wanted to go back to document oriented hypertext and not use a modern browser that is basically a separate operating system in a box to power applications to incidentally also browse the old web. No, this is backwards, I felt. Browsers were beasts. I was not alone.

Gemini

Gopher

This is what Drew DeVault had to say in The reckless, infinite scope of web browsers:

The reckless, infinite scope of web browsers

I used wget to download all 1,217 of the W3C specifications which
have been published at the time of writing, of which web browsers
need to implement a substantial subset in order to provide a modern
web experience. I ran a word count on all of these specifications.
How complex would you guess the web is?
The total word count of the W3C specification catalogue is 114
million words at the time of writing. If you added the combined word
counts of the C11, C++17, UEFI, USB 3.2, and POSIX specifications,
all 8,754 published RFCs, and the combined word counts of everything
on Wikipedia’s list of longest novels, you would be 12 million words
short of the W3C specifications.2
I conclude that **it is impossible to build a new web browser**. The
complexity of the web is *obscene*.

People rediscovered Gopher and began writing new "Gopher holes". People started thinking about making changes, adding transport layer security (TLS) and MIME types, and more. Gemini was born. It was possible for a single person to write Gemini servers. It was possible for a single person to write Gemini clients. I was all in. I had written an Oddmuse extension that served my pages via Gopher. I wrote another Oddmuse extension that served my pages via Gemini. I developed a Gemini sister-protocol called Titan which allowed me to post pages, too. I wrote a wiki that used Gemini and Titan, called Phoebe. I added virtual hosts. I added a web user interface. I started up The Transjovian Council which was served by Phoebe using Gemini and the web. I added an implementation of the Internet Oracle. I added a MUSH. I added a journaling game. I added an interesting network blocker. I added "Gemini capsule" hosting.

The Transjovian Council

Internet Oracle

It didn't catch on. What did seem to catch on, however, was people editing their own sites, hosting them with software that served static files and nothing more. I think the problem was that I wanted to use protocols that were simpler than the web so that I could build interesting applications. But nobody else wanted to build interesting applications because if you wanted that, why look to Gopher and Gemini in the first place.

When Phoebe started running into out-of-memory errors and I was unable to figure out what caused it, I dediced to end it. Three years later, I was no longer interested. I can still read what other people are writing using Gemini because Lagrange is a beautiful client. But it's also a complex client and I'm never going to write an equivalent client. Perhaps this puts me in the shoes of people that looked at my Perl code. It's weird.

Lagrange

So this is what I learned for Oddµ: The wiki is for single authors first and foremost. All the wiki features like revisions, diffs, histories, recent changes – they only matter if you have enthusiastic collaborators that you don't know and I haven't seen that in a very long time. So that's why Oddµ lacks all those features. Most people aren't going to need them. If you do, you can check the files into git, and people can make their changes there. Have a commit hook trigger a redeployment and the site updates. You can get revisions, diffs, histories and recent changes from git.

And if you're all alone, you can use rsync to keep a local directory tree in sync with the server. Git is optional.

The idea of small groups of people collaborating, a handful of friends, is still a powerful one. For these cases I was prepared to make a single allowance: The URL paths are structured in such a way that you can use a web server acting as reverse proxy to setup authentication and authorization. The web server gets to know the usernames and passwords, and who gets to view and edit and search which subdirectories. None of that is built into Oddmu. All Oddmu does is use directories consistently such that it is possible to set this up.

You need to protect your site on the Internet from vandals and spammers. But if your site is private, if it runs only for your team or your friends or your family or your tilde, then it’s optional. Authentication, authorization, usernames and passwords, Apache as the front-end, its all optional.

​#Oddµ

---

Previously: Oddmuse lessons learned for Oddmu. Next: Recent Changes is back, based on the discussion below.

Oddmuse lessons learned for Oddmu

Recent Changes is back

Comments

I feel like my opinions evolved alongside yours.

You remember Epoch2020. I revitalized CommunityWiki, or so I like to say! Then I moved on to revitalizing the TourBus. Where are they now? Both silent. I now focused on *my* sites. I am known for Mycorrhiza, a wiki engine for many users. But many of the wikis end up having no more than one... My next project, Betula, ended up being single-user, but federated. Seems like this is *the* next model. One could suspect that federation is not needed for bookmarking, but I do end up reposting others' bookmarks, and one other person does so, so maybe it's a good idea after all!

CommunityWiki

Mycorrhiza

Betula

So, being single-user is the trend now.

Gemini. We became enthusiastic about it at around the same time, which is Gemini creation time, and slowly lost interest. It is read-only for me now. Sure, Betula supports saving Gemini links, there is unique content there, no doubt. But WWW is not so bad after all! It's actually pretty good. Much better than Gemini.

Oddµ brought me mixed feelings.

On one hand, it's the end of OddMuse. One of the few pulses of the old Wiki Web. One of the few what I call ‘classic’ wiki engines left. The other being MoinMoin (ver 2 abandoned, ver 3 developed for 12 years) and MediaWiki (too big for me).

OddMuse

MoinMoin

MediaWiki

On the other hand, it's a new project of yours! I always welcome them. And this one is in Go! I use Go too. A fellow Gopher!

On the third hand, calling it a wiki engine is kind far-reaching. Or not? Nobody really knows what a wiki is nowadays. I'm still on my quest to find a definition that would please me. But I'm certain Oddµ is not a classic wiki engine. Markdown!? The whole page naming approach. No recent changes!? Recent changes are so fundamental, how can you be without them!?

– Bouncepaw

Bouncepaw

---

Thank you for sending that email and allowing me to publish it here. I added some links for context so people can find the things mentioned.

You are definitely right with respect to Community Wiki. I guess Emacs Wiki is still alive and it uses Oddmuse so I don't plan on "sun-setting" Oddmuse. I haven't been developing any big new features in a long time and now I just know that for my own projects, I have an alternative.

As for calling Oddmu a wiki: It works like a wiki if you hand out accounts. One could work on automating this, having people register and all that, but then you need to think about all the things that I've been able to avoid: revisions, diffs. Who knows, perhaps there's a solution to be found somewhere. Numbered backup files that expire after 30 days, perhaps? Right now you can look at the source files and the last backup file: A and A~. Currently, there is no diff.

A

A~

Perhaps one could do something like the following: if the code wants to write a backup file, make sure that it doesn't overwrite backup files less than 60 min old. Then add a diff functionality which effectively groups all the edits of an hour. Perhaps that would be enough.

As for changes, a similar solution might be a checkbox for the edit form which is set by default. If set, a new link is added to the "changes.md" file (like the links on index) if doesn't already exist. If it already exists, just move it to the top.

index

I think I want to go back to such "crude" implementations of features because of something I recently read on Ward Cunnigham's page about

Workflows describe productive activities that are well supported but
not enforced by wiki.
We rely on discovered sequences of primitive actions to complete
tasks that might be directly supported by designed features in a
monolithic system. Primitives, cautiously created when needs arise,
are closely aligned with the necessary software operations.
Workflows might start life as a workaround for a missing feature
only to be recognized later to be a versatile solution that does not
require additional user affordance.

I think this is similar to my attempt at sticking with Markdown and HTML for Markup.

Oh, and by the way: As I was looking for the Smallest Federated Wiki link, I stumbled upon @interstar@artoot.xyz's page on SmallestFederatedWiki page which led me to LeavingTheSFW. It has some interested drawbacks of a fancy UI, fancy file format, and so on. The HelloWorld page makes me think that Phil Jones has been thinking about similar things.

SmallestFederatedWiki

LeavingTheSFW

HelloWorld

CardiganBay
is being written partly as a new wiki-engine; one which combines
classic wiki ideas and values with new technologies and internet standards.
Partly as a personal note-taking / PersonalKnowledgeManagement / DigitalGardening
engine which can help capture and organize my ideas. And even help turn them into
actions, or more coherent "products" (such as essays or longer-form pieces of writing).

CardiganBay

Lots of good stuff.

All of this to loop back to features and Recent Changes. I suspect that I hesitated about automatically having Recent Changes is that it immediately adds the need for minor and major changes because small typos and mass changes (global search and replace operations, of which there have been thousands on this wiki in recent days and weeks) shouldn't show up there. That's also why the directory listing is not enough. But if we had a flag that is implicitly off for changes happening from the command line, then that might work.

And this entire idea only works because I decided to create feeds based on lists of links of files. It also reminds me of the very first Recent Changes where the wiki added links to a page but it was up to people to expire old links, or reorder the list. So that's where I'm headed, if anywhere at all.

– Alex

P.S.: Further emails led to Recent Changes is back.

Recent Changes is back