In 2021, I'm going to dedicate a significant portion of my free time on open source projects, and I want to complete at least 3 projects.
I want to release v1.0.0 of Krohnkite in 2021. I really want to stablize the codebase with proper feature set, so that I can move onto something else.
Most notable changes from users' perspective should be file-based configuration and Wayland support. It'll also update Shortcut names, which will break existing user setups, but, hey, this is a major release for a reason.
Internally, there are lots of homeworks:
Proper modularization using JS import/export and minAMD.
Krohnkite currently relies on Typescript's --outFile option, but this
turned out to be a bad decision as a JS project.
Use yarn-based build.
I have relied on typescript package in Arch Linux, but Arch is a rolling
release, and I have had some incompat issue w/ older tscs. It should be
better to freeze Typescript version, and upgrade it only when necessary.
Poperly support multi-backend.
While designing Krohnkite, I put a separate backend layer to abstract out underlying APIs, so that I can run it on multiple environments. Personally, I want to be able to run Krohnkite on the web, mainly for demo. While this simply sounds like mere "cool thing to do", once this gets possible, it will be possible to run Krohnkite on other DEs or even independently using proper wrappers.
Flatten backend interface
Currently, a backend is supposed to provide several types of objects, just like usual OOP design. In terms of logic, this isn't much of a problem, but it quickly became untrackable who does what on which, making it difficult to reason with API and predict what's going on. implement new backend. This needs to be simplified.
I want to complete IM2020, my personal toy design for the next generation federated SNS. I actually started working on this in early 2020, but had to stop because of personal reasons.
It's going to outline the communication scheme required to acheieve SNS-like user experience in the network of weakly-coupled (or federated) services. There already is a working protocol called ActivityPub, but I couldn't like its committee-driven, heavily OOP, tightly integrated design.
There are a few key points in the design:
Message Passing - I believe that every type of communication can be reduced to simple message passing. No fancy types, but simple Message with extra data in programmable format.
Protocol Agnostic - The messaging scheme itself must not assume on-wire protocols, while allowing per-implementation optimizations. The goal is achieving end-to-end UX, not specifying technical details.
However, I still have to implement it somehow for the sake of verification and technical demo. It's just that the main goal is designing the scheme, and that technical specs are not a concern yet.
Resource-driven - A message is just a chunk of data that does nothing on its own. Its meaning (and validity) only matters to receiver,
At the end of the day, it should be able to completely abstract existing SNS services including Twitter, Facebook, Reddit, old-style BBS, mailing list, and email. Not just read/write messages, but also various interactions (like, up-/down-vote, reaction, etc) and grouping, etc.
I'm thinking of creating a markdown alternative, something sits b/w MD and RTF in terms of feature set. The goal is to create an open rich-text document format, that can be easily integrated into applications.
In the most ideal case, I want to be able to
Another protocol scheme design.
Online shoping data ---> public social data ---> social standard for making transactions (browse, search & discover, checkout negotiation).
This requires more social engineering than programming...
Payment can be PITA to work with.
Not a "desktop" UI toolkit, but a different type of UI. This is for prompt-driven desktop environment, which is one of my long-term goals.
Minimalistic - Only supports rectangle and text.
Decouple UI state from renderer, to allow seamless remote access.
Application ---> [ Library ---> ContextD ---> Renderer ] ---> Display