Previous Page

nihilist@mainpc - 2025-03-21

How to become a Maintainer

Becoming a Maintainer is the next step to contribute to the Opsec blog and Darknet Lantern projects, where you get to assist the other contributors contribute just like you did. The requirement is simple: You should have contributed at least 3 times, having submitted contributions that were already nearly finished (95%) in one go. If you are still submitting contributions that are 75% finished in one go, you are not ready to become a maintainer yet, maintainers are supposed to know the quality standard perfectly, to be able to enforce it when doing contribution reviews, therefore i expect that they show that they understand it.

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

Onboarding new Contributors

First of all if there are new contributors that want to join in and contributors, maintainers need to invite them to the contributors chatroom, (and if said maintainer is an administrator, give them their git account credentials):

Once added in private messages, the user can be invited (and can safely get their new git account credentials) :

In the Contributors chatroom, the contributors will be able to communicate with maintainers directly:

Converting Criticism into todolists

As a maintainer, you get to also be paid for writing valid (and actionnable) todolists, since you get to have authority on what they contain, and you get to decide if they are valid or not. This is why it is important for you to take part in the debates that are happening in the public OPSEC chatroom.

As a maintainer, you are getting rewarded 2 euros per valid todolist, all you need to do is write them (coming from criticisms that you either make, or that the other community members make), then you need to put them on each git issue that they are related to. So if you write a new todolist, please make sure that you save the link to the todolists that you wrote so that you can ask to recieve payment at the end of the month for all of the todolists you wrote, in one go.

The financial incentive lies is in tracking all the valid criticisms that are being thrown at us in the public chatrooms (which are all opportunities to improve, that's why we welcome it) to then write alot of todolists, for example if you write 10 valid todolists in 1 month time, you'll recieve 20 euros in monero for correctly writing them (as the payment is 2 euros PER todolist correctly written).

If there are any valid criticisms to tutorials that are supposed to be finished (meaning there are tutorials that need to be improved), write the todolist on the issue (in the completed column), and move it back to the "to be assigned" column

Therefore make sure that you take part in the criticisms and debates in in the opsec chatroom, as this is the place where you'll see the most criticism coming from, so if there are any valid criticisms coming from there, make sure that the criticism is at least saved somewhere (ideally on the targeted git issue, or on a new one that you created yourself.)

If you want to save the criticism somewhere on the git repo for later, go into the maintainers project board and create a git issue there, with the title starting with "Criticism - For the tutorials XYZ", and make sure you add the label "criticism to convert into todolists", that'll help us make sure that criticisms aren't lost forever, but rather are stored somewhere, to be treated at a later time:

See this git issue for instance, that i created to contain the valid criticism i recieved for the Sensitive VMS tutorial, that i saved here to treat (or let another maintainer) treat at a later time.

When you decide to turn criticisms into todolists, follow the usual format as detailed in the previous "how to become a contributor" tutorial:

to be explained: (why + what)
-
-
-

to be showcased: (How)
-
-
-

If you are not sure about if a particular todolist/criticism is valid or not, you can ask an administrator their opinion to know if it's OK or not aswell, to double check. But by default, as a maintainer your judgement is going to be trusted to write correct todolists. (With only other maintainers or administrators being able to overrule your judgement)

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.

Assigning contributors onto todolists

As a maintainer you also get to assign people to work on todolists:

You get to have authority on deciding what todolists get to contain (with only the other maintainers and administrators being able to overrule your decisions), you can validate them or edit them however you wish, only if they are not yet assigned (do not change a todolist if there's already someone working on it).

(don't forget to move the issue into the "assigned" column on the project board aswell:

Reviewing Contributions

And lastly, the maintainer's role is to review contributions whenever a contributor submits one, That's probably the most time consumming part. For example, we have the following contributor that's assigned on this issue:

As you are most likely already aware since you are supposed to already be a contributor, whenever someone submits a contribution, they need to follow the quality standard, as a maintainer, you are supposed to make sure that they follow that standard whenever they try to contribute new content.

Here for example, the contributor "optimist" submits a contribution after having followed the "how to contribute" guide, and lets you know in the contributors chatroom:

Going there you see that the contributor correctly made a PR, but you need to git clone it to review the changes:

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [~]
→ cd Documents

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [~/Documents]
→ torsocks git clone http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/optimist/blog-contributions blog-contributions.optimist
Cloning into 'blog-contributions'...
remote: Enumerating objects: 6608, done.
remote: Counting objects: 100% (6608/6608), done.
remote: Compressing objects: 100% (5362/5362), done.
remote: Total 6608 (delta 3302), reused 3611 (delta 1133), pack-reused 0 (from 0)
Receiving objects: 100% (6608/6608), 342.55 MiB | 522.00 KiB/s, done.
Resolving deltas: 100% (3302/3302), done.

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [~/Documents]
→ cd blog-contributions.optimist

If they wrote their changes in a separate git branch, switch to the correct branch like so:

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [blog-contributions.optimist/opsec/nextcloud]
→ git switch branchname

Then in the cloned repository, navigate to the new tutorial folder to get the path:

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [~/Documents/blog-contributions.optimist]
→ cd opsec/nextcloud

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [blog-contributions.optimist/opsec/nextcloud]
→ pwd
/home/nihilist/Documents/blog-contributions.optimist/opsec/nextcloud

And in there from your local browser you can assess if the contribution is completed, and if it follows the quality standard:

Here as you can see, this is clearly garbage. It does not follow the quality standard at all, and it even deviates from the todolist that the contributor agreed to work on. So you can either spend 10x more time reviewing what they took to write by making the following assessment, or since this was a low effort you could simply post a low effort review like so:

1) re-read the quality standard
2) re-read the methodology on how to contribute
3) re-read the todolist again and follow it this time 

