Contributing

1 Rho account

If you want to be a part of this project, sign up on Rho with a fake email, login, select the rho/wallet or rho/rhomessaged repository, select issues and discuss your proposed work. Ensure that git signing works as described below, create a fork of the project that you intend to contribute to under your account on Rho, and submit your fork for a pull. If it is good, you will likely get rights to push directly eventually.

2 Signing code

2.1 ssh keys

Assuming you are creating the repository in ~/src, and you already have a ~/.ssh directory, which if on linux must have the correct permissions. And assuming your pseudonym that you will be using is «MyName», and the fake email that you will register at Rho is «myname@example.com»

You create the ssh private and public key «MyName» and «MyName».pub

You create or add to the config file, ~/.ssh/config that tells ssh to use the keyfile ~/ssh/«MyName» to sign in on Rho with this identity file when contacting Rho as user gitea.

cd .ssh
ssh-keygen -t ed25519 -f  «MyName» -C ""
# the option -C "" avoids the information leak of inserting your hostname
nano config
cat config

Your terminal now looks something like this:

:~# adduser «MyName»
:~$ cd .ssh
~/.ssh$ ssh-keygen -t ed25519 -f  «MyName» -C ""
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in «MyName»
:~/.ssh$ nano/config
:~/.ssh cat config
Host gitea.rho.la
        User gitea
        IdentityFile ~/.ssh/«MyName»

You make these files private, and list them and their contents to make sure everything is as it should be.

chmod 600 *
chmod 700 .
ls -hal
cat *

Your terminal now looks something like this:

:~/.ssh$ chmod 600 *
:~/.ssh$ chmod 700 .
:~/.ssh$ ls -hal
total 20K
drwx------ 2 «MyName» «MyName» 4.0K .
drwx------ 4 «MyName» «MyName» 4.0K ..
-rw------- 1 «MyName» «MyName»   76 config
-rw------- 1 «MyName» «MyName»  419 «MyName»
-rw------- 1 «MyName» «MyName»  106 «MyName».pub
:~/.ssh$ cat *
Host gitea.rho.la
        User gitea
        IdentityFile ~/.ssh/«MyName»
-----BEGIN OPENSSH PRIVATE KEY-----
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-----END OPENSSH PRIVATE KEY-----
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILJkMCDumS7BTc1iKHHXf+Wk0Fjl7vByh0JNegkWENvd

2.2 Register your key on Rho

Having previously registered a new user, «MyName», at Rho, you click on the user icon at top right, click on settings, click on keys click on add ssh key, and add the contents of «MyName».pub

then click on verify, which gives you code to paste into my terminal

:~/.ssh$ echo -n 'e7277e80432bc2a033d92f0d4078e5877c7de4fe105e6b0f04b04e2c6a5005d9' | ssh-keygen -Y sign -n gitea -f «MyName»
Signing data on standard input
-----BEGIN SSH SIGNATURE-----
U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgsmQwIO6ZLsFNzWIocdd/5aTQWO
Xu8HKHQk16CRYQ290AAAAFZ2l0ZWEAAAAAAAAABnNoYTUxMgAAAFMAAAALc3NoLWVkMjU1
MTkAAABAv1ON+wMqm2rVxhzuraBIEc3NVog6zsHvHktzFGcmQmPyY1DFnq0wwnIIfECIRy
pJSNoDEPZeXKruHokzPF8WCw==
-----END SSH SIGNATURE-----

You paste that in to the verification window, and Forgejo tells you “Verified key
«MyName»
SHA256:NLOjR27eL+KUZ29xE5DGiCqqyCQUf8c2Wllq2kBM8y8”

2.3 Fork

This enables you to push, pull, and fork from the repository as the remote

You then click on the plus button, and fork the repository rho/wallet or rho/rhomessaged

you go back to my linux terminal, switch to your source directory, and clone your fork of the repository using the ssh address displayed by gitea, which will be something like gitea@gitea.rho.la/«MyName»/wallet.git

git clone --recurse-submodules gitea@gitea.rho.la/«MyName»/wallet.git

If you already cloned the repository using https, you will need to edit the origin remote from the https address to the ssh address of your fork.

2.4 Set up git signatures

You then then cd into that freshly cloned repository list the public key, ~/.ssh/«MyName».pub and add it to the .gitsigners file

After a subsequent pull that gives you a status of modified submodules, or if you originally cloned without the --recurse-submodules tag, to fix the submodules

git submodule update --init --recursive --remote

After a checkout or branch switch that gives you a status of modified submodules.

git submodule update --recursive

You then configure the local git repo to sign your commits and to check signed configs against the .gitsigners file

nm=«MyName»
cd ~/.src
git clone gitea@gitea.rho.la:$nm/wallet.git
cd wallet
cat ~/.ssh/.pub
nano .gitsigners
# add your pseudonym and public key to the list,
# preferably in alphabetical order
git config user.signingkey ~/.ssh/$nm.pub
git config user.name $nm #must agree with the name you created on Rho
git config user.email $nm@example.com ##must agree with the fake email you created on Rho
git config include.path ../.gitconfig #sets various defaults, ssh signing among them

