feat: Add trust documentation

Author: oSumAtrIX

docs/revanced-internals/README.md

@@ -11,4 +11,5 @@ ReVanced is a FOSS (Free and Open Source Software) project. However, one of the
 - [Principles](principles.md)
 - [Management](management.md)
 - [Infrastructure](infrastructure.md)
+- [Trust](trust.md)
 - [Finance](finance.md)

docs/revanced-internals/history.md

@@ -0,0 +1,20 @@
+# ReVanced history
+
+With years behind, ReVanced has rich history. Here, it is documented.
+
+## <find title>
+
+- Begin:
+- Group formation:
+- Name settled:
+- First commit:
+
+## How it started
+
+ReVanced s where Vanced stopped. Vanced is a predecessing project maintained by different people. Vanced provided a modified version of YouTube with a rich community. Rumors during the time Vanced announced its end revolved around various reasons such as <fill>, however, it came to an end by a cease & desist letter from YouTube due to improper use of their media assets. While this sounds like an easy thing to solve for Vanced, it seems Vanced used this as an opportunity to end the project and move on. The day that marked the end of Vanced is the day ReVanced began. An announcement was posted on the Vanced Discord server regarding the end,which led to discussions in the channels of the server. Particularly one which led to the birth of ReVanced. First, it was explored, how Vanced could be kept alive and various ideas were discussed, one of which is the core principle of ReVanced. Unlike Vanced, which modified YouTube and distributed APK files, an open-source patcher ran by the user would apply the modifications. This way, a halt like Vanced would be mitigated, because the patcher and the patches would be open source and ran on the end of the user. This idea was met with skepsis, however some individuals did see a potential and continued the brainstorm around this idea leading to a primitive formation of a handful of people that were interested in it. A Discord server was made for this purpose, which today is the ReVanced Discord server.
+
+Once the Discord server was made, the name "ReVanced" was decided for the project. "Re" would stand for "reverse engineering", "restart", "renewed", "reimagined" and similar to which "Vanced" was appended forming the name "ReVanced". The name was perfect, because it was not only a word-play, but also strategical in the early beginnings of ReVanced. Vanced was discontinued, so the community were exploring for alternatives. The name "ReVanced" sounded familiar to people, whereas "Re" gave a sense of continuation and advancement of Vanced. The slogan "Continuing the legacy of Vanced" further enhanced this, and was a strategic move which lead to the fast grow of ReVanced in the early times. The idea seemed reasonable, the name convincing and soon many people joined the Discord server curious to see how it evolves. In the meantime, the team started to realize the project by creating a GitHub organization, early stages of branding, proof-of-concepts and performing research. The Vanced APK file was reverse-engineered to understand the modifications that would later be realized as open-source patches. Eventually a proof-of-concept was created that did patch the YouTube application which proved the potential of the idea for the first time. At the same time other initiatives have started to continue what Vanced had left. However, ReVanced was different. Instead of developing a similar solution like Vanced, ReVanced provided a unique concept to patch apps, that was later abstracted and scaled to be able to patch any app arbitrarily, thus not only making it a continuation of Vanced, but something much bigger than that, a general-purpose patcher for Android applications as seen today. The team was successfully coordinated into developing the patcher and the patches to ensure an efficient workflow right from the begining of ReVanced. With the code being open, developers alike started to get involved and form ReVanced into shape.
+
+## Branding
+
+At one point in time, when ReVanced was already an established initiative, ReVanced did not have proper branding like logo, or guidelines. ReVanced started with basic iterations of brandings and settled with one that looked similar to the current one. This logo accompanied ReVanced for a while, however, did have room for improvement. ReVanced decided to implement proper branding. The community was given time to submit logo ideas and concepts, which eventually would be voted. A vote was made eventually, however the winning logo was an improved version of the one used at that time. This showed, that the community got familiar with the logo already and liked it the most. Once the logo was chosen ReVanced began to design a final, proper version of the submission forming the current ReVanced logo. Not everyone was satisfied, however the majority seemed to be okay with the logo. A second poll was made afterwards to lock in the logo with the community one last time.

docs/revanced-internals/marketing.md

@@ -0,0 +1,15 @@
+# ReVanced marketing
+
+To maintain a presence on the web, ReVanced has certain rules and conventions to market itself.
+
+## Branding
+
+ReVanced uses branding consistently according to the ReVanced branding guidelines. Whereever applicable, the ReVanced logo or name is used to present itself. Additionally ReVanced comes with a slogan as part of the branding guidelines whenever a description is needed.
+
+## Representation
+
+ReVanced is not represented by any individual. Instead, it is represented by itself. This means, that ReVanced speaks to the community and not e.g. the lead or team member. This can be observed in the ReVanced Discord server channel or the announcements page on the ReVanced Website for example. This ensures the community does not create a strong association between ReVanced and any individual and strengthens the bond between the community and ReVanced itself. However, the team is publicly presented by ReVanced, for example on the homepage, through Discord roles, donation pages, or in GitHub repository commits. Team members also interact directly with the community on an one-to-one basis <im auftrag von> ReVanced.
+
+## Speech
+
+As an open project, ReVanced uses neutral speech. This ensures the project remains true to its purpose and does not deviate into irrelevant matters. Neutral speech also ensures that no specific personality is embodied by ReVanced. While this may sound boring to some, it ensures ReVanced is not forced into some kind of appearance. Instead, it freely allows everyone to interpret ReVanced the way they see fit.

docs/revanced-internals/other.md