this is 30% completed.

On the contrary, if the user actually tried his best to write the contribution, (meaning it has to be above 30% completed FOR SURE, ideally 95% completed) then yes give them a lengthy review to help them better their contribution like the one that oxeo wrote:

Then the contributor pushes some more commits to fix their mistakes and ask for a second review, so since we already git cloned their repository we just need to do a git clone to pull their new commits:

Then, locally you can do a git pull to review their updates, in order to review their contribution locally again:

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [blog-contributions.optimist/opsec/nextcloud]
→ cd ../..

[ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [~/Documents/blog-contributions.optimist]
→ torsocks git pull

And from there, if there are still mistakes that they can improve on, tell them that the contribution is (depending your assessment) for example 80% completed, stating what's missing still. Otherwise confirm that the contribution is OK and ready to be merged (using the good to merge git label)

Then the administrator issues payment for both the contributor and to you the maintainer, for correctly reviewing a contribution. For maintainers specifically, the payment for the reviews will depend on how tedious the reviewing was.

- 1 back and forth: (easy review) 3 euros
- 2 backs and forth: (average review) 5 euros
- 3+ backs and forth: (tedious review) 8 euros

Obviously, no need to be an ultra-perfectionnist for every detail that doesnt truly matter, however The top priority here is that the blogpost needs to be CRYSTAL CLEAR It needs to be easy to understand, from start to finish, while containing all the information one needs to understand what we are talking about, and how to achieve the targeted setup. If the noobs out there don't understand what the hell we're talking about, then we are doing them a disservice by writing those blogposts.

Dealing with Lazy and Incompetent Contributors

Just warning you, this is the most annoying part of being a maintainer, so if the reviewing is extra-tedious because you are facing an incompetent or lazy contributor, don't worry i'll send you extra monero your way for your trouble.

I don't want this blog to contain ANY half-assed content, the only acceptable content is VALID, FINISHED, QUALITY content. It takes time to have quality, that's why we give a 1 month default deadline (which is more than enough 99% of the time, even for complex contributions). if contributor A is not going to write a tutorial correctly before the deadline, REJECT THEIR CONTRIBUTION, contributor B will write it correctly later on (Sum Nihil, don't care who does what, only care about what they do).

With a 1 month deadline, there's no rush. Do not tolerate laziness or incompetence coming from contributors. Whoever wants to contribute to the blog is expected to follow the todolist, and follow the quality standard. If that contributor does not contribute quality, it means that they do not WANT to contribute quality. And if that's the case, do not waste your time on them.

I repeat, If a contributor doesn't contribute quality after being told to do so, DO. NOT. CARE. REJECT THEIR CONTRIBUTION. It's not for you to do it for them, it is for them to step up to do it themselves, do not treat them like a baby, if something needs to be fixed, tell them to fix it, and wait for them to fix it. From my own experience, if the contributor is not competent, it is not worthwhile to keep recieving contributions coming from them, as they are simply wasting the reviewers' time.

The contributor is expected to know what they are talking about, and they must be willing to write it in the correct way, so that their knowledge is correctly transmitted to the readers out there.