Added 1692781795-it_has_been_a_while_since_the_last_newsletter with It has been a while since the last newsletter

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