fix alot of shit, post-mkdocs contribute guides fixed

maintainers/index.md

@@ -69,24 +69,6 @@ When you decide to turn criticisms into todolists, follow the usual format as de
 
 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](../../hacking/index.md). 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.
-
-![](../contribute/65.png)
-
-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)
-
-![](../contribute/66.png)
-
-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.
-
-![](../contribute/64.png)
-
-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:
@@ -118,27 +100,24 @@ Going there you see that the contributor correctly made a PR, but you need to gi
 ![](10.png)
     
     
-    [ 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
-    
+```sh    
+[ localhost ] [ /dev/pts/23 ] [~/Documents]
+→ torsocks git clone http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/optimist/opsec-blogposts opsec-blogposts.optimist
+
+Cloning into 'opsec-blogposts'...
+remote: Enumerating objects: 2110, done.
+remote: Counting objects: 100% (2110/2110), done.
+remote: Compressing objects: 100% (2106/2106), done.
+remote: Total 2110 (delta 62), reused 1996 (delta 0), pack-reused 0 (from 0)
+Receiving objects: 100% (2110/2110), 193.91 MiB | 146.00 KiB/s, done.
+Resolving deltas: 100% (62/62), done.
+
+```
 
 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]
+    [ Mainpc-PrivateVM-Debian12 ] [ /dev/pts/11 ] [opsec-blogposts.optimist/nextcloud]
     → git switch branchname
     
     
@@ -155,11 +134,10 @@ Then in the cloned repository, navigate to the new tutorial folder to get the pa
     
     
 
-And in there from your local browser you can assess if the contribution is completed, and if it follows the quality standard: 
+And in there from your vscodium editor you can assess if the contribution is completed, and if it follows the quality standard.
 
-![](11.png)
 
-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](http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/pulls/253#issuecomment-1997), or since this was a low effort you could simply post a low effort review like so:
+Here as you can imagine, 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](http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions/pulls/253#issuecomment-1997), or since this was a low effort you could simply post a low effort review like so:
 
 ![](23.png)