Previous Page

nihilist@mainpc - 2025-04-03

How to become a Contributor

In this tutorial we're going to look at how you can contribute to the opsec blog, we'll look into how the work is being organized, and how to contribute via gitea.

Sidenote: Help us improve this tutorial by letting us know if there's anything missing or incorrect on this git issue directly!

The Nihilism Blog Organisation

First, look at all the blogposts that are yet to be completed from the opsec index page to see if there are some you'd like to do:

Each tutorial (even if completed) has it's own assigned issue on gitea:

You can pick one that you'd like to do, if you see one that has a red cross you can click on it, it will redirect you to it's assigned gitea issue (example: Easy Private Chats - SimpleX. If there is no todolist on each assigned gitea issue, you are free to brainstorm it like so:

If a blogpost gitea issue doesn't have a todolist yet, please follow this general template to write it:

Privacy - Easy Private Chats with SimpleX

To be explained:
- Graph of the targeted setup
- why is this setup relevant ? What are the threats ? What are we trying to achieve (Privacy / Anonymity / Deniability) ? 
- what are your options ? 
- comparing option A B and C
- In this tutorial we're going to use option B because it is superior due to these criterias blah blah blah

To be showcased:
- how to install the clientside application
- how to install the serverside application
- how to configure the application
- show that it works as intended

The idea being that each issue needs to have a clear todolist to bring clarity on what needs to be done in it. Please check if the tutorial is already assigned to someone already or not:

At first, I am assigning only one contributor per tutorial, and only one tutorial per contributor at a time, with a default deadline of 1 month. to complete the assigned tutorial. (if you want to extend the deadline, you'll have to contact me first).

In short, please choose a tutorial that is neither done, nor assigned yet, you can check the status of each tutorial on the project board here:

The list of tutorials that are not assigned yet are in the second column, once you have chosen one just ping me on Opsec SimpleX group chat.

You can also submit a suggestion to me directly if you think this blog is missing something crucial, such as a brand new blogpost idea (although make sure it remains on topic for Privacy / Anonymity / Deniability) i am NOT looking for regular Sysadmin tutorials here.

If you think one of the existing tutorials is missing something, feel free to criticize them in their assigned issues (ping me when you do so, so i don't miss it):

After discussing with me what task you want to do, we'll confirm on the price for that tutorial and after i get your confirmation i'll assign it to you, and that's when you can start to work on it.

Disclaimer: if you're not used to writing technical stuff, please aim for the tutorials that are labeled as "Simple" and that you actually understand. Don't try to bite more than you can chew, otherwise i might refuse further contributions coming from you. You should be at least familliar with the topic you intend to talk about.

What's Offtopic?

Here are the list of things that are offtopic, and that we will NOT cover in the blog (for the foreseeable future at least):

1) General security and hacking: (making sure a software is secure, how to test if it is secure or not) this is a BOTTOMLESS rabbithole that we won't go into again. I went down that rabbithole myself, in the Hacking section. Point being, you anyway cannot defend against the threat that you don't know anything about (0days). You're never going to eliminate all 0day risks by going for ultra minimalism, since every damn line of code your minimal software contains can potentially contain a vulnerability. Trying to protect against the threat you don't know about (0days) IS a pointless and futile endeavor. You can reduce the risks of 0days by going for ultra-minimalism, but we'll leave that at the discretion of the viewers. TLDR: Tell the viewer to run the software on it's latest update. If a malicious commit is pushed into the software, don't trust that repository and maintainer anymore, fork it on your own .onion forgejo instance, remove the bad commits, and compile the software yourself. We will consider some FOSS software as suitable for opsec use until proven otherwise (so don't bring up the 0day excuse) , not the other way around.

2) Closed-source hardware privacy workarounds: no, we won't recommend to the 90% average joes out there to wire up cables to their CPU in order to disable intel ME, install coreboot, or whatever else, and risk bricking their motherboards/CPUs permanently. We will recommend that average joe to purchase fully open hardware devices, that are free of potential backdoors in the first place, when they are available on the market. We do with the tools at our disposal, so until those tools are made available, we use what we can use. We will consider FOSS Host OS as suitable for privacy, even on closed-source hardware for the time being. (so don't bring up the google pixel graphene OS or the Intel/AMD CPU hardware backdoor argument until you find an actual open hardware alternative that does the job aswell)