@@ -0,0 +1,51 @@
+# ReVanced other
+
+Some internals are still uncategorized but noteworthy.
+
+## Consistency
+
+ReVanced maintains a couple of repositories on GitHub. However, often, repositories share similar structures, code or style. Since a handful of maintainers work on these repositories separately, inconsistencies can occur. For this reason, from time to time, similarities between repositories are identified and kept consistent. Examples include CI, readmes, documentation, dependencies, build systems, code-style or repository settings. Consistency allows ReVanced to apply changes across repositories in bulk via a single source of truth and reduce technical debt with an increasing size and amount of repositories. Consistency also reduces disruption of users and contributors navigating across repositories in ReVanced.
+
+## Modularity
+
+ReVanced is designed with modularity. ReVanced Manager and ReVanced CLI allow using any set of patches for example. You can configure ReVanced Manager to use a different API and use APK downloaders of your choice. Patches are modular as well, so that each patch can be developed, maintained and used separately. Modularity prevents centralization, as you can use ReVanced with your own choice of modules. Our distribution of our tools like ReVanced Manager are configured to default to our distribution of modules, like our patches or API. Someone elses distribution could configure their modules. Modular design also allows decoupling systems, code and isolating problem spaces. This ensures development of one module does not disturb another which eases the maintenance and development of ReVanced. Designing with modularity in mind is not easy and can be accidentally done incorrectly, yet it is an important attribute of ReVanced.
+
+## Conventions
+
+### Comments
+
+Comments should conventionally conform a valid English sentence. This means, starting comments with an uppercase letter and ending them punctuation. Sometimes comments only consist out of a single word, in which case, the word should start with an uppercase letter and end with a punctuation, unless it is a specific term. Some examples of comments include:
+
+- // A regular comment should be a sentence.
+- // Word.
+- // terminology.
+
+### Naming
+
+Abbreviations should not be used to mitigate unreadable or obfuscated code, as well as to increase consistency. Examples that are okay:
+
+- val home = Home()
+- val methodInstructions = method.instructions
+- val instructions = fingerprint.method.instructions
+- val instructionIndex = instruction.index
+- val index = instruction.index
+
+In contrast, examples that are not okay:
+
+- val h = Home()
+- val mInsn = method.instructions
+- val ins = fingerprint.method.instructions
+- val instructionIdx = instruction.index
+- val idx = instruction.index
+
+Long names may be shortened without abbreviation, e.g., instead of "someClassFingerprintMethodInstructionIndex", just "index" may be used. Shortening variable names should be done according to contextual requirements. Expressive variable names that explain what they are should be used. For example, instead of just "index", the variable name "returnIndex" would be favorable in the case it refers to an index where something is returned. Depending on the context, to avoid redundancy, "index" may also be fine, however this needs to be weighted on a case-by-case basis.
+
+This kind of naming scheme should be reflected on class, method, field and even outside of code, e.g., in documentations, announcements, readmes and more.
+
+### Abstraction
+
+Especially patches may have repetitive patterns, e.g., manifest patches that replace some attribute are mostly similar to each other, differing only in the attribute. In such cases it is very important to abstract code in a way so it can be shared. Duplicate code should be avoided to mitigate tech debt.
+
+### Emojis
+
+ReVanced uses emojis in documentation and other various places, e.g., document titles, readmes or similar.

docs/revanced-internals/trust.md

@@ -0,0 +1,28 @@
+# ReVanced trust
+
+ReVanced uses cryptography to ensure trust.
+
+## Signing
+
+Assets such as the patches or tools, or messages like announcements, changelogs or certificates are signed with a GPG key. For each purpose, an individual subkey may be used.
+
+## Verification
+
+The following steps are necessary to verify signatures:
+
+1. Obtain the signing key: Before you can verify a signature, you need to obtain the public key of the signer. This key is usually shared via a trusted channel, such as a website or a key server. ReVanced publishes its keys at [api.revanced.app/keys](https://api.revanced.app/keys). Import the key with `gpg --import <key-file>`.
+2. Trust the signing key: After obtaining the public key, you need to trust, that it is the correct key. A simple method to establish trust is to compare the signing key's fingerprint with that of a handful of signed assets or messages. If the fingerprints match, this means, the key is associated with them. For higher assurance, you need to verify the key's fingerprint through multiple independent sources, such as official social media accounts, community forums, or other trusted individuals and sources.
+3. Verify the signature: Once you have the public key and have established trust in it, you can use it to verify the signature of subsequent assets or messages. This is typically done using the `gpg` command-line tool: `gpg --verify <signature-file> <signed-file>`.
+
+### Verifying certificates
+
+To verify a certificate, follow the same steps as above. The certificate itself is a signed message, so you can verify it like any other signed message. A certificate should also include the public key of the entity it is issued to, so you can verify that the certificate is indeed issued to the correct entity. To prove that an entity is indeed the holder of the private key associated with the public key in the certificate, request a message signed with the private key and verify it with the public key from the certificate. Require a challenge to be signed alongside the message to prevent replay attacks.
+
+## Revocation
+
+In case a signing key is compromised or lost, it can be revoked. Revocation certificates will appear at [api.revanced.app/keys](https://api.revanced.app/keys) as well as [keyserver.ubuntu.com](https://keyserver.ubuntu.com/).
+
+## Notable scenarios
+
+- Next to ReVanced signing release assets, GitHub provides [artifact attestations](https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations) to proof that a build was created by a specific workflow. This can be used to link a release asset to a specific commit or tag in the source code repository. WIth this, you can trust GitHub that our assets were built from the source code we publish and at the same time, trust ReVanced that the assets are official ReVanced assets, giving you bidirectional trust, independent of each other. ReVanced Manager, ReVanced API, ReVanced CLI and similar are examples that are or will rely on this to ensure trust
+- Permission to use copyrighted brand assets is granted in the form of a GPG-signed message