cinode.github.io/index.xml at master · cinode/cinode.github.io · GitHub

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
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Cinode dev blog</title>
    <link>http://example.org/</link>
    <description>Recent content on Cinode dev blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Wed, 27 May 2020 20:54:19 +0200</lastBuildDate>

	<atom:link href="http://example.org/index.xml" rel="self" type="application/rss+xml" />


    <item>
      <title>Cinode goes live</title>
      <link>http://example.org/post/2020-05-27-cinode-goes-live/</link>
      <pubDate>Wed, 27 May 2020 20:54:19 +0200</pubDate>

      <guid>http://example.org/post/2020-05-27-cinode-goes-live/</guid>
      <description>One of the rules I did set in the previous post was to practically test the theory that is forming here. Thus it is high time to make use of what has been said so far before moving forward.
What I have discussed so far can perfectly fit into static web page where every page consists of rarely changing blobs of data. An example of such page is this blog - it&amp;rsquo;s compiled using hugo and the result can easily be served using a simple web server such as apache or nginx.</description>
    </item>

    <item>
      <title>Back to Work</title>
      <link>http://example.org/post/2020-05-20-back-to-work/</link>
      <pubDate>Wed, 20 May 2020 20:54:19 +0200</pubDate>

      <guid>http://example.org/post/2020-05-20-back-to-work/</guid>
      <description>It&amp;rsquo;s been a bit longer than what I thought. My last post ended up with the &amp;lsquo;see you soon&amp;rsquo; phrase&amp;hellip; Well, that&amp;rsquo;s not the &amp;lsquo;soon&amp;rsquo; I usually mean when saying that. Thus here&amp;rsquo;s my apology for whoever could have waited for the new content.
Let&amp;rsquo;s see if I could get back for a bit longer this time ;)
What has happened? Why I did stop? Well, no surprise - &amp;ldquo;usual&amp;rdquo; life stuff, not enough time spent with family, new job, focusing on other things&amp;hellip;</description>
    </item>

    <item>
      <title>We need trees, we need graphs</title>
      <link>http://example.org/post/2016-10-03-we-need-trees-we-need-graphs/</link>
      <pubDate>Mon, 03 Oct 2016 00:00:00 +0000</pubDate>

      <guid>http://example.org/post/2016-10-03-we-need-trees-we-need-graphs/</guid>
      <description>Extending flat blob space Standard CAS system gives us a flat namespace. There&amp;rsquo;s no structure of data nor relationship between blobs. Although this could be enough for some range of applications, better tools to organize data help simplifying apps and sometimes is even necessary to express data access authorization. That&amp;rsquo;s why we have to go beyond a flat structure and build more complex data connections.
A natural improvement is to build a tree - similarly to what happens with files in filesystems.</description>
    </item>

    <item>
      <title>Trust noone</title>
      <link>http://example.org/post/2016-09-27-trust-noone/</link>
      <pubDate>Tue, 27 Sep 2016 00:00:00 +0000</pubDate>

      <guid>http://example.org/post/2016-09-27-trust-noone/</guid>
      <description>Where things went wrong? Let&amp;rsquo;s solve the &amp;ldquo;puzzle&amp;rdquo; from last post, shall we?
The issue was with the trust level. The code basically assumed that the storage layer, being a memory, filessytem or a remote web server, is trustworthy. When the data was read back from datastore, the code didn&amp;rsquo;t check whether it&amp;rsquo;s correct or not. And from the design point of view we know that the data must perfectly match the name of blob we asked for.</description>
    </item>

    <item>
      <title>Encrypt &#39;em all</title>
      <link>http://example.org/post/2016-09-12-encrypt-em-all/</link>
      <pubDate>Mon, 12 Sep 2016 00:00:00 +0000</pubDate>

      <guid>http://example.org/post/2016-09-12-encrypt-em-all/</guid>
      <description>Another step in the implementation journey This time we&amp;rsquo;ll take a look at the implementation of blob encryption layer. Just before we start I give you one puzzle to solve - there&amp;rsquo;s one serious security flow in current implementation. I wonder if you&amp;rsquo;ll be able to spot it. I plan to show and fix it in the next post.
