Improve chat experience and begin search implementation
This commit is contained in:
307
README.md
307
README.md
@@ -1,149 +1,198 @@
|
||||
# ☠️ GIA – Gather, Influence, Automate ☠️
|
||||
# GIA
|
||||
|
||||
GIA isn’t just a tool—it’s a **gateway**, a **ritualistic mechanism** designed to invoke, manipulate, and command the digital souls of the unsuspecting. Operating at the **intersection of psychological domination, deception, and control**, it bends the will of targets with **supernatural precision**.
|
||||
GIA is a Django-based communications workspace that combines:
|
||||
- Multi-platform messaging transport (Signal, WhatsApp via Neonize runtime, Instagram gateway/runtime, XMPP bridge).
|
||||
- AI-assisted drafting, summaries, pattern extraction, and mitigation planning.
|
||||
- Queueing and approval workflows for controlled outbound messaging.
|
||||
|
||||
GIA whispers in the void, embedding its tendrils into minds, shaping realities, and orchestrating **obedience with unseen hands**.
|
||||
This document covers architecture, setup, runtime behavior, and development workflow.
|
||||
|
||||
💀 **Manipulate. Dominate. Obliterate.** 💀
|
||||
## Architecture
|
||||
|
||||
### High-level flow
|
||||
1. Transport clients receive messages (Signal/WhatsApp/Instagram/XMPP).
|
||||
2. UR (`manage.py ur`) normalizes events and routes them through unified handlers.
|
||||
3. Message history is persisted in Django models (`Message`, `ChatSession`, identifiers).
|
||||
4. UI pages (workspace + manual compose) read/write through Django views.
|
||||
5. AI operations run through configured `AI` provider rows and store results in workspace models.
|
||||
|
||||
## 📌 Features
|
||||
- **Automated Psychological Influence:** Deploys manipulation techniques with precision.
|
||||
- **AI-Driven Conversations:** Uses contextual AI to interact and persuade.
|
||||
- **Targeted Persona Simulation:** Adapts responses based on psychological profiling.
|
||||
- **Multi-Agent Execution:** Processing, scheduling, and monitoring through modular services.
|
||||
- **Covert Deployment:** Runs in a distributed architecture with signal interception.
|
||||
### Core components
|
||||
- `core/modules/router.py`:
|
||||
- Unified Router entrypoint.
|
||||
- Starts transport clients.
|
||||
- Cross-protocol typing/read events.
|
||||
- `core/clients/`:
|
||||
- `signal.py` + `signalapi.py`: Signal transport integration.
|
||||
- `whatsapp.py`: Neonize-backed WhatsApp runtime client.
|
||||
- `instagram.py`: Instagram runtime/gateway integration.
|
||||
- `xmpp.py`: XMPP bridge client.
|
||||
- `transport.py`: Unified send/typing/QR API used by views/models.
|
||||
- `core/messaging/`:
|
||||
- AI execution wrapper.
|
||||
- Message history persistence and enrichment helpers.
|
||||
- `core/views/`:
|
||||
- `workspace.py`: AI workspace, insights, mitigation plans/artifacts.
|
||||
- `compose.py`: Manual chat mode, AI drafts/summary/engage shortcuts.
|
||||
- `signal.py`, `whatsapp.py`, `instagram.py`: Service setup/account pages.
|
||||
|
||||
## 🚀 Quickstart Guide
|
||||
### Data model highlights
|
||||
- `Person` + `PersonIdentifier`:
|
||||
- Identity layer across services (`signal`, `whatsapp`, `instagram`, `xmpp`).
|
||||
- `ChatSession` + `Message`:
|
||||
- Conversation storage.
|
||||
- Delivery/read metadata fields on `Message`.
|
||||
- `WorkspaceConversation`:
|
||||
- AI workspace context per person/thread.
|
||||
- Stability + commitment scores and confidence.
|
||||
- `WorkspaceMetricSnapshot`:
|
||||
- Historical metric snapshots for trend charts.
|
||||
- Pattern mitigation models:
|
||||
- `PatternMitigationPlan`, `Rule`, `Game`, `Correction`, exports, and auto settings.
|
||||
|
||||
### 🔧 Setting Up the Environment
|
||||
GIA runs inside **Podman containers**. Ensure you have **Podman** and **Podman Compose** installed. Docker might work. Results may vary.
|
||||
## Runtime services
|
||||
|
||||
1. **Clone the repository**
|
||||
```shell
|
||||
❯ git clone https://github.com/your-repo/gia.git
|
||||
❯ cd gia
|
||||
```
|
||||
`docker-compose.yml` defines these primary services:
|
||||
- `app`: Django web process.
|
||||
- `ur`: Unified Router runtime (transport clients).
|
||||
- `scheduling`: Scheduled jobs.
|
||||
- `migration`: Startup migrations.
|
||||
- `collectstatic`: Static asset collection.
|
||||
- `redis`: Cache/runtime signaling.
|
||||
- `signal-cli-rest-api`: Signal backend.
|
||||
|
||||
2. Set up the environment variables
|
||||
```shell
|
||||
❯ cp stack.env.example stack.env
|
||||
```
|
||||
## Installation
|
||||
|
||||
3. Edit `stack.env`
|
||||
### Prerequisites
|
||||
- Podman + Podman Compose (preferred in this repo), or Docker Compose.
|
||||
- Linux environment with bind-mount access for configured paths.
|
||||
|
||||
4. Build and start the containers
|
||||
```shell
|
||||
❯ make build
|
||||
❯ make run
|
||||
```
|
||||
|
||||
5. Run database migrations
|
||||
```shell
|
||||
❯ make migrate
|
||||
```
|
||||
|
||||
6. Create a superuser for Django Admin (optional but recommended)
|
||||
```shell
|
||||
❯ make auth
|
||||
```
|
||||
|
||||
7. Monitor logs
|
||||
```shell
|
||||
❯ make log
|
||||
```
|
||||
|
||||
## ⚙️ Deployment & Architecture
|
||||
### 🏗️ Services Overview
|
||||
| Service | Description |
|
||||
|----------------|-------------|
|
||||
| **app** | Main application container running **Uvicorn** for API handling. |
|
||||
| **db** | ManticoreSearch-based database backend. |
|
||||
| **redis** | Message queue for task distribution. |
|
||||
| **signal-cli** | Handles Signal communications. |
|
||||
| **processing** | Processes incoming messages and executes manipulations. |
|
||||
| **scheduling** | Handles timed tasks and influence scheduling. |
|
||||
| **migration** | Runs database migrations automatically on startup. |
|
||||
| **collectstatic** | Collects static files for Django before launch. |
|
||||
|
||||
## 🔥 Running Commands in a Container
|
||||
|
||||
You can execute management commands inside the app container using:
|
||||
```shell
|
||||
❯ docker-compose --env-file=stack.env run --rm app sh -c ". /venv/bin/activate && python manage.py <command>"
|
||||
```
|
||||
|
||||
## 🛑 Stopping GIA
|
||||
To stop all running services:
|
||||
```shell
|
||||
❯ make stop
|
||||
```
|
||||
|
||||
## 🕵️♂️ Operational Modes
|
||||
GIA runs in different operation modes set via OPERATION:
|
||||
| Mode | Description |
|
||||
|--------|-------------|
|
||||
| **uwsgi** | Runs behind Nginx for production. |
|
||||
| **dev** | Direct execution via Django's built-in server (development mode). |
|
||||
|
||||
|
||||
The default Podman entrypoint dynamically selects the correct process based on OPERATION.
|
||||
Be sure to uncomment nginx if using dev, as the shipped setup expects an external `nginx` instance to point to the GIA `uwsgi` sock:
|
||||
```
|
||||
location / {
|
||||
include include/xf-only.conf;
|
||||
include /etc/nginx/uwsgi_params;
|
||||
uwsgi_pass unix:///code/vrun/uwsgi-gia.sock;
|
||||
uwsgi_param Host $host;
|
||||
uwsgi_param X-Real-IP $remote_addr;
|
||||
uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
uwsgi_param X-Forwarded-Proto $http_x_forwarded_proto;
|
||||
}
|
||||
location /static {
|
||||
alias /code/xf/GIA/static/;
|
||||
}
|
||||
### 1) Clone and configure
|
||||
```bash
|
||||
git clone <your-repo-url> GIA
|
||||
cd GIA
|
||||
cp stack.env.example stack.env
|
||||
```
|
||||
|
||||
## 🔄 Persistent Data & Storage
|
||||
| Mount Path (Host) | Purpose |
|
||||
|---------------------------|-------------|
|
||||
| **docker/uwsgi.ini** | Configuration for **uWSGI** execution. |
|
||||
| **db.sqlite3** | SQLite database storage. |
|
||||
| **/code/vrun/** | Sockets shared between services. |
|
||||
| **signal-cli-config/** | Stores **Signal CLI** configuration and keys. |
|
||||
Edit `stack.env` with at least:
|
||||
- `SECRET_KEY`
|
||||
- `ALLOWED_HOSTS`
|
||||
- `CSRF_TRUSTED_ORIGINS`
|
||||
- `SIGNAL_NUMBER` (if Signal enabled)
|
||||
- `WHATSAPP_ENABLED=true|false`
|
||||
- `INSTAGRAM_ENABLED=true|false`
|
||||
- XMPP values if XMPP bridge is enabled
|
||||
|
||||
## 🔧 Additional Configuration
|
||||
### Django Environment Variables
|
||||
### 2) Build and start
|
||||
```bash
|
||||
make build
|
||||
make run
|
||||
```
|
||||
|
||||
The following are required for proper operation:
|
||||
```shell
|
||||
APP_PORT=5006
|
||||
REPO_DIR=.
|
||||
APP_LOCAL_SETTINGS=./app/local_settings.py
|
||||
APP_DATABASE_FILE=./db.sqlite3
|
||||
DOMAIN=example.com
|
||||
URL=https://example.com
|
||||
ALLOWED_HOSTS=example.com
|
||||
NOTIFY_TOPIC=example-topic
|
||||
CSRF_TRUSTED_ORIGINS=https://example.com
|
||||
DEBUG=y
|
||||
SECRET_KEY=
|
||||
STATIC_ROOT=/code/static
|
||||
REGISTRATION_OPEN=0
|
||||
OPERATION=uwsgi
|
||||
BILLING_ENABLED=0
|
||||
```
|
||||
### 3) Run migrations and create admin user
|
||||
```bash
|
||||
make migrate
|
||||
make auth
|
||||
```
|
||||
|
||||
These can be set inside `stack.env`.
|
||||
### 4) Follow logs
|
||||
```bash
|
||||
make log
|
||||
```
|
||||
|
||||
## ⚠️ Legal Disclaimer
|
||||
## Local developer commands
|
||||
|
||||
**GIA is provided for research and educational purposes only.**
|
||||
The developers and contributors are not responsible for any **misuse, illegal activities, or consequences** resulting from the use of this software.
|
||||
```bash
|
||||
make makemigrations
|
||||
make migrate
|
||||
make test
|
||||
```
|
||||
|
||||
By using GIA, you **acknowledge and agree** that:
|
||||
- You are solely responsible for your actions and compliance with applicable laws.
|
||||
- The software should not be used for unauthorized surveillance, coercion, or unethical influence.
|
||||
- The authors disclaim all liability for damages resulting from its use.
|
||||
Run ad-hoc manage commands:
|
||||
```bash
|
||||
docker-compose --env-file=stack.env run --rm app \
|
||||
sh -c ". /venv/bin/activate && python manage.py <command>"
|
||||
```
|
||||
|
||||
GIA is a tool that must be used responsibly. **Do not deploy it where it violates privacy laws, cybersecurity regulations, or ethical guidelines.**
|
||||
## Service setup pages
|
||||
|
||||
- Signal: `/services/signal/`
|
||||
- WhatsApp: `/services/whatsapp/`
|
||||
- Instagram: `/services/instagram/`
|
||||
|
||||
### WhatsApp pairing (Neonize)
|
||||
WhatsApp account linking expects a real Neonize runtime QR:
|
||||
1. Start stack with `WHATSAPP_ENABLED=true`.
|
||||
2. Ensure `ur` is running and WhatsApp runtime initialized.
|
||||
3. Open `Services -> WhatsApp -> Add Account`.
|
||||
4. Scan QR from WhatsApp Linked Devices.
|
||||
|
||||
If runtime QR is not available yet, UI returns a clear warning instead of a synthetic QR.
|
||||
|
||||
## Manual compose mode
|
||||
|
||||
- Route: `/compose/page/?service=<service>&identifier=<id>[&person=<uuid>]`
|
||||
- Features:
|
||||
- Chat thread view.
|
||||
- Send with two-step failsafe (`Arm Send` + `Confirm Intent`).
|
||||
- AI overlay tools:
|
||||
- Draft suggestions.
|
||||
- Conversation summary.
|
||||
- Quick engage send (shared framing, with its own two-step failsafe).
|
||||
- Click-outside dismiss behavior for AI overlays.
|
||||
|
||||
### Live updates and traffic minimization
|
||||
- WebSocket endpoint: `/ws/compose/thread/` (ASGI path).
|
||||
- Compose clients open one persistent WS per panel and receive incremental updates.
|
||||
- HTTP polling remains as a fallback at a slower interval when WS is unavailable.
|
||||
|
||||
This reduces repeated client GET requests compared with short polling loops.
|
||||
|
||||
## AI workspace
|
||||
|
||||
Route: `/ai/workspace/`
|
||||
|
||||
Key capabilities:
|
||||
- Summary, draft, pattern extraction.
|
||||
- Mitigation planning and artifacts (rules/games/corrections).
|
||||
- Insight metrics:
|
||||
- Detail pages per metric.
|
||||
- All-graphs page using Chart.js.
|
||||
- Scoring help page describing formulas and interpretation.
|
||||
|
||||
## Configuration notes
|
||||
|
||||
- `app/local_settings.py` is imported by `app/settings.py`.
|
||||
- Redis cache is expected at `/var/run/gia-redis.sock` unless overridden.
|
||||
- Service runtime URLs are read by `core/clients/transport.py`:
|
||||
- `SIGNAL_HTTP_URL`
|
||||
- `WHATSAPP_HTTP_URL`
|
||||
- `INSTAGRAM_HTTP_URL`
|
||||
|
||||
## ASGI / WebSocket note
|
||||
|
||||
`app/asgi.py` now multiplexes:
|
||||
- HTTP to Django ASGI app.
|
||||
- WebSocket path `/ws/compose/thread/` to compose realtime handler.
|
||||
|
||||
Use an ASGI-capable server in environments where WebSockets are required.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### “Send failed. Check service account state.”
|
||||
- Verify service account is linked and runtime is connected.
|
||||
- Check `ur` and service logs (`make log`).
|
||||
|
||||
### WhatsApp QR not available
|
||||
- Confirm `WHATSAPP_ENABLED=true`.
|
||||
- Confirm Neonize initializes in `ur` logs.
|
||||
- Retry Add Account after runtime is ready.
|
||||
|
||||
### No compose realtime updates
|
||||
- Verify ASGI deployment path and websocket upgrade support.
|
||||
- Fallback polling should still update messages on interval.
|
||||
|
||||
## Security and operational safety
|
||||
|
||||
- Outbound actions in manual compose/engage are guarded by two-step failsafe toggles.
|
||||
- Queue workflow exists for additional human approval in managed flows.
|
||||
- Deploy only with lawful consent and compliant data handling for your jurisdiction.
|
||||
|
||||
Reference in New Issue
Block a user