~ilmu/saman

saman/SPECIFICATION -rw-r--r-- 8.7 KiB
32fdcfbfilmu put some notes on model approach wip a month ago
                                                                                
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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
Draft specification
===================

To begin with this should be a sketch of how to approach implementation. With time it can grow.

Name system lattice
-------------------
WARNING: This sketch is oversimplified and needs to be rearranged slightly in order for it to work

    (((((this) is) a) contrived) example)

Here `this` is the top namespace in it there is the name `is` which is also a namespace and so on,
until we resolve then name `contrived` into the template for interpreting `example`.

Now if we had a context such as `(context this is a)` when receiving the data `(contrived example)`
then there is no problem. The context should be the `join` of all the names in the place and there
is a one-to-one correspondence between contexts and places. A join can also be generated on the fly,
to simplify operations graph, then it doesn't have a name so it is identified by the content address.

Places meet in more detailed contexts. Each namespace relates n names, this is done via hashlist so
the structure is a DAG, however, we also have the object-property perspective; where namespaces are
properties and names are objects. Each namespace is also a name (and it is still impossible to break
bipartiteness because we can say content addresses are objects and metadata is properties).

    (define name 0 hash)  ;; the 0 refers to how many holes the frame has; this will be a netstring.

There is only one dynamic namespace which is the top one, it unifies all the loaded contexts yielding
the current environment.

TODO: simplify syntactic expression of this model using the template mechanisms to create organized
      namespaces so that `(((examples like) ((these will start) to make) sense) yo)` the trick is ofc
      purely functional programming but automating the operation graph and interleaving it via some
      effect system should not be impossible; the unstructured approach will serve as base and further
      developments should then be based on risk assessments (meaning totally arbitrary code can happen
      and we will ensure manually that the general guidelines are being respected as we develop the
      web of trust to a sufficient degree that we can kick off the training wheels). In effect this
      comes down to organization of namespaces such as `trusted` so that you can limit which programs
      get to run (with a gradient implicit<->explicit permission from the user and other dimensions of
      analysis).

~~ BOOTSTRAP ~~
The simplest way to start is to make it so that if you get a nested parenthesis then you expect the
thing that comes out of resolving the name (and putting the values into the holes in the frame) to be
a command that can be piped into sh, since you still don't have the frame for the outer values. The
idea is that `... unquote | sh` will happen to whatever you get from resolving innermost parenthesis.

Resolving a parenthesis (name data) comes down to putting the data into the holes, then you have a
token for the transitions in the operation graph, with inner parenthesis the properties should guide
how to resolve the object (so logic programming looks for optimal execution trace before exec) but
we can cheat by just always assuming `sh` and that will be simple for unix hackers to work with.

Another nicety will be (somename shcmd file1 file2 file3) where the shcmd is a template missing three
filenames and the netstrings in the following slots will be put into temporary files for the command.
Flexibility in wiring inputs and outputs is key to convenient metaprogramming. Which is why guix will
be a strategic dependency; first class support for providing arbitrary programs for the environment.

Tala will modify the `sh` assumption into assuming `tala`, that is it will chain menus rather than
commands (which the automatic name resolution will assume at first). These will obviously be put in
different namespaces; which brings us to lisp, clearly we can eval stuff and this would be the core
namespace of saman. To begin with; the logic programming aparatus and garbage collection that is
briefly mentioned in README.

The context is basically a collection of properties that are assumed; the namespaces that are loaded.
All namespaces are properties not all properties are namespaces but all properties are in a namespace.
Properties can do arbitrary things but we try to constrain the arbitrariness by naming them and giving
them thorough definitions.

Strangely enough even though they are all the same these are slightly different things, super OP-graph.


Object-property graphs
----------------------
Depending on how we build them we get different inclusions.

Probability based relations can have different threshold for inclusion.

Functions (simplest example is filters) can turn one type of OP-graph into another (changing premise
for inclusion). They may need to re-contextualize data to change the control flow around the "P".

Logic can derive properties, new logic can become applicable after you have applied function (filter).

The type of the OP-graph determines the properties that can be derived and the side-effects to invoke.

The monotone-ness of the functions is of course complete sophistry but what can you expect from a user?

TODO: relate more closely to datafun model


Operation graph
---------------
This is the control flow of the currently loaded environment. The index of available transitions.

The transitions are derived via logic programming over the environment (the environment is a datalisp
metaprogram, running it gives you an operation graph; i.e. a program). Metaprogramming should be safe
and signal-positive w.r.t. user (i.e. secure). Safety should be proven as far as possible. Security is
w.r.t. reality, so oracle problem.

The operation graph can invoke arbitrary programs as provided by the metaprogram, the metaprogram also
provides compatible data (modulo context specific guarantees) via the places. 


Notes
-----

Objects are hashes. Properties are names. Properties can be related logically and given causality.
That is not completely correct, I suppose objects are just any height 0 cxp (so just netstrings).

In order to associate an object with many properties we use an OP-graph which is itself a property of
the associated data, namely; the adjacencies between elements in the list of objects (hashes) and list
of properties (names / references).

Mostly this involves answering queries from the front end about what kinds of properties it has access
to for the current object being displayed in the interface.

The fundamental TOP-graph (trust object property graph) has trust thresholds associated with
edges, this kind of thing is necessary but still thinking about it, anyway the core trusted definitions
will include the interface property definitions (because you must be able to trust that your interface
is telling you the truth about your data and that no code runs without permission).

The immutable objects are associated mutably with the properties but we try to converge on property
definitions so that we can achieve confluence. Metatheory of progress is clarity. Information sources
which contribute improvenents to clarity somewhat reliably are more trustworthy and therefore treated
with higher priority. For this reason: When convergence happens it can be assumed to be censorship
resistant in the same way as mathematical results. Therefore we can safely (in the societal sense)
rely on anonymity to protect vulnerable parties with interesting perspectives. This motivates peers
to play mixnets; or use broadcasts based on (zk)proofs-of-membership rather than proofs-of-identity.

Privacy must always be considered in relation to the censorship resistance properties because privacy
predicated on a censor broadcast is equivalent to just having the censor (since the private party has
no recourse when censored except to give up anonymity). Due to our aim of achieving confluence we will
depend on common vocabularies and therefore legitimate improvements to definitions will probably be
censorship resistant enough to motivate anonymity (since peers benefit from the information they will
share it with those they trust).

Different representations (of the confluent concepts) are unavoidable for the foreseeable future.
Therefore we must rely on logic and probability theory to make sense of these things. However; in
order for these webs of knowledge to remain convincing, the individual must remain sovereign and
have the benefit of the doubt. That way we continuously reorient the viewpoints to cover different
cases of perspective mismatch (canonical/most trustworthy presentation vs some humans cognition).

Clearly whatever works will be used and therefore we can assume that those who understand will be
able to explain and somehow keep the knowledge alive. Good luck.