1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
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
|
