#wip: Estructura y base de la documentación.

.gitignore

@@ -0,0 +1 @@
+/Data

Doc/dev/idea.md

@@ -0,0 +1,108 @@
+# Idea a desarrollar
+
+```mermaid
+flowchart TD
+
+C[Clientes]
+
+subgraph Nodos 
+    T[Trackers]
+    S[Servidores]
+    DB["Base de datos"]
+end
+
+subgraph Plataformas
+    VT[VirusTotal]
+    MB[MalwareBazaar]
+end
+
+C -.->|Conocen| T
+T -.->|"Puede ser"| S
+T -->|validan| S
+S -->|"¿Tiene hashes?"| DB
+DB -.->|Sí| C
+DB -->|No| Plataformas
+Plataformas -.-> C
+Plataformas -.->|Registran| DB
+C -->|"Peticionan a"| S
+
+```
+
+## F.A.Q.
+
+> ¿Cómo conoce los clientes a los servidores?
+
+El cliente ha de tener la dirección de un Tracker, y éste ya le responderá cuales son los Trackers y servidores.
+
+El origen serían los servidores de 1noro y KyMAN como Trackers.
+
+> ¿Cómo se inicia por primera vez un nodo?
+
+Se conectará a un Tracker, y éste le devolverá la lista de Trackers existentes. Luego, todos los Tracker tendrán que aceptar su solicitud manualmente por los dueños de los Trackers y cuando todos hallan aceptado dicho Nodo, éste empezará a funcionar.
+
+> ¿Puede ser un servidor no ser Tracker? ¿Nos interesa?
+
+Sí, porque los Trackers son como los administradores, y los servidores simplemente darían el servicio de gestión de Hashes y cuentas antivirus.
+
+> La base de datos...
+
+Todos los servidores tendrían que tener una copia de la base de datos y éstos actualizar dicha copia por cada cambio entre ellos. Esto permite validar como si de una cadena de bloques se tratase. Tiene que existir un demonio en cada servidor que verifique que la base de datos esté actualizada.
+
+```mermaid
+flowchart TD
+
+F[Archivo]
+DB["Base de datos"]
+M[Memoria]
+P[Plataformas]
+R{{Respuesta}}
+X{Registro}
+
+F -->|"¿Está en...?"| DB
+DB -->|Sí| R
+DB -->|"No. ¿Está en...?"| M
+M -->|Sí| R
+M -->|No| P
+P --> X
+X -.-> DB
+M -.- X
+X --> R
+
+```
+
+Registro:
+
+```mermaid
+sequenceDiagram
+
+    participant Servidor1
+    participant Servidor2
+    participant Servidor3
+    participant ServidorN
+
+    note over Servidor1: Tiene un nuevo registro en memoria
+    Servidor1 ->> Servidor2: Envía el nuevo registro
+    Servidor1 ->> Servidor3: Envía el nuevo registro
+    Servidor1 ->> ServidorN: Envía el nuevo registro
+    Servidor2 ->> Servidor1: Verifica tener el nuevo registro
+    Servidor3 ->> Servidor1: Verifica tener el nuevo registro
+    ServidorN ->> Servidor1: Verifica tener el nuevo registro
+    Servidor1 ->> Servidor2: Verifica sincronía
+    Servidor1 ->> Servidor3: Verifica sincronía
+    Servidor1 ->> ServidorN: Verifica sincronía
+    note over Servidor1: Escribe registro
+    note over Servidor2: Escribe registro
+    note over Servidor3: Escribe registro
+    note over ServidorN: Escribe registro
+
+```
+
+> Estado de sincronización al arranque.
+
+> Formato de versión
+
+Mayor-Minor-Patch
+
+- **Mayor**: Completamente márketing. Se decide por los miembros del equipo. Sería como una versión final donde 0 es Alpha o Beta, y a partir de ahí son versiones estables.
+- **Minor**: Número incremental continuo o de cambios. No hay límite.
+- **Patch**: Arreglos rápidos sobre la *Minor*.

Doc/dev/questions.md