3) Unrealistic advice: the advice we bring forth in this blog should be doable by 90% of the average joes out there, by explaining it correctly. For instance, no, 90% of the average joes out there are not going to go dressed up in black coats, wear an anonymous mask, sit in mcdonalds, to try and use someone else's public wifi anonymously for entire days on end just to browse the web anonymously and avoid it being tied back to their irl identity. NOBODY is going to do that. Keep that unrealistic advice off this blog, as it doesn't help anyone. The realistic approach to this is to just do a (you -> vpn -> tor -> destination) setup, it defeats 99% of the attack vectors, and 90% of the joes out there can do it if you explain it properly. End of the story. I don't care about the 1% most unlikely scenario that only the top 1% non-average joe can pull off. Simply mention the other options briefly, while focusing on the method that 90% of the people out there are the likely to be able to adopt.

4) Overcomplications: I want you to go for the simplest option that actually leads to the intended result. If, from point A you can go to point B, to arrive at result Z, then if you try to go from point A to B to C to D to E to G to H to then arrive at point Z, you are offtopic because you are overcomplicating something that should have been simpler. If a simpler solution exists, show that option only, do not waste diskspace writing innefficient methods that the readers don't need to read or know about. I will categorically refuse any overcomplications that isn't properly justified with adequate opsec scenarios and threat modeling.

How to contribute new tutorials

Now you first need to sign up on gitea, click the Register button and fill out your details.

DO NOT give your real email here, you can put a dummy one. Email is not verified.

If account creation is successful, you'll be automatically logged in.

Now, you can ask to join our Contributors private chatroom where we brainstorm new contributions, formulate todolists, assign those todolists to contributors like you, and review those contributions:

From there, you can fork the repository, from your new account:

You can leave everything as default as shown below:

Now from there you continue from the commandline, do a git clone the repository you just forked, and do the edits you need to do:

[ mainpc ] [ /dev/pts/18 ] [~/Documents]
→ apt install git tor torsocks -y

[ mainpc ] [ /dev/pts/18 ] [~/Documents]
→ torsocks git clone http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/6dv9lk1pbaflulau/blog-contributions
Cloning into 'blog-contributions'...
remote: Enumerating objects: 3400, done.
remote: Counting objects: 100% (3400/3400), done.
remote: Compressing objects: 100% (2729/2729), done.
remote: Total 3400 (delta 1588), reused 2109 (delta 609), pack-reused 0 (from 0)
Receiving objects: 100% (3400/3400), 149.35 MiB | 6.82 MiB/s, done.
Resolving deltas: 100% (1588/1588), done.

[ mainpc ] [ /dev/pts/18 ] [~/Documents]
→ cd blog-contributions

If you are reusing the repository after you're done sending pull requests, don't forget to do a git pull to make sure you're working on an up-to-date repository, as i am frequently pushing commits.

[ mainpc ] [ /dev/pts/18 ] [blog-contributions]
→ torsocks git pull http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/6dv9lk1pbaflulau/blog-contributions

Now that you're on the latest commit, you can start to do your own changes:

[ mainpc ] [ /dev/pts/18 ] [~/Documents/blog-contributions]
→ ls
assets  index.html  opsec  productivity  pull.sh  push.sh  pushtoprod.sh  README.md

[ mainpc ] [ /dev/pts/18 ] [~/Documents/blog-contributions]
→ cd opsec

now from there you can copy the template tutorial folder called "0_anon" into another folder:

[ mainpc ] [ /dev/pts/18 ] [Documents/blog-contributions/opsec]
→ cp -r 0_anon newtutorial

[ mainpc ] [ /dev/pts/18 ] [Documents/blog-contributions/opsec]
→ cd newtutorial

In it you will find the index.html file that you can edit from the commandline still:

[ mainpc ] [ /dev/pts/18 ] [blog-contributions/opsec/newtutorial]
→ pwd
/home/nihilist/Documents/blog-contributions/opsec/newtutorial

