Codev

Codev is a COllaborative DEVelopment environment with command'based user interface,

as an ideal frontend for GNUnet

list of all projects will appear in a floating layer, at the center of the screen, called overview layer

overview layer:

, left panel:

, roots: home directory of current user and other users, plus attached devices

if a directory is read'only and does not have any visible entry, hide it

, project groups: content of roots

, main view:

projects: content of project groups

in a project view, the list of files of a project will be displayed in the left side'bar

opened files will be slightly highlighted

files and directories with names starting with a dot, will be hidden

".cache" directory inside a project is for files we don't want to share or backup

each opened file will have a side'bar at right showing its sections

there we can create new view corresponding to a section

sections with views will be slightly highlighted

text files will be opened in a text editor

directories containing media files, will be opened in a gallery view

files and directories inside a gallery, will be opened in a floating layer

non'local projects, web pages, PDF documents, etc, accessed from links inside the main project,

will be opened in a floating layer

web pages: move caret between visual elements (ignoring structural elements)

actions:

, next/previous word, line, paragraph, section

ask before crossing files

, next/previous section view, opened file

, go to the list of files to open a file view

, go to the list of sections to open a section view

, start and end selection, then copy or cut

, paste

, undo

, navigation: move, search

, selection

, completion

command based user interfaces (using keyboard, voice, gesture) are faster, more convenient and more powerful,

than pointer based user interfaces (using mouse, touch, pen)

pointer based interface seems appealing at first sight, because of its discoverability

but with simple uniform GUI (ie the oposite of what we see in websites),

there is no need for a pointer based user interface

touch interface has an additional problem: interaction at a distance is not possible

touch interface can be useful in some special cases, but it's not good as a general interface

detection of voice commands is a relatively simple process (compared to general speech recognition),

because we only need to match against a relatively small set of commands

a headset with near range microphone can be used, to exclude far away sound sources

also it is better to put battery and transmitter of the headset in a separate unit which can be put in a pocket

this makes the headset lighter and safer

for those who neither can use all their fingers, nor can talk, gesture based (2d) input can be implemented

navigation keys (arrows, page up, page down, home, end, esc), and ctrl/shift/alt based keybindings,

are available by pressing and holding "mod" key

pressing one "mod" key while holding the other one, is equivalent to Super key

to insert punctuations (in insert mode), press "pun"

after entering a punctuation charactor, it automatically returns to normal mode

unless the "pun" key is still pressed, in which case, it will return to normal mode after releasing "pun"

to insert numbers, press and hold "num"

to insert capital letters, press comma then press the letter

to insert an all capital word, press two commas

the following letters will be inserted in capitalized form, until space is pressed

this is how it is implemented:

when comma key is press, keyboard enters the cap mode in which:

, pressing a letter key, sends a "backspace" key, and then the capitalized form of that letter,

and then the cap mode will be canceled

, pressing comma again, sends a "backspace" key, and activates caps mode,

which remains active until space (or enter or mod) is pressed

, pressing any other keys, acts like normal, and cancels the cap mode

Kinesis Advantage 2 keyboard

flaws of version control systems:

, they double the storage (working directory, local repository)

, their design makes it difficult to modify the history

so in practice, the whole history must be kept indefinitely, even if not needed

when we download a project, a pristine copy is kept untouched in ".cache/gnunet/pristine",

and ref links will be created in the working directory, and then we can work on our own branch

after a while when we want to pull and merge changes made in the main branch,

first a three'way diff based on the main branch, pristine, and the working directory will be shown,

then the user will be asked to accept different parts of the diff

to send a pull request to the main branch, first publish the pristine and the working directory,

then send the two addresses to the main developer

the main developer will make a diff based on these two, plus her own working directory

a pull request can be removed by sending a message to the main developer, and unpublishing the two links

changelog can be used to record credits, and at the same time, track backdoors

decentralized internet is already elegantly implemented by GNUnet, but no one is talking about it

compare it with the hype around decentralized transaction systems, aka blockchians or distributed ledgers,

which are inefficient and unscalable

in decentralized transaction systems, we have a P2P network where all nodes store the same ledger,