General idea Blob encryption will be another layer of code, separate from the fist one - datastore.</description>
    </item>

    <item>
      <title>Refactoring mistakes</title>
      <link>http://example.org/post/2016-08-08-refactoring-mistakes/</link>
      <pubDate>Mon, 08 Aug 2016 00:00:00 +0000</pubDate>

      <guid>http://example.org/post/2016-08-08-refactoring-mistakes/</guid>
      <description>Mistake? What mistake? So far we&amp;rsquo;ve implemented CAS layer. It already looks pretty nice and has high test coverage. But I made one small mistake there. Athough CAS is currently doing what it&amp;rsquo;s supposed to do, it will have to be extended later to gain a bit of dynamic features. Using CAS name for such extended module would be misleading. That&amp;rsquo;s why it has to be renamed.
I&amp;rsquo;ve chosen datastore for the new name.</description>
    </item>

    <item>
      <title>CAS in action</title>
      <link>http://example.org/post/2016-07-26-cas-in-action/</link>
      <pubDate>Tue, 26 Jul 2016 00:00:00 +0000</pubDate>

      <guid>http://example.org/post/2016-07-26-cas-in-action/</guid>
      <description>Tough decisions Before I jump to description of the code itself, let&amp;rsquo;s first clarify what technology I&amp;rsquo;ll be using to write Cinode prototype. I decided to use golang. I find it rather nice to work with but it also has some thorns here and there. Why would I like to use it then? It turns out to be very practical, especially in the field of network services. Goroutines are just great - no need to think in terms of callbacks anymore, just straight, sequential code.</description>
    </item>

    <item>
      <title>Password please</title>
      <link>http://example.org/post/2016-06-18-password-please/</link>
      <pubDate>Sat, 18 Jun 2016 00:00:00 +0000</pubDate>

      <guid>http://example.org/post/2016-06-18-password-please/</guid>
      <description>Good Keys, bad keys When using encryption, good encryption keys are essential. They must be generated randomly and must contain enough entropy. Otherwise we&amp;rsquo;ll open wide range of attacks on encrypted data. In addition to the key, we also need Initialization Vector (IV) which doesn&amp;rsquo;t necessarily have to be secret, but still it should be either pseudorandom or (in case of some encryption primitives) just unique when used together with the same key (IV is then also called a nonce).</description>
    </item>

    <item>
      <title>Static base</title>
      <link>http://example.org/post/2016-06-11-static-base/</link>
      <pubDate>Sat, 11 Jun 2016 00:00:00 +0000</pubDate>

      <guid>http://example.org/post/2016-06-11-static-base/</guid>
      <description>Let&amp;rsquo;s talk about blobs Computers understand bits, bits form bytes. Bytes can be ordered into sequence: we end up having blocks of data, blobs. We store them in various places. Running program will need some data inside memory, other part of it will be saved on disk. Some data will be downloaded from servers, CPU will keep some blobs inside it&amp;rsquo;s cache. We can put dozens of examples here, but what this shows is that being so fundamental in computer science, proper data blob management is the key to good application environment.</description>
    </item>

    <item>
      <title>Humble beginning</title>
      <link>http://example.org/post/2016-06-02-humble-beginning/</link>
      <pubDate>Thu, 02 Jun 2016 00:00:00 +0000</pubDate>

      <guid>http://example.org/post/2016-06-02-humble-beginning/</guid>
      <description>What? Cinode is an experimental protect, something like a sandbox for ideas. It does/will utilize some crypto technologies to materialize new kind of application environment. As&amp;nbsp;a&amp;nbsp;result of this project, I&amp;rsquo;d like to come up with a&amp;nbsp;pretty good idea on how we could create new set of apps built on top of solid crypto base: secure by default but still relatively easy to create.
This solid crypto base is the major goal here.</description>
    </item>

  </channel>
</rss>