[ mainpc ] [ /dev/pts/18 ] [blog-contributions/opsec/newtutorial]
→ ls
index.html

[ mainpc ] [ /dev/pts/18 ] [blog-contributions/opsec/newtutorial]
→ vim index.html

and you can also view your edits in real time from your browser of choice, just put the complete path to the index.html file to view it in real time, for me it is as follows: /home/nihilist/Documents/blog-contributions/opsec/newtutorial/index.html (just hit F5 to refresh in the browser, everytime you save (:w) in vim)

Make sure that you follow the quality standard i described here: start with the Why, then the What, then the How.

DISCLAIMER: We are not taking any shortcuts in this blog, I expect you to talk about the path, to list the steps that are on that path, and more importantly want you to show the audience how YOU walk that path.

For the "How" parts specifically, as you are expected to explain and show the audience how to do things, make sure you use images and screenshots like so:

<img src="12.png" class="imgRz">

To take screenshots like i do, you can use flameshot, it has everything you need for screenshots. When you take screenshots, dont forget to draw arrows to mention where the user needs to click, add text if something needs to be clarified, etc. and then save your screenshot in the same folder as your blogpost contribution (in this case, in blog-contributions/opsec/new-tutorial)

apt install flameshot -y 

flameshot

Sidenote: If you are showcasing any IRL steps to make, take pictures to explain what needs to be done, just like how i did when i showcased how to install GrapheneOS.

If you are showcasing a complex tutorial please make a graph to explain what you are talking about. One graph will convey the equivalent of a wall of text in one clear image, it's a matter of efficiently conveying information to the audience. I used to make graphs using yEd Graphs (but it's closed source) so instead as of q3 2024 i'm using Drawio to make them, both tools have got everything you need to write complex graphs.

[ mainpc ] [ /dev/pts/3 ] [blog/opsec/manifesto]
→ apt search draw.io
Sorting... Done
Full Text Search... Done
draw.io/now 24.7.17 amd64 [installed,local]
  draw.io desktop

[ mainpc ] [ /dev/pts/3 ] [blog/opsec/manifesto]
→ apt install draw.io

[ mainpc ] [ /dev/pts/3 ] [blog/opsec/manifesto]
→ drawio

If you want to use my logos for onymity, surveillance, centralisation, complexity, etc you can find them in the blog-contributions/opsec/logos/ directory:

Then, i'll let you go through the drawio documentation to learn how to use it, as there's alot to cover to add logos, change shapes, add text, add arrows, etc:

But in the end you should have a good looking graph like this one:

and if there are any commands (or terminal output) to be shown, copy paste from your terminal directly into the index.html file as this is going to help us save some disk space, into the pre code blocks:

<pre><code class="nim">
[ mainpc ] [ /dev/pts/20 ] [~/Nextcloud/blog]
→ vim index.html

</pre></code>

[ mainpc ] [ /dev/pts/20 ] [~/Nextcloud/blog]
→ vim index.html

Preferably copy paste the command outputs into the pre code blocks, so we i can save on storage space as images take alot more space than regular text.

Then once your tutorial is finished, don't forget to edit the footer to contain your contact details, your links if you have any, and your monero donation address (which is important as i use that address to pay you for your contribution).

Now your tutorial is ready to be sent over for review. So now you need to git push it to your forked repository like so:

[ mainpc ] [ /dev/pts/18 ] [~/Documents/blog-contributions]
→ git config --global user.email "6dv9lk1pbaflulau@nowhere.moe"

[ mainpc ] [ /dev/pts/18 ] [~/Documents/blog-contributions]
→ git config --global user.name "6dv9lk1pbaflulau"

[ mainpc ] [ /dev/pts/18 ] [~/Documents/blog-contributions]
→ git add -A

[ mainpc ] [ /dev/pts/18 ] [~/Documents/blog-contributions]
→ git commit

new tutorial contribution
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch main
# Your branch is up to date with 'origin/main'.
#
# Changes to be committed:
#   new file:   opsec/newtutorial/index.html
#   modified:   push.sh

ESC :wq

