The Quality Standard
In order to make sure the content isn't rushed and the quality of the blog overall remains high, we have the following quality standard:
Rather than writing a gigantic wall of text and loose you halfway, as you can see i made a graph. This is the most effective way of conveying your ideas to your audience, so don't hesitate to make graphs using drawio (with colors preferably) instead of writing walls of text that nobody will read.
First of all, the general structure of the content is with the Why / What / How methodology This following the minimalistic style where everything that is used and mentionned must be justified. (Everything that has no justification to be there, is to simply be removed.)
Why should I care ?
What are my options ?
How can i implement it ?
Nobody cares about your message until you tell them why they should care. Usually that goes by telling them a short story that they can relate to, in our case it's an opsec scenario that explains what an adversary can do against you.
The blog is structured around 3 core scenarios:
Privacy: The adversary can see you do something, how can you prevent it ?
Anonymity: The adversary knows that it's you who did it, how can you prevent it ?
Deniability: The adversary busts down your door, and forces you to open your devices, how can you make sure he doesn't find anything in there ?
If the scenario of your contribution doesn't fit into (or serve a purpose for) one of those 3, it's most likely off-topic.
Context: In your house, in your bedroom, if there are windows to look outside
Situation: the annoying neighbor always stops by to look at what you're doing in your bedroom
Are you ok with this situation ?
So you told your story to highlight the problem, the reader understands that they want privacy. Now you need to tell them the what, what are their options ?
You have a few options to prevent your annoying neighbor from seeing what you're doing in your bedroom:
1) get rid of all windows and have a house with only walls : expensive
2) install curtains on your windows : inexpensive
Sidenote: Nobody wants to read a wall of text. HIGHLIGHT the important parts (using the <b></b> tags of your text so that the reader's eye is immediately drawn to what matters most.
Now that you laid out the Why, you of course tell them what the best option is, and then you're going to tell them how they can implement it.
Let's showcase how to install curtains, as it's the easiest and cheapest solution to prevent outsiders from seeing what you're doing in your bedroom.
1) buy it,
2) then you attach it above your windows, using screws and screwing it into the wall, (warning, if you're living in an apartment, ask for your landlord's permission!)
3) then you can move the curtain to prevent outsiders from peeking in
But the thing is, we're not lazy blogwriters here, talking about the path is not enough, you are expected to show the readers how you walk that path. This is why the todolists for new blogposts are structured like so:
to be explained: (WHY + WHAT)
-
-
-
to be showcased: (HOW)
-
-
-
-
In the first part usually there is the to be explained section, where you tell the user why they should care, and what their options are, but afterward there usually is the "to be showcased" part. In that part, you are expected to do a step-by-step tutorial of how to implement the solution which means that you are literally implementing the solution yourself, for yourself, but showing everyone how you're doing it.
Let's take a small todolist that is as follows:
to be showcased:
1)Download grapheneOS (GUI digital step)
2)Reboot the phone (Physical step)
3)flash graphene OS on the phone (CLI digital step)
Here we have a combination of the 3 possible types of steps you may be expected to showcase, a physical step, a GUI digital step, and a CLI digital step.
The first step being a GUI digital step, you need to take a screenshot with arrows, to make it simple i recommend using flameshot like i explained above, to have screenshots like that:
In the case of the physical step, you need to take a picture, and add arrows in it if needed, like so:
While editing the html file it will look like that (as you need to put the picture in the same folder as the tutorial you're editing):
<img src="1.png">
If you want to reuse an image from another tutorial like i just did above (it's totally fine), but rather than copying the image from another tutorial and waste diskspace, you can simply reuse the image of another tutorial by adding ../tutorialfolder/ before the path of the image like so:
<img src="../graphene/10.png">
and lastly if you have a CLI step to show, you need to simply copy paste the terminal output in the pre code blocks while still highlighting what's important like so:
<pre><code class="nim">
nowhere# ./flash-all.sh
Warning: skip copying bootloader_a image avb footer (bootloader_a partition size: 0, bootloader_a image size: 14125140).
Sending 'bootloader_a' (13794 KB) OKAY [ 0.364s]
Writing 'bootloader_a' (bootloader) Flashing pack version slider-14.5-11677881
(bootloader) flashing platform gs101
(bootloader) Validating partition ufs
(bootloader) Validating partition partition:0
[...]
OKAY [ 3.089s]
Finished. Total time: 3.454s
Setting current slot to 'a' OKAY [ 0.058s]
Finished. Total time: 0.059s
Rebooting into bootloader OKAY [ 0.000s]
[...]
Sending sparse 'super' 11/13 (254972 KB) OKAY [ 6.618s]
Writing 'super' OKAY [ 0.950s]
Sending sparse 'super' 12/13 (254972 KB) OKAY [ 6.621s]
Writing 'super' OKAY [ 0.935s]
Sending sparse 'super' 13/13 (46284 KB) OKAY [ 1.216s]
Writing 'super' OKAY [ 0.204s]
Erasing 'userdata' OKAY [ 0.390s]
Erase successful, but not automatically formatting.
File system type raw not supported.
wipe task partition not found: cache
Erasing 'metadata' OKAY [ 0.007s]
Erase successful, but not automatically formatting.
File system type raw not supported.
Finished. Total time: 105.929s
Rebooting into bootloader OKAY [ 0.000s]
Finished. Total time: 0.150s
nowhere#
</pre></code>
If there are parts of the commandline output that don't matter, just replace them with [...] in order to stick to what the user needs to see.
And lastly, if you are someone that makes alot of spelling and grammar mistakes (like me, i know i'm guilty of that aswell), use LTEX+'s addon on vscodium (which is the FOSS version of vscode), it will setup a local LLM that will find your grammar and spelling mistakes:
wget -qO - https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/master/pub.gpg \
| gpg --dearmor \
| sudo dd of=/usr/share/keyrings/vscodium-archive-keyring.gpg
echo 'deb [ signed-by=/usr/share/keyrings/vscodium-archive-keyring.gpg ] https://download.vscodium.com/debs vscodium main' \
| sudo tee /etc/apt/sources.list.d/vscodium.list
sudo apt update && sudo apt install codium
Now using this addon you can find your typos more easily (as it highlights them for you), effectively helping you find and fix them, so if english isn't your first language definitely make sure that you run LTEX+ once after you finished writing your article, so that you don't leave spelling mistakes behind.
DISCLAIMER: a blogpost is NOT complete until it follows this quality standard, if you find one that doesn't meet those requirements, do mention it on their gitea issue or ping me directly about it on SimpleX.
Same thing if you want to contribute a blogpost that does not meet these quality requirements, i do not care, it is NOT finished until it meets those requirements. Do not be suprised if i refuse your blog contribution for weeks on end if it doesn't meet the requirements. It may take a little more time to do things properly, but at least you're not lowering the quality of the overall blog by following it.
Sidenote: Help us improve this tutorial by letting us know if there's anything missing or incorrect on this git issue directly!