which can be extended based on permissionless consesus between nodes

distributed ledgers are authenticated by mass collaboration powered by collective self'interests

appropriate incentives that will continue to encourage honest participation in the network,

is a key component of the consensus protocol

anyone can participate in consensus,

though one’s voting power is typically proportional to its possession of network resources,

such as computation power, token wealth, storage space, etc

see "a survey of distributed consensus protocols for blockchain networks"

https://arxiv.org/pdf/1904.04098.pdf

so in decentralized transaction systems:

, every full node has a copy of the ledger (an always growing database)

typical blockchains with their currently limited number of users, are hundreds of gigabytes

now just imagine that expanded on a global scale

also note that, full nodes are necessary if you want private and trustless transactions

using light nodes means we have to trust miners; how is that better than trusting banks

, transactions are slow

, the system is completely isolated from external world

we cannot import external money and assets to the system

a necessary feature, if we really want to replace current monetary system

it's clear that the motivation behind blockchains is not to replace the current corrupted monetary system,

because it's just not capable to do that, by design

its only purpose is to create a side system for criminal activities

an ideal transaction system would be trustless, and avoids having a single point of failure

this doesn't necessarily mean that we have to completely decentralize everything

transactions intrinsically need some centralized parts

trying to decentralize it by force, based on an ideology, leads to hideous creatures like Bitcoin

we need special nodes (let's call them IO nodes):

, to import assets from external world

, to prevent double spending, whithout the need for a complicated consensus mechanism,

hurting efficiency and scalability

tokens contain two fields:

, token type: determining if it's money, or any other kind of asset

, value+hash (for money tokens), or an identifier encoding the physical aspects of an asset

token history file: a file with the token as its name, containing the history of the token

each line has three parts seperated by space:

, timestamp

, a public key made by the owner (at that time),

, signature made by the private pair of the key in the previous line

in the case of the first line, the signature made by the IO node

tokens are produced and signed by IO nodes based on real resources

to prevent a single point of failure, tokens will be signed by multiple IO nodes

each IO node publishes all the issued tokens

for each token, a file will be published, with the token as the file name

the file contains the signature of the latest owner

the signature is made by the owner's public key, not the key in the history file

so IO nodes can't make fake tokens, or double spend a token, without being detected

violations made by IO nodes (double spendings, refusing valid transactions), will be reported,

to remove them from next release of GNUnet

IO nodes do not have any power, they are just there to prevent double spending

you own your tokens signed off by IO nodes and all the previous owners

owners produce a new key for each token and for each IO node

so each IO node will have a different history file for the same token

to steal a token, one has to first hijack all IO nodes,

and then somehow find all the private keys that the last owner used to sign the token with

even if we do not use a post quantum cryptography like NTRU,

breaking all these keys with a quantum computer, would be very expensive

transaction request:

, timestamp

, list of provided tokens (plus a request for changes if needed)

, list of requested asset tokens, or the value requested in exchange, or a contract

, address of the receiver

first a transaction request is sent from sender to the receiver and all IO nodes

then the receiver sends a compatible answer to IO nodes

IO nodes sign the request and answer, and send it back to the sender and receiver

sender and receiver sign off their tokens and send them to the IO nodes

IO nodes send the tokens to their new owners

if any IO node receives the signed off tokens, but does not send them back to their new owners,

they can be reported using the transaction request/answer which has their signature

the more i think, the more i'm convinced that identities capable to have tokens, must be related to real persons

otherwise, criminals can force people (by kidnapping, violance ...) to send their money/assets to anonymous accounts

one can always have different identities hidden from others, but identifiable by IO nodes

taxes, i think, are out of the scope of transaction systems

they must be evaluated according to the kind of job and a lot of other factors (like environmental damage)

nonetheless, because of IO nodes, some kind of surveillance can be implemented,

to prevent criminal activities, without violating privacy of users

voting:

real persons submit a public key in their companies, and then can use their private keys to sign their votes

the complete list of votes will be published by the company, so anyone can check her own vote

and since the total number of voters is known, there is no place for cheating