An attempt to minimize the bloatness of the repository
------------------------------------------------------

Hi and happy new year!

I tend to think that the repo is getting bloated and unorganized as the time
passes.

Modules, utilities, HTTP API (which is also not complete), new attempts and
experiments. To draw a picture: commited changes are mostly things that are
already known to work in one way or another, while my working directory has
a lot new files, test files and I keep resetting or rebasing my local zchain
to do tests. Nevermind though, that's local mess.

You might noticed that I don't do releases for arching-kaos-tools or for
arching-kaos-web-ui. The reason to that is breaking changes that happen during
development. That's not ideal for someone else to use in a production
environment (imagine that, lol).

I put an effort to make things work in no problem with what is already working.
Still, if you do want to try a blockchain-based content diary, you can! Now,
a thing that pops up in my mind is compatibility. While I do use and write this
in a Linux environment, users of other OSes should not feel excluded at all.
The reason is very simple: Virtual Machines! You can always install some Virtual
Machine host on your OS and install a minimal distribution of Linux in there.
You might even like it, but besides that, you 'll get to try arching-kaos-tools
and the rest of wonderful options of Linux that arching-kaos takes advantage of.

However, tools need to be organized as well for this to be as easy as it gets.
Hence, akcli (or ak-cli) is going to be introduced in the not so far future.
This would provide one main entry to handle all kinds of tasks that relate to
arching-kaos, be it looking at the zchain, mining for the schain (upcoming
feature), put new content on your zchain or transfer coins (upcoming feature) to
others.

Moreover, to enhance security and encourage privacy, confidentiality and trust,
modules for encrypted zblocks are about to be developed as well. In that sense,
you could create a zblock that only the people that you want to read this, could
do so.

Reminding here that all the zchain and schain activity *IS* public but in cases
like "we gonna have pizza tonight, come" the privacy should be top priority.

Other things that need to be thought of is the way transactions are getting
verified, packed, published etc. Also, prototype of the miner is rewarding coins
but there is no verified way of using these for now, since you can post
transactions in your zchain, without having been credited the spend amount.
Of course, since there is no active mining activity and no active users, that's
okay for now, but needed in the future.

So the hardest part right now is jumping from personal consistency to shared.
Since the adoption of the idea of schain (a blockchain that includes all the
zchains it can "hear" about), the zchain consistency, has become vital for the
project. Thinks are looked after more carefully and are slowly getting better
towards that direction.

In an example, if I would delete my local zchain, while having it published in
schain, I would need to redownload my zchain and continue appending that one.
For that reason, new modules should be introduced, like:

- forget: would signal the original contributor wants the post forgotten,
- ignore: would signal the OP wants to ignore a certain zblock,
- patch:  would signal the OP wants to patch a certain zblock.

In the end, patch is the most ideal cause you supposingly apply a delete all
lines patch to your prefered and *owned* zblock.

Another point of interest is including a renderer script in zblocks instead of
module/action but also this can be proven dangerous if the scripts included are
malware. Which raises again the confidentiality and trust factors. To do this,
a signature is needed to be valid for the script and the key that signs it needs
to be signed by someone that is known to already contribute to the project.

Which brings up the next upcoming thing: public discussion! Think of it as a
forum or like a mailing-list. There is also a repository that someone could
raise an issue and discuss about new features at:
https://github.com/arching-kaos/arching-kaos-improvement-proposals

To port this into arching-kaos, a new module could be developed, you can post
your new proposal or read others' or reply on some proposal.

Which brings us to the next wagon on this running train of thought: a
generalized way to develop modules and -in full circle- provide the scripts for
the zblocks. :P

So, yeap! A ton of things that I need to figure out, test and develop in order
to be ready for the schain solution.

To summarize:
- API needs to be finished
- akcli needs to be finished
- patch module needs to be developed
- research for debasing ak-ipfs wrappers from IPFS
- transaction verify from schain state
- transaction/add modify to acknowledge schain state
- maintainance of all the modules available in repository
- networking (not mentioned in this article)
- mailing-like-lists module
- akip module for future
- research on signing gpg keys and how we could share these signatures
- module example (dumb module that explains what a module should be doing)

No idea when all these are going to be ready, you can buy me time by donations.

No need to be a stranger, join irc.arching-kaos.net at #arching-kaos and speak
up your mind for all this non sense :D

cya

### References
- https://news.arching-kaos.net/?from_block=QmZM1FaNHodm6RZ9TjFAyo7PXTHq6usCFhjf3De8jXeAdd
- https://news.arching-kaos.net/?from_block=Qmc7LAmJNPXxAJZhQfwziKqQJTXL4VAVCc9n7bJQpdi8t3