Your terminal now looks something like this:

:~/.ssh$ cd ~/src
:~/src
:~/src$ git clone gitea@gitea.rho.la:$nm/wallet.git
Cloning into 'wallet'...
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (4/4), 11.57 KiB | 11.57 MiB/s, done.
:~$ cd wallet
:~/src/wallet$ cat .ssh/«MyName».pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILJkMCDumS7BTc1iKHHXf+Wk0Fjl7vByh0JNegkWENvd «MyName»
:~/src/wallet$ nano .gitsigners
:~/src/wallet$ cat .gitsigners
«MyName» ssh-ed25519 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILJkMCDumS7BTc1iKHHXf+Wk0Fjl7vByh0JNegkWENvd
:~/src/wallet$ git config user.signingkey ~/.ssh/$nm
:~/src/wallet$ git config user.signingkey ~/.ssh/$nm
:~/src/wallet$ git config user.name $nm #must agree with the name you created on rho
:~/src/wallet$ git config user.email $nm@example.com ##must agree with the fake email you created on rho
:~/src/wallet$ git config include.path ../.gitconfig #sets various defaults, ssh signing among them

Because you have added .gitconfig to your local .git/config, git log will now display the crypographically secured ssh signatures based on .gitsigners, rather than the claimed email address.

You then commit the .gitsigners file, and do a git lg -2 to see the signature is good.

git utcmt -am"adding my name to .gitsigners"
#utcmt is an alias for commit set in .gitconfig to avoid revealing your timezone
git lg -2  #alias for log, set in .gitconfig to display good signatures
git push

:~/src/wallet$ git utcmt -am"adding my name to .gitsigners"
:~/src/wallet$  git lg -2  #alias for log, modified in .gitconfigto display good signatures
2 minutes ago  G «MyName»

git log now displays username, and in blue, whether the signature is good rather than the unsecured username and email address. The .gitconfig git alias, git lg, displays a more concise display of the log information.

Only someone who has the secret key corresponding to the public key in .gitsigners can a generate a commit that gets a blue G after the name, and .gitsigners is under git source control so that any improper changes in it will be obvious. (A better solution would be the equivalent of .gitsigners on the blockchain so that improper changes are impossible.)

Then push the file to Rho, and go back to Rho to see if the signature on your commit to your fork was recognized on Rho, as it was recognized by Git when you typed git lg -2

Rho should show a padlock on your commit, indicating validly signed.

But Rho signature checking is not the final authority, merely a convenience. The final authority on identity and identity checking must be local, because solutions out in the cloud will be subject to attack by enemies.

If Git thinks a signature is valid, and no improper changes have been made to .gitsigners then it is valid, no matter what the server may say. We should eventually add a git hook to ensure that .gitsigners is insert only, and dupe free.

But because everyone has a local history of .gitsigners, everyone can themselves determine that no improper changes have been made since they got started using it.

If not your keys, then not your coins. Well. If not your keys, then not your commits either. Identity, they say, is consensus, and it is, but whose consensus? Thus identity must ultimately be local.

The immediate objective of the software we are creating is to provide local identity for everyone, and the plan to make money out of it is to provide local identity for doing business, with the likely early adopters being dexes.

3 Building and unit testing the code

To build on linux, you need * the gtk library files, which on Debian are apt install libgtk-3-dev * libsecret, which on linux is apt install libsecret-1-0 libsecret-1-dev and on Arch are pacman -S libsecret To build the docs you will need Pandoc.

To build the wallet executable, in the project root directory run

cmake -B build -S .
cmake --build build --config Debug
cmake --build build --config Release
# optional, use multithreading (helpful for wxWidgets)
# cmake --build build --parallel $(nproc)

this will build the project including submodules. Afterwards, to run the wallet:

./build/wallet -dct

The command line argument -dct runs and displays the unit test.

On Windows using Microsoft Visual studio, you will find that though you need cmake to build the static libraries, msvc/wallet.sln is more convenient than the build/wallet.sln built by Cmake, because you are unlikely to be working on the libraries.

4 Editing and building the docs

The docs are in a chaotic state, with much that should be linked unlinked, and much that should not be linked because obsoleted by recent events and in urgent need of updating, or just wrong, and some of the links that do exist pointing at the wrong directory. All links are relative so that the website in the build directory will work identically to the website on the server.

The docs are in Pandoc markdown. They are intended to edited in codium, preferably with the .continue extension pointing at a local llm for privacy.

4.1 build website locally

If you are using Visual Studio Code, you should not be, because it is loaded with spyware, censors the extensions, sells your personal information, and manipulates extension page rank to steer you into the Microsoft, spyware, and Big Corp ecosystem. Use Codium.

codium docs

In codium, assuming docs is the current project directory, the Control Shift B key will rebuild the website from the markdown files and the various website configuration files in each docs directory.

Or to build manually in the terminal:

mkdir -p docs/build
cd /docs/build
cmake -G Ninja ..
cmake --build .

 reaction.la gpg key 154588427F2709CD9D7146B01C99BB982002C39F
This work is licensed under the Creative Commons Attribution 4.0 International License.