diff options
Diffstat (limited to 'news')
| -rw-r--r-- | news/1692781795-it_has_been_a_while_since_the_last_newsletter | 75 |
1 files changed, 75 insertions, 0 deletions
diff --git a/news/1692781795-it_has_been_a_while_since_the_last_newsletter b/news/1692781795-it_has_been_a_while_since_the_last_newsletter new file mode 100644 index 0000000..97963b6 --- /dev/null +++ b/news/1692781795-it_has_been_a_while_since_the_last_newsletter @@ -0,0 +1,75 @@ +It has been a while since the last newsletter +============================================= + +Well, hi again! + +It is indeed a while. To be honest I am mostly unsure about when the last +newsletter occure. Data suggest it's only since June but whatever. + +Maybe it's the urgent feeling to get the word out. + +So! There are some heavy updates! + +I am looking for a job recently and since I am not required to daily work for +someone else, I take the opportunity to focus on Arching Kaos project. + +There are many things that appear to have been done in a quick'n'dirty manner. +I know, I know... But investing these hours between working for others got me +here so far. I have spend years developing this project, evolving my +understanding on fields that come up while solving the problem that Arching +Kaos is intented to solve. + +Indeed this space, got me the time to see and retrospect on the current state of +the project and also got me able to solidify which is the problem that it wants +to solve, how it actively solves it and how the project could proceed in the +future. + +So, we have 3 questions: + +Which problem it solves? + - It solves the problem of digital contribution and distribution. + +How it does that? + - It uses IPFS (a distributed filesystem) to publish and exchange data. + - Contributors make a personal blockchain with arching-kaos-tools. + - Contributors have the following information: + 1. their GPG key, + 2. their blockchain, + 3. their IPNS key for publishing their blockchain, + 4. their IPNS key for publishing the above information, + 5. optional data that they can "attach" to the above mentioned key (4) + Ultimately, the key mentioned in (4) essentially acts as an ID. + - This ID (or the keys mentioned in it) can be published for others to see. + +Where is this heading to? + - Reaching stability of the underlying scripts and programs is always a goal, + - Installation can be more inclusive to other Linux distros, + - The API should be enhanced, + - CJDNS might be a requirement in the near future as the API develops, + - Further expansion with python-cjdns-peering-tools, + - Possibly, a lightweight python admin panel for GUI, + - Further development on the web-ui and adaptation of routes of the API, + - Research for the SCHAIN part of things if needed, + - Right now, probably to ROADMAP in order to start getting things done + +However, all the above raise the question: + +Are there any assumptions? + - We assume that information is handed to the public as is. + - Everyone is free to replicate and redistribute either as is or modified. + +After all, both assumptions are based on the fact that you can manage to copy +even firmware. The assumption is not taking sides on e.g. piracy but it inherits +naturally the environment that it is created in. + +Furthermore, knowing each others keys, contributors can choose to encrypt data +for a specific contributor they want. Even while the nodes can know where the +data is, or even to whom they are sent to, the underlying message is encrypted. + +Reaching this point, I 'd say that there are plenty of things that are going to +take place in the near future. + +Watch out for a ROADMAP update soon! + +Cheers, +Kaotisk Hund |