Quick Start Gorgona Stheno

[open-reserve]

Quick Start Gorgona Stheno

- Run the following command to create and start the container:
- Use the same command to update, it your personal settings will not be deleted.

Code:

sudo docker pull perynfr/gorgona_stheno:latest && \
sudo docker rm -f gorgona_stheno && \
sudo docker run -d \
  --name gorgona_stheno \
  --network host \
  --restart unless-stopped \
  -v /etc/gorgona:/etc/gorgona \
  -v /var/lib/gorgona:/var/lib/gorgona \
  perynfr/gorgona_stheno:latest && \
sudo docker image prune -f

example content:

📊 *Bitcoin Parser Report*
━━━━━━━━━━━━━━━━━━━━
✅ *Status:* Sync Completed
🧱 *Blocks:* 948485 ➔ 948485
📑 *Total Txs:* 3,072
💰 *Total Volume:* 8,125.91 BTC
💎 *Avg Volume:* 8,125.91 BTC/blk
⏱️ *Duration:* 26.9 sec
🚀 *Avg Speed:* 26.91 s/block
━━━━━━━━━━━━━━━━━━━━
🕒 UTC: 2026-05-08 16:47:13

https://talkimg.com/images/2026/05/08/UJkaha.png

[NotFuzzyWarm]

You need to link to where you got that code from.
I found it here https://forum.proxmox.com/threads/announce-gorgona-notification-bridge-for-proxmox-ve.183282/post-851630 just copying it is plagerism and you can be banned for that.
That said a description of what the code does and is for would be nice...

[open-reserve]

https://youtu.be/oyzwiag1Fcc

I wrote the code myself, so you can rest assured on that front

[open-reserve]

Gorgona Stheno v1.2.3
feat: implement dynamic theme support (Light, Catppuccin, Tokyo Night)

Code:

sudo docker pull perynfr/gorgona_stheno:latest && \
sudo docker rm -f gorgona_stheno && \
sudo docker run -d \
  --name gorgona_stheno \
  --network host \
  --restart unless-stopped \
  -v /etc/gorgona:/etc/gorgona \
  -v /var/lib/gorgona:/var/lib/gorgona \
  perynfr/gorgona_stheno:latest && \
sudo docker image prune -f && \
sleep 1 && sudo docker logs gorgona_stheno 2>&1 | grep "#"

[open-reserve]

In Gorgona 3.4.8 a substantial set of infrastructure improvements has been released. The server is no longer tied to hardcoded paths: all directories are now configurable. The parameters data_dir, conf_dir and log_file provide flexible control over the location of the database, peer cache, certificates and logs. This is especially useful for deployments in Docker, on embedded devices, or in corporate environments with their own data placement standards.

The second important change is the -c / --conf startup flag, which allows specifying an alternative path to the configuration file. This opens the way to running multiple gorgonad instances on a single machine with isolated state, which is convenient for testing, staging environments and building local mesh clusters. Hot reload via SIGHUP also works correctly with a custom configuration, so reconfiguration no longer requires a process restart.

In the same release the hash-chain logic has been significantly refined. After vacuum and after loading the database from disk the chain is now fully recomputed and becomes deterministic. All nodes that hold the same set of alerts always obtain identical prev_hash, curr_hash and last_hash values. This eliminates divergences that previously appeared because of different order of removal of expired records on different nodes.

Protection against Full Sync storms has also been strengthened. Cooldowns for repeated full synchronisations and a mechanism that prevents parallel heavy sync operations with multiple peers at the same time have been introduced. As a result, when an already synchronised node starts, the number of unnecessary BACKFILL operations is sharply reduced, and memory and CPU consumption when working with several peers becomes noticeably more stable.

Taken together these changes make the behaviour of the mesh network more predictable and resilient as the number of nodes and the volume of data grow.

Detailed technical documentation is available at:
https://github.com/psqlmaster/gorgona

You can explore the system through the control panel here:
https://46.138.247.148:8000/
Login credentials:
Username: demo
Password: demo

[open-reserve]

The “Head-Cutting” Paradox:
Classic blockchains or Git don’t support a sliding window—their chains grow indefinitely, consuming disk space (the entire Bitcoin blockchain weighs ~800 GB, and Git’s history stretches on forever).
But classic systems with a sliding window (Redis, Kafka, circular buffers) discard cryptographic hash chains because deleting old records causes the chain’s anchor to be lost.
Now this problem has been solved.

A deterministic Eventual Consistency model written in pure C was successfully implemented and validated through stress tests (using a simulated 100-second node isolation): The network automatically and seamlessly resolves forks during network failures (“split-brain”) by performing a local rebase of the chain based on the Snowflake ID without losing a single byte. For the community, this means absolute fault tolerance with near-zero resource consumption: nodes can lose connectivity, operate in isolated segments, and rejoin the mesh at any time -> within milliseconds, the cluster will mathematically restore the chronology and converge to a single state on its own, without manual intervention, without the risk of data loss, and without bloated mechanisms like Raft or blockchain consensus protocols, while keeping end-to-end (E2E) encryption intact.
https://github.com/psqlmaster/gorgona/discussions/15