zet

KEG Considerations Combined with Zettelkasten

Since discovery and adoption of the ZK knowledge repo approach I have little motivation to finish out the rest of KEG. GitHub is already the world’s leading exchange of open source code and will soon be the same for open knowledge content for all the right reasons. Managing knowledge as source has always been intuitive to those who critical matter in the promotion of this medium. It will only continue. For better or worse, GitHub is already established in that space and motivated to always allow users to see content hosted there.

So where does that leave KEG?

KEG has always been about content and never the transport. If anything, promoting Git for that remains key and consistent.

The local caching of content and subbing to content creators, however, is something that needs serious reconsideration. It is what allowed the control of a personal search engine optimized based on criteria that the individual decides. This very much must remain a priority. Perhaps it could take a much different form. Perhaps it is more fully dependent on Git and just uses Git with its many supported transports. Ironically, we considered that approach in 2016 and even called it git.net at one point.

The idea of being able to locally search everything from a PWA cache was always untested. It’s quite possible a better approach would be an actual collection of repos from which an individual could pull based on what they wish to search. Hell, if all the repos are on GitHub then the search scaffolding is already written and works with the API. A search could just be run against multiple repos in a local list. The centralization on GitHub is directly against the goals of the project.

This is where the practical needs of the moment tend to outweigh the principles of the future. I don’t like it, but I need to use it and get shit done. At least it’s not fucking Google.