[ mainpc ] [ /dev/pts/18 ] [~/Documents/blog-contributions]
→ git push
Username for 'http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion': 6dv9lk1pbaflulau
Password for 'https://6dv9lk1pbaflulau@git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion':
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 4 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 388 bytes | 388.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0), pack-reused 0
remote:
remote: Create a new pull request for '6dv9lk1pbaflulau:main':
remote:   http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/compare/main...6dv9lk1pbaflulau:main
remote:
remote: . Processing 1 references
remote: Processed 1 references in total
To http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/6dv9lk1pbaflulau/blog-contributions
   7c759d3..7067b5c  main -> main

Now you have pushed your changes to your forked respository, from there you can make a Pull request (asking me to pull in your changes, to the main repository) as follows:

now from there your pull request is created, and I'll review it as soon as I get the time:

If it's not complete, I'll comment in there asking you to add what's missing, changes that you must actually finish before the deadline. To add further changes simply add more commits to it

[ mainpc ] [ /dev/pts/18 ] [~/Documents/blog-contributions]
→ vim opsec/newtutorial/index.html

[ mainpc ] [ /dev/pts/18 ] [~/Documents/blog-contributions]
→ git add -A

[ mainpc ] [ /dev/pts/18 ] [~/Documents/blog-contributions]
→ git commit

forgot to do this change!
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch main
# Your branch is up to date with 'origin/main'.
#
# Changes to be committed:
#   modified:   opsec/newtutorial/index.html

ESC :wq

[main eb4b994] forgot to do this change!
 1 file changed, 1 insertion(+), 1 deletion(-)

[ mainpc ] [ /dev/pts/18 ] [~/Documents/blog-contributions]
→ torsocks git push
Username for 'http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion': 6dv9lk1pbaflulau
Password for 'https://6dv9lk1pbaflulau@git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion':
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 4 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 432 bytes | 432.00 KiB/s, done.

Then wait for me to confirm the content is complete, and then i'll accept the pull request and merge it into the main repository.

Warning: your contribution is supposed to follow the quality standard, if your contribution doesn't follow the quality standard closely, we're going to keep refusing your contribution until you make it good enough to be acceptable.

If you intend on becoming a maintainer you need to keep submitting contributions that are at least 95% completed each time. The worst you could do is submit a contribution that is 30% completed and waste our time with a tedious reviewing process (which will force us to stop accepting contributions coming from you aswell, if it keeps happening), We'll tolerate it if that's your first contribution, but you should strive to improve your writing skills with each new contribution that you submit. The best contributors (which are fit to become maintainers) are supposed to send nearly completed contributions upon the first review..

Updating existing tutorials

Sometimes it happens that a tutorial is outdated, has errors or just needs some methodology updates. If you have an idea for something that could be added, or if you want to fix some errors in the tutorial, contact us on simplex or open an issue on gitea. We will discuss the changes and make sure they're going in the right direction. If it's a small change (like fixing typos or modifying just a few sentences), you can make a pull request with the changes without contacting us.

Usually, there are already a few issues for blog updates listed on the project board. If you want to help, feel free to pick one and start working on it.
The steps are similar to what we have for creating new tutorial - fork the repository, create a branch and edit appropriate blog post. When you're done with your changes, open a pull request so that we can review them.

Depending on how much of the tutorial is actually changed, you should credit yourself accordingly. For the sake of this example, let's say you're oxeo0 (the person making an update) and Nihilist is the original author of the blog post.

Small change

If the changes you've made are small (let's say less than 20% of the blog post), you should keep the name of the original author. You may change the date to inform readers it has been changed recently, but this is not strictly required. Do not add your XMR address in the footer. This doesn't mean that you won't be getting paid. If you're working on an issue on the project board, there's often a reward even for small edits.

Considerable change

If the changes you've made are considerable (let's say more than 20% of the blog post), you should credit yourself and the original author. Mention the tutorial has been updated by you at the top and keep both yours and author's XMR address in the footer.

Complete rewrite

Sometimes the tutorial needs to be rewritten entirely (more than 90% changes). In this case, you can treat the tutorial as if it was written by you from the beginning.

Special Case - Collaboration

If there is more than one person working on the tutorial, credit all as authors and list their XMR addresses.