@@ -0,0 +1,41 @@
+# Preguntas de los desarrolladores
+
+Esta sección se encargará de almacenar las preguntas cara el desarrollo del proyecto por parte de ellos para ellos. Cualquiera podrá leerlas pero sólo ellos participarán.
+
+## Inclusión de AnP
+
+> Pregunta de **KyMAN**. ¿Verías muy loco montar todo sobre AnP?
+
+La pregunta viene por el hecho de que **AnP** ha de ser un Framework flexible y adaptativo, con sus librerías y mecánicas internas. Probé a importarlo en otro proyecto para probar y funcionó perfectamente aunque en VSCode sale una advertencia en la importanción por el cambio de Path, pero al ir por "from ... import ... as ..." sería compilable. El problema de ésto vendría cara lo que dicho en una de las dudas que expongo en otro punto: estructura AnP válida. 
+
+Si hacemos esto me ayuaría a validar AnP y a blindarlo, además de poder hacer uso de todas sus herramientas y tecnologías. Expongo un ejemplo de vinculación sin integrar dentro del proyecto a AnP.
+
+```py
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+# Importamos las librerías pertinentes al VirusTotalPlus.
+from Application.VirusTotalPlus import VirusTotalPlus
+from typing import Any
+from os.path import abspath as absolute_path
+from sys import path
+
+# Añadimos el directorio Python del proyecto AnP, importamos AnP, creamos objeto 
+# para consumir dependencias y limpiamos Paths del proyecto.
+path.append(absolute_path('../../AnP/Python'))
+from Application.AnP import AnP
+anp:Any = AnP()
+path.clear()
+
+# Montamos objeto VirusTotalPlus, que viene siendo la aplicación.
+vtp:VirusTotalPlus = VirusTotalPlus(anp)
+
+```
+
+Esta idea también puede desarrollarse en una librería Abstracta donde cargamos los recursos del AnP que nos interesan y luego limpiamos los Paths del proyecto, dejando un entorno de inicio de aplicación más limpio.
+
+## Estructura AnP válida
+
+> Pregunta de **KyMAN**. **AnP** es un Framework diseñado por mi, aunque de su origen se basa en la experiencia de otros proyectos en las que entre otros parcipantes estaba 1noro, como fueron los proyectos *URfree*, *Error 418.2* y *Kyby*. El tema es que la filosofía de desarrollo de AnP, así como de los otros proyectos es de llevar el propio objeto AnP entre las diferentes librerías. A la hora de tipar dicha variable AnP en las librerías se da un caso muy peculiar en Python: se buclea infinitamente la carga de AnP por el "import" dentro de cada una de estas librerías. ¿Alguna idea de montarlo tal que quede mapeado como hasta ahora con el "AnPMap" sin que el bucle suceda?
+
+El tema está en que en cualquier desarrollo POO como Java o C# nos encontramos una estructura donde las librerías o paquetes del proyecto se encuentran en un entorno común, y cuando se hace uso de una librería del proyecto, ésta ya está iniciada desde el principio; sin embargo, en Python se carga un nuevo nivel de ejecución por cada librería, dando lugar al problema de que si tenemos un objeto AnP en una librería raíz y todas las demás extraen una variable de ésta, al intentar importar dicha librería buclea infinitamente por ese problema. La opción más viable a éste ámbito es no tipar dicha variable o poner como Any su propio tipado, sin embargo, ésto eliminaría dos opciones: el mapeado en el IDE; y la posibilidad de tipar frente a *MyPy* entre otras opciones. Por otro lado, si se hace uso del "AnPMap" sólo habría un problema: la posibilidad de tipar frente a *MyPy*.

Doc/dev/targets.md

@@ -0,0 +1,29 @@
+# Objetivos
+
+Aquí se plantearán los objetivos de cada miembro del equipo de desarrollo, así se podría ir haciendo un seguimiento del estado del proyecto.
+
+## 1noro y KyMAN
+
+- [X] Determinar un sistema de versionado del proyecto.
+- [ ] Estructurar proyecto.
+- [ ] Estructurar la documentación.
+- [ ] Acordar datos que se quieran almacenar con respecto a los Hashes de los ficheros y sus resultados de análisis.
+
+## KyMAN
+
+- [ ] Desarrollar base.
+- Desarrollar un lado cliente.
+    - [ ] Montar sistema de ejecución contra el lado cliente.
+    - [ ] Desarrollar entrada de parámetros.
+- Desarrollar un lado servidor.
+    - [ ] Montar sistema de ejecución contra el lado servidor.
+    - [ ] Estructurar base de datos.
+- Desarrollar un lado Tracker.
+- Debugear proyecto.
+- Documentar proyecto.
+
+## 1noro
+
+- [ ] Dockerización del proyecto.
+- Debugear proyecto.
+- Documentar proyecto.

Doc/donatives.md

@@ -0,0 +1,17 @@
+# Donativos
+
+Este proyecto no tiene ánimo de lucro, además de ser libre, abierto y gratuito para cualquiera, sin embargo, su mantenimiento físico en servidor tiene un gasto constante de energía eléctrica, consumo de Internet así como mantenimiento de los equipos que lo sostentan. Por esa razón se expone una forma de recaudar fondos que ayuden a dichas tareas, éstos, gestionados por los propios desarrolladores del proyecto. Tenemos las siguientes direcciones de Cryptomonedas con las que podéis colaborar.
+
+- **Bitcoin** *(BTC)*: 
+- **Litecoin** *(LTC)*: 
+- **Dogecoin** *(DOGE)*: 
+- **Dash** *(DASH)*: 
+
+Las direcciones de estas monedas pertenecen a un Wallet local privado creado a partir del Core sobre la cadena de Bloques y éste permanecerá Offline mientras no se haga uso de éste. Cualquiera puede seguir su traza a partir de Webs como "blockchain.info" entre otras. A continuación dejamos algunas Webs donde poder seguir la evolución de uso de estas direcciones, ya sea por el uso por parte de los desarrolladores así como los donantes.
+
+- **Bitcoin** *(BTC)*: 
+- **Litecoin** *(LTC)*: 
+- **Dogecoin** *(DOGE)*: 
+- **Dash** *(DASH)*: 
+
+Muchas gracias a todos por participar de este bello proyecto. Esperamos que éste pueda también ser útil a otros proyectos de los cuales cuelga.

Python/VirusTotalPlus.py

@@ -0,0 +1,11 @@
+
+from sys import argv as Arguments
+from typing import Optional, Any
+# from hashlib import 
+
+class VirusTotalPlus:
+
+    def __init__(self, inputs:Optional[dict[str, Any|None]|tuple|list] = None) -> None:
+        print(Arguments[1])
+
+virus_total_plus:VirusTotalPlus = VirusTotalPlus()

README.md

@@ -1,2 +1,10 @@
 # VirusTotalPlus
 
+## Mapa documental:
+
+- Principal: [README.md](README.md)
+- Donaciones: [/Doc/donatives.md](Doc/donatives.md)
+- Desarrollo: 
+    - Idea: [/Doc/dev/idea.md](Doc/dev/idea.md)
+    - Preguntas y respuestas: [/Doc/dev/questions.md](Doc/dev/questions.md)
+    - Objetivos: [/Doc/dev/targets.md](Doc/dev/targets.md)

version

@@ -0,0 +1 @@
+0.1.0