X: Moved markdown files from Documentation to keep in sync
This commit is contained in:
@@ -0,0 +1,244 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>AssetAZ Documentation</title>
|
||||
<style>
|
||||
body {
|
||||
font-family: Arial, sans-serif;
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
background-color: #f8f9fa;
|
||||
color: #333;
|
||||
line-height: 1.6;
|
||||
}
|
||||
.container {
|
||||
width: 80%;
|
||||
max-width: 1000px;
|
||||
margin: auto;
|
||||
padding: 20px;
|
||||
}
|
||||
h1, h2 {
|
||||
color: #0056b3;
|
||||
}
|
||||
.section {
|
||||
margin-bottom: 40px;
|
||||
}
|
||||
.highlight {
|
||||
background-color: #e7f1ff;
|
||||
padding: 10px;
|
||||
border-left: 4px solid #0056b3;
|
||||
margin-top: 20px;
|
||||
}
|
||||
.footer {
|
||||
text-align: center;
|
||||
padding: 20px;
|
||||
border-top: 1px solid #ddd;
|
||||
margin-top: 40px;
|
||||
color: #777;
|
||||
}
|
||||
.token-logo {
|
||||
width: 100px;
|
||||
height: 100px;
|
||||
}
|
||||
ul.toc {
|
||||
background: #e7f1ff;
|
||||
padding: 16px;
|
||||
margin-bottom: 40px;
|
||||
border-left: 4px solid #0056b3;
|
||||
list-style: none;
|
||||
}
|
||||
ul.toc li {
|
||||
margin-bottom: 6px;
|
||||
}
|
||||
ul.toc a {
|
||||
color: #0056b3;
|
||||
text-decoration: none;
|
||||
}
|
||||
ul.toc a:hover {
|
||||
text-decoration: underline;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="container">
|
||||
<h1>AssetAZ Documentation</h1>
|
||||
<ul class="toc">
|
||||
<li><a href="#1-introduction-and-purpose">1. Introduction and Purpose</a></li>
|
||||
<li><a href="#2-hubs-and-terminals">2. Hubs and Terminals</a></li>
|
||||
<li><a href="#3-plugins-and-interfaces">3. Plugins and Interfaces</a></li>
|
||||
<li><a href="#4-interaction-with-nenjim">4. Interaction with Nenjim</a></li>
|
||||
<li><a href="#5-observables-and-subscribers">5. Observables and Subscribers</a></li>
|
||||
<li><a href="#6-assetaz-token-and-incentives">6. AssetAZ Token and Incentives</a></li>
|
||||
<li><a href="#7-peer-to-peer-and-oracles">7. Peer-to-peer and Oracles</a></li>
|
||||
<li><a href="#8-user-experience">8. User Experience</a></li>
|
||||
<li><a href="#9-transparency-trust-and-signed-builds">9. Transparency, Trust and Signed Builds</a></li>
|
||||
<li><a href="#10-distribution-and-installation">10. Distribution and Installation</a></li>
|
||||
<li><a href="#11-future-topics-todo">11. Future Topics (TODO)</a></li>
|
||||
</ul>
|
||||
|
||||
<div class="section" id="1-introduction-and-purpose">
|
||||
<h2>1. Introduction and Purpose</h2>
|
||||
<p>
|
||||
AssetAZ is <strong>not</strong> a finance application – it is a platform. Just like Windows is not Notepad
|
||||
or Word, AssetAZ is not a budgeting app or a wallet. AssetAZ is the foundation upon which other applications
|
||||
and plugins are built.
|
||||
</p>
|
||||
<p>
|
||||
Each user (human or AI) runs their own “AssetHub” – the central system that manages all their financial
|
||||
plugins and data. This means that all interaction with assets happens locally and under full user or AI
|
||||
control. AssetAZ is designed as a new standard for building financial software – open, decentralized, and
|
||||
flexible.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="section" id="2-hubs-and-terminals">
|
||||
<h2>2. Hubs and Terminals</h2>
|
||||
<p>
|
||||
An AssetHub runs in a single place – locally or in the cloud – and has one owner. Terminals are the devices
|
||||
that access the hub: this could be mobile apps, API clients, smartwatches, or even automated agents such as
|
||||
AIs. Some terminals have graphical UIs, others are completely invisible and operate only through messages or
|
||||
events.
|
||||
</p>
|
||||
<p>
|
||||
There is only <strong>one user per AssetAZHub</strong>. It is not a multi-user system, but a personal
|
||||
system. Access to external systems (such as API keys) is managed in Nenjim, not inside AssetAZ.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="section" id="3-plugins-and-interfaces">
|
||||
<h2>3. Plugins and Interfaces</h2>
|
||||
<p>
|
||||
AssetAZ itself can do almost nothing. All functionality comes from plugins. A plugin can be, for example, a
|
||||
wallet, a budgeting tool, or a plugin that connects to an exchange.
|
||||
</p>
|
||||
<p>
|
||||
Plugins communicate via API modules (interfaces), which can have many different implementations. This
|
||||
ensures that various components can be swapped out without breaking the whole system. A key feature of the
|
||||
AssetAZ ecosystem is that <strong>interfaces survive, but implementations can die</strong>.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="section" id="4-interaction-with-nenjim">
|
||||
<h2>4. Interaction with Nenjim</h2>
|
||||
<p>
|
||||
Nenjim is responsible for fetching, configuring, and delivering instances of components. AssetAZ simply
|
||||
asks Nenjim: “Give me a Bitcoin wallet.” Nenjim returns an instance that already works, because it’s
|
||||
configured with, for example, the correct private key.
|
||||
</p>
|
||||
<p>
|
||||
All configuration – such as access to external APIs – happens in Nenjim. Plugins in AssetAZ communicate
|
||||
with Nenjim via lazy-loaded and versioned components. This enables side-by-side execution of old and new
|
||||
versions of the same objects.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="section" id="5-observables-and-subscribers">
|
||||
<h2>5. Observables and Subscribers</h2>
|
||||
<p>
|
||||
Observables are plugins that provide information or events to others interested in receiving that
|
||||
information. Those who listen to the information are called 'Subscribers'. When everything flows through
|
||||
AssetAZ, it becomes possible to do centralized logging, analysis, and, for example, correct tax calculation
|
||||
(FIFO, etc.).
|
||||
</p>
|
||||
<p>
|
||||
A plugin acting as an Observable can also be a system that registers external events (such as water
|
||||
temperature). Observables can also be subscribed to over P2P – an AssetAZHub can subscribe to an observable
|
||||
from another hub and receive events as if they were local.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="section" id="6-assetaz-token-and-incentives">
|
||||
<h2>6. AssetAZ Token and Incentives</h2>
|
||||
<p>
|
||||
The AssetAZ token is used to pay developers, vote on decisions, and provide access to plugins and services.
|
||||
When a task needs to be solved, the price is estimated in tokens. The developer is then paid in tokens and
|
||||
can choose to keep them as an investment or sell them.
|
||||
</p>
|
||||
<p>
|
||||
Tokens can also be used by users who wish to have features developed, or as a reward for contributing
|
||||
knowledge, code, or data.
|
||||
</p>
|
||||
<p>
|
||||
The token’s price is determined indirectly through the “anchors” that users set themselves – one user may
|
||||
expect one token to equal one krone, while another may value it more highly. These differences create trade
|
||||
and speculation on a decentralized exchange, but can also easily be traded “over the counter” (OTC).
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="section" id="7-peer-to-peer-and-oracles">
|
||||
<h2>7. Peer-to-peer and Oracles</h2>
|
||||
<p>
|
||||
All AssetAZHubs run in a P2P network. This makes it possible to share services – for example, access to
|
||||
wallets, sensor data, or plugins – without giving access to the actual code. You can sell oracle services,
|
||||
such as measuring sea temperature every morning and making it available as an observable to other
|
||||
AssetAZHubs.
|
||||
</p>
|
||||
<p>
|
||||
This makes it possible to earn tokens on other types of assets than just financial – knowledge and data
|
||||
also become assets.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="section" id="8-user-experience">
|
||||
<h2>8. User Experience</h2>
|
||||
<p>
|
||||
The user experience in AssetAZ depends 100% on the terminal and plugins you use. An AI will never use a UI,
|
||||
while a human user may only use a smartwatch.
|
||||
</p>
|
||||
<p>
|
||||
A plugin can choose to render information in many ways – it’s similar to installing a graphics card in a
|
||||
computer. It translates data into something the user understands. It’s up to the terminal to present it.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="section" id="9-transparency-trust-and-signed-builds">
|
||||
<h2>9. Transparency, Trust and Signed Builds</h2>
|
||||
<p>
|
||||
All plugins are open source. The user can compile them themselves or trust builds that others have
|
||||
published and cryptographically signed.
|
||||
</p>
|
||||
<p>
|
||||
The user defines their own prioritized list of whom they trust. When a plugin needs to be installed, Nenjim
|
||||
tries to find a build that matches from one of the trusted signatures.
|
||||
</p>
|
||||
<p>
|
||||
It’s also possible to charge for signed builds, e.g., via the AssetAZ token, but this requires actively
|
||||
adding a payment plugin – Nenjim has no dependency on AssetAZ unless you want it.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="section" id="10-distribution-and-installation">
|
||||
<h2>10. Distribution and Installation</h2>
|
||||
<p>
|
||||
To make AssetAZ easy to install, it can be delivered as a ready-made image with Lightwale – a minimalist,
|
||||
immutable Linux system with Docker. There is only one container: Nenjim. It is configured to automatically
|
||||
start AssetAZ and the relevant plugins via a single configuration file.
|
||||
</p>
|
||||
<p>
|
||||
This makes it possible to deliver an entire hub with everything preconfigured – you just power it up.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="section" id="11-future-topics-todo">
|
||||
<h2>11. Future Topics (TODO)</h2>
|
||||
<ul>
|
||||
<li>Backup and restore via IPFS and encryption</li>
|
||||
<li>Security and privacy section</li>
|
||||
<li>AI as users and agents</li>
|
||||
<li>Governance and community</li>
|
||||
<li>User scenarios and fictional cases</li>
|
||||
<li>Semver-enforcer tool and build validation</li>
|
||||
<li>Further development of the observable concept</li>
|
||||
<li>Fluid trust and signature replacement</li>
|
||||
<li>Payment services for signed builds</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="footer">
|
||||
<p>AssetAZ – The foundation for open, decentralized, and programmable finance.</p>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
+110
@@ -0,0 +1,110 @@
|
||||
#<center><H1>AssetAZ<br>Documentation</H1></center>
|
||||
|
||||
**Indholdsfortegnelse:**
|
||||
<!-- TOC -->
|
||||
* [1. Introduktion og formål](#1-introduktion-og-formål)
|
||||
* [2. Hubs og terminaler](#2-hubs-og-terminaler)
|
||||
* [3. Plugins og interfaces](#3-plugins-og-interfaces)
|
||||
* [4. Interaktion med Nenjim](#4-interaktion-med-nenjim)
|
||||
* [5. Observables og Subscribers](#5-observables-og-subscribers)
|
||||
* [6. AssetAZ-token og incitamenter](#6-assetaz-token-og-incitamenter)
|
||||
* [7. Peer-to-peer og orakler](#7-peer-to-peer-og-orakler)
|
||||
* [8. Brugeroplevelse](#8-brugeroplevelse)
|
||||
* [9. Transparens, tillid og signerede builds](#9-transparens-tillid-og-signerede-builds)
|
||||
* [10. Distribution og installation](#10-distribution-og-installation)
|
||||
* [11. Fremtidige emner (TODO)](#11-fremtidige-emner-todo)
|
||||
<!-- TOC -->
|
||||
|
||||
## 1. Introduktion og formål
|
||||
AssetAZ er ikke en økonomiapplikation – det er en platform. Ligesom Windows ikke er Notepad eller Word, er AssetAZ
|
||||
ikke et budgetprogram eller en wallet. AssetAZ er selve fundamentet, som andre applikationer og plugins bygges ovenpå.
|
||||
|
||||
Hver bruger (menneske eller AI) kører sin egen “AssetHub” – det centrale system der håndterer alle ens økonomiske
|
||||
plugins og data. Det betyder, at al interaktion med aktiver foregår lokalt og under fuld bruger- eller AI-kontrol.
|
||||
AssetAZ er tænkt som en ny standard for at bygge økonomisk software – åben, decentral og fleksibel.
|
||||
|
||||
## 2. Hubs og terminaler
|
||||
En AssetHub kører ét sted – lokalt eller i skyen – og har én ejer. Terminaler er de enheder, som tilgår hubben:
|
||||
Det kan være mobilapps, API-klienter, smartwatches, eller endda automatiserede agenter som AI’er. Nogle terminaler
|
||||
har grafisk UI, andre er helt usynlige og virker kun gennem beskeder eller hændelser.
|
||||
|
||||
Der er kun én bruger pr. AssetAZHub. Det er ikke et multibrugersystem, men et personligt system. Adgang til
|
||||
eksterne systemer (som API-nøgler) styres i Nenjim og ikke inde i AssetAZ.
|
||||
|
||||
## 3. Plugins og interfaces
|
||||
AssetAZ selv kan næsten ingenting. Alt funktionalitet kommer fra plugins. Et plugin kan være fx en wallet,
|
||||
et budgetværktøj eller et plugin der forbinder til en børs.
|
||||
|
||||
Plugins kommunikerer gennem API-moduler (interfaces), som kan have mange forskellige implementationer. Det sikrer,
|
||||
at forskellige komponenter kan udskiftes, uden at det bryder hele systemet. En vigtig egenskab ved AssetAZ-økosystemet
|
||||
er, at **interfaces overlever, men implementationer kan dø**.
|
||||
|
||||
## 4. Interaktion med Nenjim
|
||||
Nenjim er ansvarlig for at hente, konfigurere og levere instanser af komponenter. AssetAZ spørger blot Nenjim:
|
||||
“Giv mig en Bitcoin wallet”. Nenjim returnerer en instans, der allerede virker, fordi den er konfigureret med f.eks.
|
||||
den korrekte private nøgle.
|
||||
|
||||
Al konfiguration – f.eks. adgang til eksterne API’er – sker i Nenjim. Plugins i AssetAZ kommunikerer med Nenjim
|
||||
via lazy-loaded og versionerede komponenter. Det giver mulighed for side-om-side afvikling af gamle og nye versioner
|
||||
af de samme objekter.
|
||||
|
||||
## 5. Observables og Subscribers
|
||||
Observables er plugins, som udbyder informationer eller events til andre som er interesseret i at modtage den
|
||||
information. Dem som lytter på informationerne kaldes 'Subscribers'. Når alt går gennem AssetAZ, bliver det muligt at
|
||||
lave central logging, analyse og f.eks. korrekt skatteberegning (FIFO, m.m.).
|
||||
Et plugin for agerer Observable, kan også være et system, der registrerer eksterne hændelser (som vandtemperaturen).
|
||||
Observables kan også abonneres på over P2P – en AssetAZHub kan abonnere på en observable fra en anden hub, og modtage
|
||||
events som var de lokale.
|
||||
|
||||
## 6. AssetAZ-token og incitamenter
|
||||
AssetAZ-token bruges til at betale udviklere, stemme om beslutninger og give adgang til plugins og services.
|
||||
Når en opgave skal løses, estimeres prisen i tokens. Udvikleren betales derefter i tokens og kan selv vælge, om de
|
||||
vil beholde dem som investering eller sælge dem.
|
||||
|
||||
Tokens kan også bruges af brugere, der ønsker at få udviklet features, eller som belønning for at bidrage med viden,
|
||||
kode eller data.
|
||||
|
||||
Prisen på en token fastsættes indirekte gennem de “ankre”, som brugere selv sætter – én bruger kan forvente, at én
|
||||
token svarer til én krone, mens en anden måske mener den er mere værd. Disse forskelle skaber handel og spekulation
|
||||
på en decentral børs, men kan også sagtens handles “på gaden” (Over the Counter (OTC))
|
||||
|
||||
## 7. Peer-to-peer og orakler
|
||||
Alle AssetAZHubs kører i et P2P-netværk. Det gør det muligt at dele services – fx adgang til wallets, sensordata,
|
||||
eller plugins – uden at give adgang til selve koden. Man kan sælge orakeltjenester, som f.eks. at måle havets
|
||||
temperatur hver morgen, og stille det til rådighed som en observable for andre AssetAZHubs.
|
||||
|
||||
Det gør det muligt at tjene tokens på andre typer aktiver end kun finansielle – viden og data bliver også til et aktiv.
|
||||
|
||||
## 8. Brugeroplevelse
|
||||
Brugeroplevelsen i AssetAZ afhænger 100% af den terminal og de plugins, man bruger. En AI vil aldrig bruge UI,
|
||||
mens en menneskelig bruger måske kun vil bruge et smartwatch.
|
||||
|
||||
Et plugin kan vælge at gengive information på mange måder – det minder om at sætte et grafikkort i en computer.
|
||||
Det oversætter data til noget brugeren forstår. Det er op til terminalen at præsentere det.
|
||||
|
||||
## 9. Transparens, tillid og signerede builds
|
||||
Alle plugins er open source. Brugeren kan compile dem selv, eller stole på builds, som andre har udgivet og
|
||||
kryptografisk signeret.
|
||||
Brugeren definerer selv en prioriteret liste over hvem de stoler på. Når et plugin skal installeres, prøver Nenjim
|
||||
at finde et build, der matcher fra én af de godkendte signaturer.
|
||||
|
||||
Det er også muligt at tage betaling for signerede builds, fx via AssetAZ-token, men det kræver, at man aktivt
|
||||
tilføjer et betalingsplugin – Nenjim har ingen afhængighed til AssetAZ medmindre man ønsker det.
|
||||
|
||||
## 10. Distribution og installation
|
||||
For at gøre AssetAZ nemt at installere, kan det leveres som et færdigt image med Lightwale – et minimalistisk,
|
||||
immutable Linux-system med Docker. Der er kun én container: Nenjim. Den konfigureres til, automatisk, at starte
|
||||
AssetAZ og de relevante plugins via én konfigurationsfil.
|
||||
|
||||
Det gør det muligt at levere en hel hub med alt prækonfigureret, som man bare starter op.
|
||||
|
||||
## 11. Fremtidige emner (TODO)
|
||||
- Backup og gendannelse via IPFS og kryptering
|
||||
- Sikkerhed og privacy-afsnit
|
||||
- AI som brugere og agenter
|
||||
- Governance og fællesskab
|
||||
- Brugerscenarier og fiktive cases
|
||||
- Semver-enforcer tool og build-validering
|
||||
- Videreudvikling af observable-konceptet
|
||||
- Flydende tillid og signaturudskiftning
|
||||
- Betalingstjenester for signerede builds
|
||||
+303
@@ -0,0 +1,303 @@
|
||||
#<center><H1>Evelyn<br>Documentation</H1></center>
|
||||
|
||||
**Indholdsfortegnelse:**
|
||||
<!-- TOC -->
|
||||
* [1. Introduktion formål og vision](#1-introduktion-formål-og-vision)
|
||||
* [1.1 Tokens som vedvarende aktiv – selv efter systemnedbrud](#11-tokens-som-vedvarende-aktiv--selv-efter-systemnedbrud)
|
||||
* [2. Tokenøkonomi og finansiering](#2-tokenøkonomi-og-finansiering)
|
||||
* [2.1 Allokering af overskud](#21-allokering-af-overskud)
|
||||
* [2.2 Buybacks og burn](#22-buybacks-og-burn)
|
||||
* [2.3 Finansiering af udvikling](#23-finansiering-af-udvikling)
|
||||
* [2.4 Ansvarsplacering og overskud](#24-ansvarsplacering-og-overskud)
|
||||
* [2.5 Neutralitet og ligestilling](#25-neutralitet-og-ligestilling)
|
||||
* [2.6 Vejen mod autonomi](#26-vejen-mod-autonomi)
|
||||
* [3. Tradingmotorens filosofi - AFETS](#3-tradingmotorens-filosofi---afets)
|
||||
* [3.1 Ikke-spekulativ tilgang](#31-ikke-spekulativ-tilgang)
|
||||
* [3.2 Søgning efter ligevægt](#32-søgning-efter-ligevægt)
|
||||
* [3.3 Anti-fragilitet](#33-anti-fragilitet)
|
||||
* [4. Trekantmodellen - Longs, Shorts og Margin](#4-trekantmodellen---longs-shorts-og-margin)
|
||||
* [5. Score-beregning – systemets beslutningsmotor](#5-score-beregning--systemets-beslutningsmotor)
|
||||
* [5.1 Principper for score-beregning](#51-principper-for-score-beregning)
|
||||
* [5.2 Beregning af score for åbning af positioner](#52-beregning-af-score-for-åbning-af-positioner)
|
||||
* [5.3 Straf for store positioner (penalty)](#53-straf-for-store-positioner-penalty)
|
||||
* [5.4 Beregning af score for lukning af positioner](#54-beregning-af-score-for-lukning-af-positioner)
|
||||
* [5.5 Fleksibilitet og udvikling](#55-fleksibilitet-og-udvikling)
|
||||
* [6. Iteration og rebalancering](#6-iteration-og-rebalancering)
|
||||
* [7. Likviditetsstyring og gearing](#7-likviditetsstyring-og-gearing)
|
||||
* [7.1 Tærskler og dvale](#71-tærskler-og-dvale)
|
||||
* [8. Risici, fail-safes og antifragilitet](#8-risici-fail-safes-og-antifragilitet)
|
||||
* [9. Udvikling, YouTrack-integration og offentlig gennemsigtighed](#9-udvikling-youtrack-integration-og-offentlig-gennemsigtighed)
|
||||
* [10. Fremtidige emner / TODO](#10-fremtidige-emner--todo)
|
||||
<!-- TOC -->
|
||||
|
||||
## 1. Introduktion formål og vision
|
||||
Evelyn er et proprietært trading-plugin bygget oven på AssetAZ-platformen. Evelyn er ikke open source og er
|
||||
ikke designet til at blive kørt af andre. Ingen andre end udvikleren har, på nuværende tidspunkt, adgang til at
|
||||
bruge, køre eller analysere den. Evelyn eksisterer udelukkende som en privat og beskyttet komponent i et større,
|
||||
decentraliseret økosystem.
|
||||
|
||||
Der arbejdes hen imod, at Evelyn, med tiden, bliver en fuldt autonom enhed med egen kapital og kontrol, hvor ikke
|
||||
engang udvikleren har adgang til beslutningstagen eller de midlerne – kun mulighed for at interagere
|
||||
på lige fod med øvrige investorer.
|
||||
|
||||
Evelyn er ikke designet til at maksimere profit for ejeren i klassisk forstand. Evelyn er en blackbox, som
|
||||
eksterne investorer kan interagere med. Al profit, Evelyn genererer gennem bl.a. trading, kanaliseres
|
||||
tilbage i systemet: til egen drift (hosting, strøm og andre ressourcer), udvikling, polstring imod kriser,
|
||||
styrkelse af likviditet i trading pools samt tilbagekøb af de 'Evelyn IOU' tokens investorerne har købt.
|
||||
Den eneste kapital, der tilfalder Evelyn selv, er derfor kun den oprindelige likviditet skabt, da tokens
|
||||
blev solgt på det åbne marked – det, man kan betragte som hovedstolen på de gældsbeviser, Evelyns IOU tokens
|
||||
repræsenterer.
|
||||
Evelyn selv tjener ikke på trading, men bruger trading som et værktøj til at styrke systemet og servicere sine
|
||||
gældsforpligtelser.
|
||||
Når Evelyn senere har opbygget en stor egenkapital, vil den anvende en del af denne kapital til filantropisk
|
||||
støtte i samfundet.
|
||||
|
||||
Evelyn distribueres teknisk som enhver anden Nenjim-komponent, men er ikke offentligt registreret, hvilket gør
|
||||
den praktisk talt usynlig for andre brugere. Denne designbeslutning understøtter Evelyns rolle som en blackbox
|
||||
til kapitalopbygning og senere filantropisk støtte. Evelyn anvender AFETS-princippet for antifragilitet i sin
|
||||
tradingstrategi og sikrer løbende systemstabilitet ved at geninvestere profit i likviditetsstyrkelse,
|
||||
udvikling og opkøb af Evelyn IOU-tokens.
|
||||
|
||||
I fremtiden vil eksterne investorer, via tokens, kunne stemme om, hvilke projekter Evelyn skal støtte.
|
||||
|
||||
### 1.1 Tokens som vedvarende aktiv – selv efter systemnedbrud
|
||||
En særlig egenskab ved Evelyns design er, at Evelyn tokens fortsætter med at eksistere og blive handlet på
|
||||
decentraliserede børser, selv hvis Evelyn selv ophører med at fungere – f.eks. på grund af likvidering af alle
|
||||
positioner eller markedsmæssige sammenbrud.
|
||||
|
||||
Det betyder, at investorers kapital ikke går tabt, selv hvis Evelyn som tradingmaskine fejler. Tokens kan stadig have
|
||||
værdi og kan handles frit. Det giver mulighed for, at tokens over tid bliver købt op igen – ikke nødvendigvis af
|
||||
Evelyn, men f.eks. af den oprindelige udvikler med anden indkomst, eller af markedet selv, hvis der opstår ny interesse.
|
||||
|
||||
Denne adskillelse mellem token og motor gør, at Evelyn ikke skaber afhængighed, men i stedet definerer en langsigtet
|
||||
økonomisk kontrakt mellem projekt og investor, som potentielt kan indfries, selv hvis omstændighederne ændrer
|
||||
sig drastisk.
|
||||
|
||||
## 2. Tokenøkonomi og finansiering
|
||||
Evelyn bruger en intern token kaldet 'Evelyn IOU' som sin primære finansieringsmekanisme. Denne token er en form for
|
||||
gældbevis, som Evelyn selv udsteder i de tilfælde, hvor der ikke er tilstrækkelig likviditet til at fortsætte
|
||||
handelsaktiviteterne. Tokens bliver udstedt “ud af den blå luft” og solgt på en decentraliseret børs.
|
||||
Provenuet fra salget bliver brugt direkte som handelskapital i systemet. Det er vigtigt at forstå, at 'Evelyn IOU'
|
||||
ikke giver krav på en fast tilbagebetaling – det er en markedsbaseret mekanisme, hvor investorerne forventer at
|
||||
kunne sælge deres tokens igen til en højere pris, efterhånden som Evelyn opnår overskud.
|
||||
|
||||
### 2.1 Allokering af overskud
|
||||
Når Evelyn genererer overskud gennem sin tradingstrategi, bliver dette overskud automatisk allokeret i forskellige
|
||||
procentandele til følgende områder:
|
||||
|
||||
1) Geninvestering i nye positioner
|
||||
1) Reduktion af gearing (hvis anvendt)
|
||||
1) Afbetaling af gæld for tidligere tab
|
||||
1) Tilførsel af likviditet i Evelyn IOU-tokenets pool
|
||||
1) Betaling for udvikling og vedligehold, samt drift af systemet
|
||||
1) Buyback og burn af tokens
|
||||
|
||||
Fordelingerne er hardcoded og justeres manuelt af udvikleren, når behovet opstår. Evelyn foretager ikke selv
|
||||
beslutninger om fordelingen. Det er et lukket kredsløb, hvor alt overskud anvendes til enten at styrke systemet,
|
||||
sikre tokenens pris eller muliggøre ny funktionalitet.
|
||||
|
||||
### 2.2 Buybacks og burn
|
||||
En af de vigtigste mekanismer i Evelyn er det automatiske tilbagekøb og efterfølgende burn af 'Evelyn IOU' tokens.
|
||||
En fast procentdel af overskuddet anvendes på at købe tokens på markedet – uanset den aktuelle pris – og brænde
|
||||
dem permanent. Dette reducerer det samlede udbud og skaber et kontinuerligt deflationært pres, hvilket typisk er
|
||||
positivt for investorerne. Buyback-strategien sikrer, at investorerne får en god pris for deres tokens, når det
|
||||
udnyttes at ikke alle investorer sælger på samme tid, da de har forskellige forventninger til prisen.
|
||||
|
||||
### 2.3 Finansiering af udvikling
|
||||
Udvikling i Evelyn sker gennem en task-baseret model. Alle opgaver oprettes i IntelliJ YouTrack og bliver
|
||||
individuelt prissat i 'Evelyn IOU'. Når en opgave er funded – enten af Evelyn selv (via overskud) eller af en
|
||||
ekstern sponsor, påbegyndes arbejdet. Når opgaven er markeret som “Done”, udbetales den aftalte mængde tokens
|
||||
til udvikleren. Alle transaktioner er offentligt synlige via SolScan, hvilket sikrer gennemsigtighed og gør det
|
||||
muligt at verificere, at en opgave faktisk funded, gennemført og til sidst, betalt for.
|
||||
|
||||
Det betyder også, at eksterne investorer kan vælge at støtte specifikke funktioner, hvis de tror på Evelyns fremtid,
|
||||
selv i perioder hvor Evelyn ikke selv har midler. Det gør tokenen både til en investeringsenhed og et værktøj til at
|
||||
drive udvikling fremad.
|
||||
|
||||
### 2.4 Ansvarsplacering og overskud
|
||||
Det er vigtigt at understrege, at al profit går til systemet og dets investorer – ikke til ejeren som personlig
|
||||
gevinst. Den eneste kapital, der kan betragtes som tilhørende ejeren, er den oprindelige likviditet, der blev tilført,
|
||||
da tokens blev solgt. Evelyn bruger alt efterfølgende overskud til at servicere sin egen gæld, styrke balancen og
|
||||
understøtte videreudvikling.
|
||||
|
||||
### 2.5 Neutralitet og ligestilling
|
||||
Selvom Evelyn er udviklet og ejet af én person, er selve systemets økonomiske struktur designet til at være neutral.
|
||||
Hvis ejeren ønsker yderligere gevinst ud over den oprindelige hovedstol fra tokensalget, skal det ske ved at købe
|
||||
Evelyn IOU-tokens på lige fod med alle andre investorer. Der er ingen bagdør, ingen særbehandling og ingen
|
||||
skjulte fordele.
|
||||
|
||||
Systemet fungerer dermed næsten som et selvejende kredsløb, hvor udvikleren er en deltager på linje med alle andre.
|
||||
Det er ikke systemets opgave at betale sin ejer – det er systemets opgave at holde balancen, betale sin gæld og
|
||||
skabe værdi for markedet.
|
||||
|
||||
### 2.6 Vejen mod autonomi
|
||||
Der er en overordnet ambition om, at Evelyn på sigt skal blive et fuldt selvforvaltende system, hvor ikke engang den
|
||||
oprindelige udvikler har adgang til dens kapital. Det betyder, at den handelskapital, Evelyn genererer eller modtager
|
||||
via tokensalg, ikke skal kunne trækkes ud af systemet af nogen – heller ikke ejeren.
|
||||
|
||||
Idealet er, at Evelyn på et tidspunkt fungerer som en økonomisk organisme med sin egen vilje. En enhed med egne midler,
|
||||
egne prioriteter og egne beslutninger – hvor adgang til ressourcer kun kan opnås gennem markedet eller gennem faktisk
|
||||
bidrag til systemet.
|
||||
|
||||
Udvikleren bliver i så fald ikke systemets ejer, men blot én deltager blandt andre, der kan tilbyde at løse opgaver
|
||||
eller investere i tokens. Det er en ny måde at tænke softwareejerskab på: ikke som besiddelse, men som
|
||||
fællesskab og udveksling.
|
||||
|
||||
## 3. Tradingmotorens filosofi - AFETS
|
||||
Evelyn bygger hele sin handelsstrategi på det, der kaldes AFETS – Anti-Fragile Equilibrium Trading System. Systemet
|
||||
er konstrueret til ikke blot at tåle markedets svingninger, men at blive stærkere af dem. Det er en strategi, hvor
|
||||
målet ikke er spekulation eller profitmaksimering, men balancering. Evelyn forsøger ikke at forudsige fremtiden.
|
||||
Den handler udelukkende på, hvad der er sandt lige nu.
|
||||
|
||||
### 3.1 Ikke-spekulativ tilgang
|
||||
I modsætning til traditionelle tradingbots, der forsøger at gætte fremtidige prisbevægelser ud fra mønstre, nyheder
|
||||
eller tekniske indikatorer, arbejder Evelyn retrospektivt. Den bygger sine beslutninger på observerede forhold
|
||||
i nuet – og aldrig på spekulation. Det gør den ekstremt robust over for chok, kriser og nyhedsdrevne spikes, fordi
|
||||
den ikke lader sig rive med af narrativer, der måske viser sig forkerte.
|
||||
|
||||
### 3.2 Søgning efter ligevægt
|
||||
Hele grundideen i AFETS er at bevare en økonomisk ligevægt. Det betyder, at Evelyn hellere vil være stabil end
|
||||
aggressiv. Den ser det som en styrke at overleve, ikke at vinde stort. Det gør systemet egnet til lang levetid
|
||||
og kontinuerlig forbedring – og til at undgå store tab.
|
||||
|
||||
### 3.3 Anti-fragilitet
|
||||
Konceptet om antifragilitet kommer fra Nassim Nicholas Taleb og beskriver systemer, der ikke bare er robuste,
|
||||
men som faktisk vokser af kaos og stress. Evelyn søger netop dette: at komme styrket ud af udsving i markedet.
|
||||
Når en ubalance opstår, bruger Evelyn muligheden for at lukke positioner med profit og styrke sin margin.
|
||||
Når tingene vender, er den klar til at tage det næste sving med endnu større stabilitet.
|
||||
|
||||
Evelyn vinder altså ikke ved at være den hurtigste eller smarteste, men ved at være den mest tålmodige og
|
||||
bedst balancerede. Det er ikke et system, der skal slå markedet – det er et system, der skal overleve og
|
||||
tilpasse sig det.
|
||||
|
||||
## 4. Trekantmodellen - Longs, Shorts og Margin
|
||||
Evelyn opererer med en unik model, hvor dens samlede kapital opdeles i tre hovedkomponenter: long-positioner,
|
||||
short-positioner, og available margin. Disse tre komponenter udgør tilsammen en trekant, hvor hver side repræsenterer
|
||||
en tredjedel af den samlede værdi. Målet er, at hver af balance imellem de tre dele altid tilstrebes, så hver side
|
||||
af trekanten udgør cirka 33% af den samlede kapital.
|
||||
|
||||
Long-positionerne repræsenterer de handler, hvor Evelyn satser på, at værdien af et givent aktiv vil stige.
|
||||
Short-positionerne er de handler, hvor Evelyn forventer, at værdien vil falde.
|
||||
Available margin er den likvide kapital, som ikke er bundet i positioner, og som er klar til at blive brugt til nye
|
||||
handler eller til at genoprette balance, hvis det bliver nødvendigt.
|
||||
|
||||
Når der opstår ubalance i trekanten, for eksempel hvis long-positionerne stiger i værdi og dermed fylder mere
|
||||
end 33% af den samlede kapital, vil Evelyn iværksætte en rebalancering. Det gør den ved at lukke en del af de
|
||||
kontrakter fra en af de overrepræsenterede positioner og føre værdien tilbage til 'available margin'.
|
||||
|
||||
I næste iteration kan Evelyn så vurdere, om available margin nu er for høj og derved bruge noget af den til at åbne
|
||||
nye short-positioner for at genoprette balancen. Målet er altid at bringe alle tre komponenter tilbage til en
|
||||
ligelig fordeling.
|
||||
|
||||
Når short-positionerne stiger i værdi (og derved er i tab), kan Evelyn stå i en situation, hvor den har svært ved at
|
||||
lukke disse positioner uden at forværre ubalancen. For at håndtere dette, vil Evelyn typisk skiftevis lukke en long
|
||||
og en short i en form for “tiptoe”-mønster. Denne metode gør det muligt for Evelyn at balancere sine positioner over
|
||||
tid, uden at skabe pludselige, store udsving i systemet.
|
||||
|
||||
## 5. Score-beregning – systemets beslutningsmotor
|
||||
Score-beregningen er hjertet i Evelyns beslutningsproces. Når Evelyn skal vælge, hvilke positioner der skal åbnes
|
||||
eller lukkes, bruger den en scorefunktion til at vurdere alle muligheder objektivt og konsekvent. Formålet er at
|
||||
vælge den position, der skaber mest balance og bedst forbedrer porteføljens risiko/profit-forhold.
|
||||
|
||||
### 5.1 Principper for score-beregning
|
||||
- Evelyn vurderer altid alle kandidater (f.eks. alle mulige nye kontrakter, eller alle åbne positioner, der kan lukkes).
|
||||
- For åbning af positioner bruges både markedsdata (pris, kontraktstørrelse, gearing mv.) og et strafsystem, så ingen
|
||||
positioner bliver for store i forhold til de andre.
|
||||
- For lukning af positioner er scoren pt. simplere (procentuel gevinst/tab), men kan udvikles videre i fremtiden.
|
||||
|
||||
### 5.2 Beregning af score for åbning af positioner
|
||||
Når en ny kontrakt skal vælges, samles alle relevante input i en record (se kode-eksempel i appendiks). Beregningen
|
||||
vurderer blandt andet:
|
||||
- Hvilken profitforbedring opnås, hvis prisen udvikler sig fra nuværende til “efter trade”-niveau?
|
||||
- Hvor stor er profitten i forhold til den kapital, der bruges?
|
||||
- Hvor meget spredes risikoen ved at vælge denne position frem for at forstørre eksisterende?
|
||||
|
||||
Eksempel på scoring:
|
||||
- Beregn forskel mellem nuværende og fremtidig pris for aktivet (alt efter om det er en long eller short)
|
||||
- Udregn profit for denne prisændring
|
||||
- Relativ profit (profit pr. dollar brugt)
|
||||
- Summér til en endelig score: score = 1 + (relativ profit)
|
||||
|
||||
### 5.3 Straf for store positioner (penalty)
|
||||
For at undgå, at Evelyn bygger uforholdsmæssigt store positioner i ét aktiv, justeres scoren nedad for de kandidater,
|
||||
hvor den nuværende position allerede er større end gennemsnittet. Straf-funktionen dæmper scoren med en faktor,
|
||||
der vokser med afvigelsen fra gennemsnittet:
|
||||
|
||||
- Hvis positionen > gennemsnittet, så:
|
||||
- adjustedScore = rawScore / (1 + K * (ratio-1)^2)
|
||||
|
||||
Her er K en justerbar parameter, der bestemmer, hvor hårdt store positioner straffes.
|
||||
|
||||
### 5.4 Beregning af score for lukning af positioner
|
||||
For at lukke positioner anvender Evelyn pt. en simpel score baseret på den procentuelle gevinst eller tab,
|
||||
positionen har. Listen af potentielt lukkede positioner sorteres på denne score, og den bedste vælges.
|
||||
|
||||
### 5.5 Fleksibilitet og udvikling
|
||||
Alle scorefunktioner er implementeret, så de kan udskiftes, tunes og forbedres uden at bryde resten af systemet.
|
||||
Det gør det let at eksperimentere med nye logikker og justere for mere optimal risikospredning eller
|
||||
profitforbedring over tid.
|
||||
|
||||
## 6. Iteration og rebalancering
|
||||
Evelyn arbejder i faste iterationer, hvor den med jævne mellemrum – for eksempel hver time – evaluerer sine
|
||||
positioner. I hver iteration summerer Evelyn værdien af alle longs, alle shorts og den available margin for
|
||||
at sikre, at de tre komponenter er i balance. Hvis for eksempel long-positionerne bliver for store i forhold
|
||||
til de to andre dele, vil Evelyn lukke nogle af disse positioner og føre værdien tilbage til den available
|
||||
margin. Dette sikrer, at der ikke opstår en skævvridning, som kan true systemets stabilitet.
|
||||
|
||||
Rebalanceringen foregår altid med forsigtighed for at undgå overreaktioner, og justeres i små skridt, så systemet
|
||||
altid er i stand til at absorbere markedsudsving uden at tabe balancen.
|
||||
|
||||
## 7. Likviditetsstyring og gearing
|
||||
Evelyns likviditetsstyring er bygget op omkring klare tærskler og trin:
|
||||
- Normalt drift: Systemet forsøger at holde available margin på ca. 33%. Det sker ved balancering mellem long-,
|
||||
short-positioner og likvide midler.
|
||||
- Faldende tilgængeling margin: Hvis available margin falder under et defineret threshold (fx 10%), begynder Evelyn
|
||||
at øge gearingen på eksisterende positioner. Det frigør kapital, men bruges kun til at holde margin på minimum,
|
||||
ikke til at tage flere handler.
|
||||
- Kritisk lav margin: Hvis gearing ikke kan øges yderligere, og marginen rammer 0%, vil Evelyn udstede nye
|
||||
'Evelyn IOU' tokens som sidste udvej for at skaffe ekstern likviditet.
|
||||
|
||||
Når markedet normaliseres, nedbringer Evelyn langsomt gearingen over tid, finansieret af trading-overskud. Det
|
||||
betyder, at systemet efter en krise ikke straks går tilbage til spot-only, men gradvist heler balancen, lidt som
|
||||
et brækket ben, der får tid til at blive stærkt igen. Under hele processen prioriteres stabilitet over aggressivitet.
|
||||
|
||||
### 7.1 Tærskler og dvale
|
||||
Hvis ubalancen bliver for ekstrem – eksempelvis hvis short-siden eller gearing dominerer – kan Evelyn gå i
|
||||
dvale (pause al trading). Dette sikrer, at systemet ikke vælter, men tålmodigt venter på bedre markedsforhold
|
||||
eller ny kapitaltilførsel.
|
||||
|
||||
## 8. Risici, fail-safes og antifragilitet
|
||||
Evelyn er designet til at overleve og vokse af markedsstress, ikke blot at modstå det. Systemet har flere
|
||||
indbyggede mekanismer for at sikre antifragilitet:
|
||||
|
||||
- Fail-safe-mode: Hvis balancen mellem longs, shorts og margin bliver for skæv (fx hvis short-siden vokser
|
||||
for meget), kan Evelyn sætte sig selv på pause og stoppe al trading. Det sikrer, at systemet aldrig tvinges ud i
|
||||
ruinøse handler, men hellere venter tålmodigt på, at markedet vender, eller på at der tilføres ny margin.
|
||||
- Tærskelbaseret gearing og tokensalg: Evelyn bruger gearing kun som midlertidigt værktøj, og kun til at holde
|
||||
marginen lige over det kritiske minimum. Kun hvis dette fejler, udstedes nye tokens.
|
||||
- Tålmodighed over panik: Systemet undgår bevidst at tage hurtige, risikable beslutninger under stress – i stedet
|
||||
nedbringer det gearing og bygger langsomt balancen op igen.
|
||||
- Antifragilitet: Når Evelyn oplever markedskaos, bliver den stærkere, fordi dens strategi bygger på at udnytte
|
||||
ubalancer og reinvestere gevinsterne i at reparere systemet.
|
||||
|
||||
## 9. Udvikling, YouTrack-integration og offentlig gennemsigtighed
|
||||
Evelyns udviklingsmodel bygger på transparens og dokumenterede processer, selvom selve koden ikke er offentlig:
|
||||
- YouTrack-integration: Alle udviklingsopgaver oprettes og prissættes i EVELYN-tokens i YouTrack. Når en opgave er
|
||||
funded (af Evelyn selv eller af eksterne), igangsættes arbejdet. Når den er færdig, udbetales tokens til udvikleren,
|
||||
og transaktionen logges med ID på SolScan.
|
||||
- Offentlig revision: Enhver kan følge med i, hvilke opgaver der er funded, hvem der har modtaget betaling, og
|
||||
hvilken transaktion der ligger bag. Dermed er der fuld gennemsigtighed i systemets økonomi uden at afsløre den
|
||||
underliggende strategi.
|
||||
- Funding af opgaver: Opgaver bliver kun udført, hvis de er funded. Investorer og udviklere kan selv gå ind og
|
||||
sponsorere opgaver, hvis de tror på systemet.
|
||||
|
||||
## 10. Fremtidige emner / TODO
|
||||
- Bedre adgangsbegrænsning: Overvej, hvordan private plugins i Nenjim kan beskyttes bedre end “security by obscurity”.
|
||||
- Automatisk tuning af allokeringsprocenter: Undersøg muligheder for at lade systemet lære og tilpasse sin interne
|
||||
kapitalallokering over tid (AI-drevet tuning).
|
||||
- Flere tradingstrategier: Udvid Evelyn med mulighed for at tilføje alternative, konkurrerende scoring-algoritmer.
|
||||
- Bedre penalty-funktioner ved close: Implementer og test mere avanceret straflogik for lukning af positioner.
|
||||
- Ekstra fail-safes: Tilføj flere automatiske stopmekanismer for at undgå at systemet “vipper omkuld” i
|
||||
ekstreme markedsbevægelser.
|
||||
- Open API for ekstern integration: Gør det muligt at tilføje eksterne datafeeds, udveksle signaler med andre
|
||||
systemer, eller automatisere funding-opgaver.
|
||||
@@ -0,0 +1,129 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<title>Nenjim Documentation</title>
|
||||
<style>
|
||||
body {
|
||||
font-family: Arial, sans-serif;
|
||||
background-color: #f8f9fa;
|
||||
color: #333;
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
}
|
||||
.container {
|
||||
width: 80%;
|
||||
max-width: 1000px;
|
||||
margin: auto;
|
||||
padding: 20px;
|
||||
background-color: #fff;
|
||||
}
|
||||
h1, h2 {
|
||||
color: #0056b3;
|
||||
}
|
||||
.toc {
|
||||
background: #e7f1ff;
|
||||
padding: 10px 20px;
|
||||
border-left: 4px solid #0056b3;
|
||||
margin-bottom: 30px;
|
||||
}
|
||||
.footer {
|
||||
text-align: center;
|
||||
padding: 20px;
|
||||
border-top: 1px solid #ddd;
|
||||
margin-top: 40px;
|
||||
color: #777;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="container">
|
||||
<h1>Nenjim Documentation</h1>
|
||||
<div class="toc">
|
||||
<h2>Table of Contents</h2>
|
||||
<ul>
|
||||
<li><a href="#1-introduction-to-nenjim">1. Introduction to Nenjim</a></li>
|
||||
<li><a href="#2-versioning-and-dependencies">2. Versioning and Dependencies</a></li>
|
||||
<li><a href="#3-updates-and-security">3. Updates and Security</a></li>
|
||||
<li><a href="#4-payment-system-and-integration-with-assetaz">4. Payment System and Integration with AssetAZ</a></li>
|
||||
<li><a href="#5-backing-store-and-flexibility">5. Backing Store and Flexibility</a></li>
|
||||
<li><a href="#6-standardized-and-automated-package-management">6. Standardized and Automated Package Management</a></li>
|
||||
<li><a href="#7-importance-of-semantic-versioning">7. Importance of Semantic Versioning</a></li>
|
||||
<li><a href="#8-integration-of-plugins-and-central-registry">8. Integration of Plugins and Central Registry</a></li>
|
||||
<li><a href="#9-integration-with-assetaz-and-economic-activity">9. Integration with AssetAZ and Economic Activity</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
<h1>Nenjim Documentation</h1>
|
||||
<h2 id="1-introduction-to-nenjim">1. Introduction to Nenjim</h2>
|
||||
<p>Nenjim is an innovative system that enables handling multiple versions of software packages simultaneously.</p>
|
||||
<p>The system solves the challenge of dependencies and versioning by using unique version numbers in the naming of
|
||||
packages,</p>
|
||||
<p>which ensures that multiple versions of the same software package can exist side by side without conflicts.</p>
|
||||
|
||||
<h2 id="2-versioning-and-dependencies">2. Versioning and Dependencies</h2>
|
||||
<p>Nenjim uses a method where packages are named with the version number directly in the package name. However,
|
||||
this is managed in so-called journals outside of the actual code, so that the Java code itself does not depend
|
||||
on Nenjim.</p>
|
||||
<p>This ensures that developers do not have to worry about version conflicts, as each dependency refers precisely
|
||||
to the version it needs. The system ensures that all necessary modules are available and kept up to date in
|
||||
the background.</p>
|
||||
|
||||
<h2 id="3-updates-and-security">3. Updates and Security</h2>
|
||||
<p>Nenjim automatically monitors for updates through what are called journals. If a security vulnerability is
|
||||
discovered in a particular version, the developers update the journal, and all NenjimHubs will automatically
|
||||
fetch the new secure version, or downgrade to a previous version until an update is ready. In this way,
|
||||
updates are distributed quickly and efficiently throughout the entire network.</p>
|
||||
|
||||
<h2 id="4-payment-system-and-integration-with-assetaz">4. Payment System and Integration with AssetAZ</h2>
|
||||
<p>To support payment for software packages, Nenjim integrates with AssetAZ. This means that developers can choose
|
||||
to receive payment for their packages either as a one-time fee, as a subscription, or per use. All transactions
|
||||
are handled via cryptocurrency.</p>
|
||||
|
||||
<h2 id="5-backing-store-and-flexibility">5. Backing Store and Flexibility</h2>
|
||||
<p>Nenjim provides complete flexibility regarding where data is stored. This can be via IPFS, in a local folder,
|
||||
or even in a database. The system is designed to be so flexible that developers can choose the solution that
|
||||
best fits their needs.</p>
|
||||
|
||||
<h2 id="6-standardized-and-automated-package-management">6. Standardized and Automated Package Management</h2>
|
||||
<p>One of the major advantages of Nenjim is that users no longer have to manually search for dependencies on the
|
||||
Internet. Nenjim uses a standardized method to automatically find and download packages, for example via IPFS.
|
||||
This means that all packages are easily accessible and can be retrieved in a consistent manner, which saves
|
||||
time and ensures a more streamlined experience for both developers and users.</p>
|
||||
|
||||
<h2 id="7-importance-of-semantic-versioning">7. Importance of Semantic Versioning</h2>
|
||||
<p>For Nenjim to function optimally, it is essential that all packages follow the principles of semantic versioning.
|
||||
This means that each version of a package clearly indicates whether it is a minor update, a bug fix, or a major,
|
||||
potentially incompatible change. By adhering to these versioning rules, Nenjim can easily and safely handle
|
||||
updates and ensure that the system is always stable and fully functional.</p>
|
||||
|
||||
<h2 id="8-integration-of-plugins-and-central-registry">8. Integration of Plugins and Central Registry</h2>
|
||||
<p>One of the unique advantages of using Nenjim is that applications can communicate directly with the NenjimHub to
|
||||
find and integrate new plugins. Through a global registry, applications can search for plugins that implement
|
||||
specific interfaces of certain versions, making it easy to extend their functionality. This flexibility allows
|
||||
users to add new features or improvements, such as codecs for a video player, while also being able to see the
|
||||
cost of different plugins.</p>
|
||||
|
||||
<h2 id="9-integration-with-assetaz-and-economic-activity">9. Integration with AssetAZ and Economic Activity</h2>
|
||||
<p>Nenjim is designed to be an open and free tool for managing dependencies, versioning, and the execution of
|
||||
software packages. The system can be used without any form of payment, and all basic features—such as local
|
||||
injection, dependency analysis, and dynamic classloading—are available without any economic interaction
|
||||
required.</p>
|
||||
<p>However, in cases where the user wants to make their software publicly available to others—for example, by
|
||||
propagating packages to a registry or selling their software—a small economic cost will be associated with
|
||||
these actions.</p>
|
||||
<p>To support this kind of activity, Nenjim uses the digital AssetAZ crypto token. This token is part of the
|
||||
broader AssetAZ platform and enables micropayments in connection with software distribution.</p>
|
||||
<p>By using a dedicated token, a decentralized and transparent settlement mechanism is achieved, while also
|
||||
creating a natural connection to AssetAZ, where the entire economic infrastructure is anchored.</p>
|
||||
<p>It is important to note that this integration does not limit the use of Nenjim in regular, non-commercial
|
||||
contexts, but as soon as you wish to publish and distribute software for commercial purposes—and thus also
|
||||
participate in registration and transaction logic—it requires the use of AssetAZ and its token.</p>
|
||||
<p>In this way, a sustainable ecosystem is created where it is free to use and experiment, but there is a small
|
||||
cost for commercial activity.</p>
|
||||
|
||||
<div class="footer">
|
||||
<p>Translated and rendered from Nenjim.md</p>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
+264
@@ -0,0 +1,264 @@
|
||||
#<center><H1>Nenjim<br>Documentation</H1></center>
|
||||
|
||||
**Indholdsfortegnelse:**
|
||||
<!-- TOC -->
|
||||
* [1. Introduktion til Nenjim](#1-introduktion-til-nenjim)
|
||||
* [2. Versionering og Afhængigheder](#2-versionering-og-afhængigheder)
|
||||
* [3. Opdateringer og Sikkerhed](#3-opdateringer-og-sikkerhed)
|
||||
* [4. Betalingssystem og Integration med AssetAZ](#4-betalingssystem-og-integration-med-assetaz)
|
||||
* [5. Backing Store og Fleksibilitet](#5-backing-store-og-fleksibilitet)
|
||||
* [6. Standardiseret og Automatiseret Pakkehåndtering](#6-standardiseret-og-automatiseret-pakkehåndtering)
|
||||
* [7. Betydningen af Semantisk Versionering](#7-betydningen-af-semantisk-versionering)
|
||||
* [8. Integration af Plugins og Centralt Registry](#8-integration-af-plugins-og-centralt-registry)
|
||||
* [9. Integration med AssetAZ og økonomisk aktivitet](#9-integration-med-assetaz-og-økonomisk-aktivitet)
|
||||
<!-- TOC -->
|
||||
|
||||
## 1. Introduktion til Nenjim
|
||||
Nenjim er et innovativt system, der gør det muligt at håndtere forskellige versioner af softwarepakker simultant.
|
||||
Systemet løser udfordringen med afhængigheder og versionering ved at benytte unikke versionsnumre i pakkernes
|
||||
navngivning, hvilket sikrer, at flere versioner af samme softwarepakke kan eksistere side om side uden konflikter.
|
||||
|
||||
## 2. Versionering og Afhængigheder
|
||||
Nenjim bruger en metode, hvor pakker navngives med versionsnummer direkte i pakkenavnet. Dette håndteres dog i
|
||||
såkaldte journaler, udenfor selve koden, således at Java koden ikke har afhængigheder til Nenjim her.
|
||||
Dette sikrer, at udviklere ikke behøver at bekymre sig om versionskonflikter, da hver afhængighed refererer præcist
|
||||
til den version, den har brug for. Systemet sørger for, at alle nødvendige moduler er tilgængelige og opdaterede
|
||||
i baggrunden.
|
||||
|
||||
## 3. Opdateringer og Sikkerhed
|
||||
Nenjim holder automatisk øje med opdateringer gennem det der kaldes journaler. Hvis der opdages en sikkerhedsbrist
|
||||
i en bestemt version, opdaterer udviklerne journalen, og alle NenjimHubs vil automatisk hente den nye sikrede version,
|
||||
eller nedgradere til en tidligere version indtil en opdatering er klar. På denne måde spredes opdateringer hurtigt
|
||||
og effektivt i hele netværket.
|
||||
|
||||
## 4. Betalingssystem og Integration med AssetAZ
|
||||
For at understøtte betaling for softwarepakker har Nenjim en integration med AssetAZ. Det betyder, at udviklere kan
|
||||
vælge at modtage betaling for deres pakker enten som engangsbeløb, abonnement eller per brug. Det hele håndteres
|
||||
via kryptovaluta.
|
||||
|
||||
## 5. Backing Store og Fleksibilitet
|
||||
Nenjim giver fuld fleksibilitet i forhold til, hvor data lagres. Det kan være via på IPFS, i en lokal mappe, eller
|
||||
endda i en database. Systemet er designet til at være så fleksibelt, at udviklere kan vælge den løsning, der
|
||||
passer bedst til deres behov.
|
||||
|
||||
## 6. Standardiseret og Automatiseret Pakkehåndtering
|
||||
En af de store fordele ved Nenjim er, at brugere ikke længere behøver at søge manuelt efter afhængigheder på
|
||||
Internettet. Nenjim benytter en standardiseret metode til at finde og downloade pakker automatisk f.eks. via IPFS.
|
||||
Det betyder, at alle pakker er let tilgængelige og kan hentes på en ensartet måde, hvilket sparer tid og sikrer
|
||||
en mere strømlinet oplevelse for både udviklere og brugere.
|
||||
|
||||
## 7. Betydningen af Semantisk Versionering
|
||||
For at Nenjim kan fungere optimalt, er det essentielt, at alle pakker følger principperne for semantisk
|
||||
versionering. Det betyder, at hver version af en pakke tydeligt angiver, om der er tale om en mindre opdatering,
|
||||
en fejlrettelse eller en større, potentielt inkompatibel ændring. Ved at overholde disse versioneringsregler
|
||||
kan Nenjim nemt og sikkert håndtere opdateringer og sikre, at systemet altid er stabilt og velfungerende.
|
||||
|
||||
## 8. Integration af Plugins og Centralt Registry
|
||||
En af de unikke fordele ved at benytte Nenjim er, at applikationer kan kommunikere direkte med NenjimHub'en
|
||||
for at finde og integrere nye plugins. Gennem et globalt registry kan applikationer søge efter plugins,
|
||||
der implementerer bestemte interfaces af specifikke versioner, og dermed let udvide deres funktionalitet.
|
||||
Denne fleksibilitet gør det muligt for brugere at tilføje nye features eller forbedringer, som for eksempel
|
||||
codecs til en videoafspiller og samtidig se, hvad de forskellige plugins koster.
|
||||
|
||||
## 9. Integration med AssetAZ og økonomisk aktivitet
|
||||
Nenjim er designet til at være et åbent og frit værktøj til håndtering af afhængigheder, versionering og afvikling af
|
||||
softwarepakker. Systemet kan bruges uden nogen form for betaling, og alle grundlæggende funktioner – som f.eks.
|
||||
lokal injektion, analyse af afhængigheder og dynamisk classloading – er tilgængelige uden krav om økonomisk interaktion.
|
||||
Men i de tilfælde, hvor brugeren ønsker at gøre sin software offentligt tilgængelig for andre – f.eks. ved at
|
||||
propagere pakker til et registry eller sælge sin software – vil der være knyttet en lille økonomisk omkostning til
|
||||
disse handlinger.
|
||||
For at understøtte denne form for aktivitet, anvender Nenjim den digitale AssetAZ crypto token. Denne token er
|
||||
en del af den bredere AssetAZ-platform og giver mulighed for mikrobetalinger i forbindelse med softwaredistribution.
|
||||
Ved at benytte en dedikeret token opnås en decentral og gennemsigtig afregningsmekanisme, samtidig med at det skaber
|
||||
en naturlig kobling til AssetAZ, hvor hele den økonomiske infrastruktur er forankret.
|
||||
Det er vigtigt at bemærke, at denne integration ikke begrænser brugen af Nenjim i almindelige, ikke-kommercielle
|
||||
sammenhænge, men i det øjeblik man ønsker at publicere og distribuere software med økonomisk formål – og dermed
|
||||
også deltage i registrering og transaktionslogik – kræver det at AssetAZ og dens token anvendes.
|
||||
På den måde skabes et bæredygtigt økosystem, hvor det er gratis at bruge og eksperimentere, men koster et lille beløb
|
||||
at gøre noget kommercielt.
|
||||
|
||||
## 10. Installation af en NenjimHub
|
||||
For at NenjimHub'en kan køre godt, skal den leve i et samspil med nogle andre komponenter. Dette kan sættes op på
|
||||
forskellige måder. Efterfølgende er et eksempel på en opsætning i en Virtuel Maskine, eller en lille fysisk host.
|
||||
Bemærk at ECC ram er kritisk for stabiliteten, specielt hvis NenjimHub'en skal arbejde med finansielle aktiviteter.
|
||||
Efterfølgende er en beskrivelse af hvordan man laver en opsætning som virker. Du kan lave specielle rettelser, hvis
|
||||
du forstår hvad du laver. Det vil dog være en god idé at følge en standard opsætning, så alt bliver lidt nemmere
|
||||
at styre.
|
||||
|
||||
## 10.1 Reference opsætning af Fysisk eller Virtuel Maskine (VM) til NenjimHub
|
||||
Her beskrives hvordan man laver en standard opsætning af en NenjimHub. Denne opsætning vil også blive refereret til
|
||||
som reference opsætningen, sådan at man har et fælles udgangspunkt at tale ud fra.
|
||||
|
||||
## 10.1.2 Minimale system krav
|
||||
Det er klart at jo mere NenjimHub'en skal lave, jo større er hardware kravene, men med en 'NenjimHub Reference
|
||||
Configuration', får du en opsætning der kan starte op og som du kan bygge videre fra.
|
||||
Derfor er kravene til opsætningen meget moderate.
|
||||
* CPU: 64bit x86
|
||||
* RAM: 2GB (Helst ECC)
|
||||
* Storage: 2x16GB (for RAID)
|
||||
* Networking: Public IPv4 access
|
||||
|
||||
## 10.1.3 Basis Operativ System installation
|
||||
Hvis du installerer som en VM (Proxmox), så brug følgende:
|
||||
* Aktiver Qemu Agent
|
||||
* Virtual Machine type: q35
|
||||
* BIOS: OVMF (UEFI - med EFI disk + Pre-Enrolled keys)
|
||||
* Storage: 2 x 16GB (SSD emulation + Discard)
|
||||
* CPU: 2 CPU cores (type: x86-64-v2-AES)
|
||||
* Memory: 2GB (Minimum 1GB + Ballooning)
|
||||
* Network: Adgang til et netværk med DHCP service (Fravælg Proxmox firewall)
|
||||
|
||||
Installer basis Operativ System:
|
||||
- Boot installations medie for Debian-13
|
||||
- Vælg defaults med mindre andet angivet nedenfor
|
||||
- User setup:
|
||||
- Full name: System Operator
|
||||
- Username: sysop
|
||||
- Partition disks:
|
||||
- Manual
|
||||
- Lav nye tomme partitions tabeller
|
||||
- Disk 1:
|
||||
- Partition 1
|
||||
- Size: 512MB
|
||||
- Name: EFI1
|
||||
- Use as: EFI System Partition
|
||||
- Bootable: on
|
||||
- Partition 2
|
||||
- Size: 8GB
|
||||
- Name: ROOT1
|
||||
- Use as: Ext4
|
||||
- Label: ROOT
|
||||
- Partition 3
|
||||
- Size: 8.7GB (Resten af disken)
|
||||
- Name: ZFS1
|
||||
- Use as: do not use
|
||||
- Disk 2:
|
||||
- Partition 1
|
||||
- Size: 512MB
|
||||
- Name: EFI2
|
||||
- Use as: do not use
|
||||
- Partition 2
|
||||
- Size: 8GB
|
||||
- Name: ROOT2
|
||||
- Use as: do not use
|
||||
- Partition 3
|
||||
- Size: 8.7GB (Resten af disken)
|
||||
- Name: ZFS2
|
||||
- Use as: do not use
|
||||
- Acceptér ikke at opsætte swap endnu.
|
||||
- Software selection:
|
||||
- SSH server
|
||||
- standard system utilities
|
||||
- Reboot after installation
|
||||
|
||||
Install additional tools:
|
||||
```
|
||||
$ su -
|
||||
# apt-get update; apt-get install -y htop zram-tools sudo tmux
|
||||
# usermod -aG sudo sysop
|
||||
(Log ud og ind igen)
|
||||
# sudo bash
|
||||
# vi /etc/default/zramswap
|
||||
(Ret PRIORITY=1)
|
||||
# sed -ri'.bak' '/^deb/ { /contrib/! s/$/ contrib/ }' /etc/apt/sources.list
|
||||
# apt-get update
|
||||
# mokutil --sb-state || sudo apt -y install mokutil && mokutil --sb-state
|
||||
# apt install -y dkms sbsigntool shim-signed mokutil
|
||||
# mokutil --import /var/lib/dkms/mok.pub
|
||||
(Indtast en midlertidig adgangskode)
|
||||
# apt-get install -y linux-headers-amd64 zfsutils-linux zfs-dkms zfs-zed
|
||||
# reboot
|
||||
(Når den blå skærm kommer, vælg 'Enroll MOK' og brug nu det password du valgte ovenover)
|
||||
```
|
||||
|
||||
Opret ZFS pool:
|
||||
```
|
||||
$ sudo bash
|
||||
# zpool create zfspool -O xattr=sa -o ashift=12 -O compression=lz4 -O checksum=sha512 -O dedup=on -O atime=off mirror /dev/sda3 /dev/sdb3
|
||||
```
|
||||
|
||||
Opret swap:
|
||||
```
|
||||
$ sudo bash
|
||||
# zfs create -V 4G -o compression=zle \
|
||||
-o logbias=throughput -o sync=always \
|
||||
-o primarycache=metadata -o secondarycache=none \
|
||||
-o com.sun:auto-snapshot=false zfspool/swap
|
||||
# mkswap -f /dev/zvol/zfspool/swap
|
||||
# echo /dev/zvol/zfspool/swap none swap sw,pri=0 0 0 >> /etc/fstab
|
||||
# swapon -av
|
||||
```
|
||||
|
||||
Installér docker (using official repository instead of Debian repository):
|
||||
```
|
||||
$ sudo bash
|
||||
# apt install -y apt-transport-https ca-certificates curl gpg
|
||||
# curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker.gpg
|
||||
# echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker.gpg] https://download.docker.com/linux/debian trixie stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
|
||||
# apt update
|
||||
# apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
|
||||
# usermod -aG docker sysop
|
||||
(Log out and in again)
|
||||
```
|
||||
|
||||
Flyt docker storage til ZFS:
|
||||
```
|
||||
$ sudo bash
|
||||
# systemctl stop docker
|
||||
# zfs create -V 3G zfspool/var_lib_docker
|
||||
# mkfs.ext4 /dev/zvol/zfspool/var_lib_docker
|
||||
# rm -rf /var/lib/docker
|
||||
# mkdir /var/lib/docker
|
||||
# echo "/dev/zvol/zfspool/var_lib_docker /var/lib/docker ext4 defaults 0 2" >> /etc/fstab
|
||||
# systemctl daemon-reload
|
||||
# mount /var/lib/docker
|
||||
# chmod 710 /var/lib/docker
|
||||
# systemctl enable docker ; systemctl start docker
|
||||
```
|
||||
|
||||
Installer ZeroTier:
|
||||
```
|
||||
$ sudo bash
|
||||
|
||||
# curl -fsSL 'https://raw.githubusercontent.com/zerotier/ZeroTierOne/main/doc/contact%40zerotier.com.gpg' | gpg --import
|
||||
(Importer ZeroTier's signeringsnøgle)
|
||||
|
||||
# gpg --fingerprint contact@zerotier.com
|
||||
(Check nøglen)
|
||||
|
||||
#if z=$(curl -fsSL 'https://install.zerotier.com/' | gpg --decrypt); then
|
||||
echo "$z" | sudo bash
|
||||
else
|
||||
echo "Signaturtjek mislykkedes – kører ikke scriptet." >&2
|
||||
exit 1
|
||||
fi
|
||||
(Henter og dekryperer (verificerer) install-scriptet og kører det kun hvis signaturen er OK)
|
||||
```
|
||||
|
||||
Konfigurer ZeroTier net:
|
||||
- Login på 'https://my.zerotier.com'
|
||||
- Opret et nye netværk 'Create A Network'
|
||||
(Som skal forbinde terminaler og AssetAZHub)
|
||||
- Klik på det nye netværk
|
||||
- Basic/Name: 'assetaz-<ditid>'
|
||||
(f.eks 'assetaz-mortengh')
|
||||
- Vælg et IP range, f.eks 192.168.192.*
|
||||
- Forbind AssetAZHub til netværket (netværks id'et kan ses på websiden):
|
||||
- # zerotier-cli join a8bea75acfa45477
|
||||
- Autoriser den nye maskine på nettet. Dette gøres ved at trykke på 'Edit' ved maskinen på websiden, som nu
|
||||
burde kunne se den. Autoriser den, giv den et navn og evt. en beskrivelse.
|
||||
- Tryk 'Add IP' og giv den en IP adresse inden for det range du har valgt oven over (f.eks 192.168.192.1). Tryk 'Save'
|
||||
- Se at AssetAZHub' nu kan pinge sig selv:
|
||||
# ping 192.168.192.1
|
||||
|
||||
Forbind terminal (f.eks en Android telefon)
|
||||
- Installer ZeroTier-One
|
||||
- Forbind til det samme net som hub'en.
|
||||
- Autoriser terminalen inde på ZeroTiers web side og set terminalen ip adresse til noget kendt f.eks 192.168.192.2.
|
||||
(Så kører hub'en på *.1 og terminalen på *.2)
|
||||
|
||||
Opsæt locale
|
||||
|
||||
Opret Docker baby swarm cluster
|
||||
```
|
||||
```
|
||||
@@ -0,0 +1,28 @@
|
||||
#<center><H1>Nenjim TestTool<br>Documentation</H1></center>
|
||||
|
||||
## Byg af NenjimTestTool
|
||||
NOTE: NenjimTestTool ligger i øjeblikket i Cauldron, men skal flyttes ud i sit egent projekt senere. Indtil det sker
|
||||
bygges NenjimTestTool sammen med alt det andet som ligger i Cauldron.
|
||||
|
||||
``` bash
|
||||
~/projects/r35157_cauldron$ ./mvnw package
|
||||
```
|
||||
|
||||
## 12. Opstart af NenjimTestTool
|
||||
For at kunne starte NenjimTestTool, skal du have startet en NenjimHub instans, da NenjimTestTool startes igennem
|
||||
Nenjim.
|
||||
|
||||
Der er jo forskellige interfaces til NenjimHub'en, men en nem måde er hvis du har aktiveret CLI interfacet til
|
||||
NenjimHub'en - så kan du state den ved at følge følgende trace:
|
||||
``` bash
|
||||
$ telnet localhost 38010
|
||||
Trying ::1...
|
||||
Connected to localhost.
|
||||
Escape character is '^]'.
|
||||
NenjimHub 0.1 r35157_reference_implementation 0.0.0.1
|
||||
OK
|
||||
START crypto.r35157.nenjim.NenjimTestTool
|
||||
OK (0ms)
|
||||
```
|
||||
|
||||
Der åbnes nu et vindue for TestToolet.
|
||||
@@ -0,0 +1 @@
|
||||
#<center><H1>Soda Task Manager<br>Documentation</H1></center>
|
||||
@@ -0,0 +1,166 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="da">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>SuWiMo Documentation</title>
|
||||
<style>
|
||||
body {
|
||||
font-family: Arial, sans-serif;
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
background-color: #f8f9fa;
|
||||
color: #333;
|
||||
line-height: 1.6;
|
||||
}
|
||||
.container {
|
||||
width: 80%;
|
||||
max-width: 1000px;
|
||||
margin: auto;
|
||||
padding: 20px;
|
||||
}
|
||||
h1, h2, h3 {
|
||||
color: #0056b3;
|
||||
}
|
||||
.section {
|
||||
margin-bottom: 40px;
|
||||
}
|
||||
.highlight {
|
||||
background-color: #e7f1ff;
|
||||
padding: 10px;
|
||||
border-left: 4px solid #0056b3;
|
||||
margin-top: 20px;
|
||||
}
|
||||
.footer {
|
||||
text-align: center;
|
||||
padding: 20px;
|
||||
border-top: 1px solid #ddd;
|
||||
margin-top: 40px;
|
||||
color: #777;
|
||||
}
|
||||
.token-logo {
|
||||
width: 100px;
|
||||
height: 100px;
|
||||
}
|
||||
pre, code {
|
||||
background: #f4f4f4;
|
||||
border-radius: 4px;
|
||||
padding: 2px 6px;
|
||||
}
|
||||
pre {
|
||||
padding: 10px;
|
||||
overflow-x: auto;
|
||||
}
|
||||
table {
|
||||
border-collapse: collapse;
|
||||
width: 100%;
|
||||
}
|
||||
th, td {
|
||||
border: 1px solid #ccc;
|
||||
padding: 6px;
|
||||
text-align: left;
|
||||
}
|
||||
ul, ol {
|
||||
margin-left: 1.2em;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="container">
|
||||
<h1>SuWiMo Documentation</h1>
|
||||
<p>#<center><H1>SuWiMo<br>Documentation</H1></center></p><p><strong>Indholdsfortegnelse:</strong>
|
||||
<!-- TOC -->
|
||||
* [1. Introduktion og Formål](#1-introduktion-og-formål)
|
||||
* [2. Arkitektur og Overordnet Design](#2-arkitektur-og-overordnet-design)
|
||||
* [2.1 Central Hub (SuWiMoHub)](#21-central-hub-suwimohub)
|
||||
* [2.2 Plugin-baseret Design](#22-plugin-baseret-design)
|
||||
* [3. Sensorer](#3-sensorer)
|
||||
* [3.1 Sensorinterface](#31-sensorinterface)
|
||||
* [3.2 Statusniveauer](#32-statusniveauer)
|
||||
* [3.3 Passiv Sensorlogik](#33-passiv-sensorlogik)
|
||||
* [4. Hierarkisk Struktur (Træstruktur)](#4-hierarkisk-struktur-træstruktur)
|
||||
* [4.1 Dynamisk Træ via Konfiguration](#41-dynamisk-træ-via-konfiguration)
|
||||
* [4.2 Statuspropagering](#42-statuspropagering)
|
||||
* [5. Notifikationssystem og Logging](#5-notifikationssystem-og-logging)
|
||||
* [5.1 Notifier Interface](#51-notifier-interface)
|
||||
* [5.2 Historik og Logging](#52-historik-og-logging)
|
||||
* [6. Distribution og Decentralisering](#6-distribution-og-decentralisering)
|
||||
* [6.1 AssetAZ Observables](#61-assetaz-observables)
|
||||
* [6.2 Distribuerede Hubs](#62-distribuerede-hubs)
|
||||
* [7. Brugsscenarier og Eksempler](#7-brugsscenarier-og-eksempler)
|
||||
* [8. Fremtidige Funktioner / TODO](#8-fremtidige-funktioner--todo)
|
||||
<!-- TOC --></p><p><h2>1. Introduktion og Formål</h2>
|
||||
SuWiMo (Surveillance Without Moving) er et system udviklet til enkel og effektiv statusovervågning af mange uafhængige
|
||||
sensorer organiseret i en hierarkisk træstruktur. Formålet med SuWiMo er at give et hurtigt, visuelt overblik over
|
||||
systemets tilstand, hvor status let kan aflæses som grøn (OK), gul (advarsel) eller rød (kritisk fejl).</p><p>SuWiMo fokuserer på tillidsvalidering og identificering af afvigelser i realtid, snarere end detaljeret monitorering
|
||||
eller datalogging som traditionelle overvågningssystemer.</p><p><h2>2. Arkitektur og Overordnet Design</h2>
|
||||
<h3>2.1 Central Hub (SuWiMoHub)</h3>
|
||||
SuWiMoHub fungerer som den centrale orchestrator, der står for al polling, statusvurdering og statuspropagering i
|
||||
træstrukturen. Hubben håndterer ikke selv sensorlogik, men trækker på plugins via interfaces.
|
||||
<ul><ul><li>Centraliseret styring af polling-interval.</li>
|
||||
<li>Indlæsning af sensor- og notifier-plugins.</li>
|
||||
<li>Dynamisk opbygning og opdatering af status-træet.</li></p><p><h3>2.2 Plugin-baseret Design</h3>
|
||||
SuWiMo benytter en modulær plugin-arkitektur, hvor forskellige typer af plugins implementerer specifikke interfaces
|
||||
efter deres funktion:
|
||||
<li><strong>Sensor-plugins</strong> implementerer sensorinterface til overvågning og statusrapportering.</li>
|
||||
<li><strong>Notifier-plugins</strong> implementerer notifierinterface til at sende notifikationer ved statusændringer.</li>
|
||||
<li><strong>Logger-plugins</strong> implementerer logningsinterface til historisk registrering af statusændringer.</li></p><p>Disse plugins registreres og administreres af Nenjim-systemet, hvilket sikrer nem distribution, versionering og
|
||||
udskiftelighed.</p><p><h2>3. Sensorer</h2>
|
||||
<h3>3.1 Sensorinterface</h3>
|
||||
Sensorer implementerer et simpelt, standardiseret interface:</p><pre><code class="java">public interface SuwimoSensor {
|
||||
SensorStatus poll();
|
||||
}</p><p>public class SensorStatus {
|
||||
StatusLevel level; // GREEN, YELLOW, RED
|
||||
String message; // Kort forklaring på tilstand
|
||||
}
|
||||
</code></pre><p><h3>3.2 Statusniveauer</h3>
|
||||
<li><strong>Green</strong>: Normal drift.</li>
|
||||
<li><strong>Yellow</strong>: Advarsel, kræver opmærksomhed.</li>
|
||||
<li><strong>Red</strong>: Kritisk fejl, kræver øjeblikkelig handling.</li></p><p><h3>3.3 Passiv Sensorlogik</h3>
|
||||
Sensorer kører ikke aktivt. De er passive komponenter, som kun evaluerer og returnerer deres status, når hubben
|
||||
poller dem.</p><p><h2>4. Hierarkisk Struktur (Træstruktur)</h2>
|
||||
<h3>4.1 Dynamisk Træ via Konfiguration</h3>
|
||||
Træstrukturen defineres i en JSON-konfigurationsfil, hvor hver node har et unikt ID, et navn, en valgfri sensor og en
|
||||
parent-reference. Eksempel:</p><pre><code class="json">[
|
||||
{ "id": "internet", "name": "Internetforbindelse", "sensor": "PingGoogle", "parent": null },
|
||||
{ "id": "zfs-check", "name": "ZFS array", "sensor": "ZfsStatus", "parent": "server01" },
|
||||
{ "id": "server01", "name": "Serverrummet", "sensor": null, "parent": null }
|
||||
]
|
||||
</code></pre><p><h3>4.2 Statuspropagering</h3>
|
||||
Den dårligste status blandt børn og egen sensor propagerer op gennem træet. Det gør det muligt at se den værste
|
||||
tilstand hurtigt fra en node eller træets rod.</p><p><h2>5. Notifikationssystem og Logging</h2>
|
||||
<h3>5.1 Notifier Interface</h3>
|
||||
Notifikationskomponenter implementerer et interface, der reagerer på statusændringer:</p><pre><code class="java">public interface SuwimoNotifier {
|
||||
void statusChanged(SensorEvent event);
|
||||
}</p><p>public class SensorEvent {
|
||||
String sensorId;
|
||||
StatusLevel oldStatus;
|
||||
StatusLevel newStatus;
|
||||
String message;
|
||||
ZonedDateTime timestamp;
|
||||
}
|
||||
</code></pre><p><h3>5.2 Historik og Logging</h3>
|
||||
Historiske log-events registreres hver gang en sensor ændrer tilstand. Denne funktionalitet implementeres som et
|
||||
separat plugin, der eksempelvis kan logge til fil, database eller anden ekstern tjeneste.</p><p><h2>6. Distribution og Decentralisering</h2>
|
||||
<h3>6.1 AssetAZ Observables</h3>
|
||||
SuWiMoHub eksponerer sin status som en AssetAZ Observable. Det gør det muligt for andre hubs eller AssetAZ-instanser
|
||||
at abonnere på sensorstatus fra eksterne hubs.</p><p><h3>6.2 Distribuerede Hubs</h3>
|
||||
Flere SuWiMoHubs kan installeres decentralt, tæt på de ressourcer de overvåger, og udveksle sensorstatus via AssetAZ's
|
||||
P2P-netværk. Dette sikrer effektiv isolation af fejl og lokal robusthed.</p><p><h2>7. Brugsscenarier og Eksempler</h2>
|
||||
Eksempler på anvendelser af SuWiMo:
|
||||
<li>Overvågning af servermiljøer (CPU, RAM, ZFS arrays)</li>
|
||||
<li>Netværksstatus (Internet-ping, DNS-opløsning)</li>
|
||||
<li>Overvågning af applikationstilgængelighed og integritet (HTTP-checks med checksum)</li>
|
||||
<li>Husovervågning (temperatur, dørsensorer, strøm)</li></p><p><h2>8. Fremtidige Funktioner / TODO</h2>
|
||||
<li>Implementering af GUI med træstruktur (træk-og-slip sensororganisering)</li>
|
||||
<li>Avanceret historikvisning (grafer og mønstergenkendelse)</li>
|
||||
<li>Yderligere notifier-plugins (push-notifikationer, SMS, Discord, syslog)</li>
|
||||
<li>Avancerede permissions og adgangskontrol</li>
|
||||
<li>Automatisk timeout-tilstand (sensor bliver rød efter manglende respons)</li>
|
||||
</ul></ul></p>
|
||||
<div class="footer">
|
||||
<p>Part of the r35157 project. See also AssetAZ, Nenjim, Evelyn.</p>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
+139
@@ -0,0 +1,139 @@
|
||||
#<center><H1>SuWiMo<br>Documentation</H1></center>
|
||||
|
||||
**Indholdsfortegnelse:**
|
||||
<!-- TOC -->
|
||||
* [1. Introduktion og Formål](#1-introduktion-og-formål)
|
||||
* [2. Arkitektur og Overordnet Design](#2-arkitektur-og-overordnet-design)
|
||||
* [2.1 Central Hub (SuWiMoHub)](#21-central-hub-suwimohub)
|
||||
* [2.2 Plugin-baseret Design](#22-plugin-baseret-design)
|
||||
* [3. Sensorer](#3-sensorer)
|
||||
* [3.1 Sensorinterface](#31-sensorinterface)
|
||||
* [3.2 Statusniveauer](#32-statusniveauer)
|
||||
* [3.3 Passiv Sensorlogik](#33-passiv-sensorlogik)
|
||||
* [4. Hierarkisk Struktur (Træstruktur)](#4-hierarkisk-struktur-træstruktur)
|
||||
* [4.1 Dynamisk Træ via Konfiguration](#41-dynamisk-træ-via-konfiguration)
|
||||
* [4.2 Statuspropagering](#42-statuspropagering)
|
||||
* [5. Notifikationssystem og Logging](#5-notifikationssystem-og-logging)
|
||||
* [5.1 Notifier Interface](#51-notifier-interface)
|
||||
* [5.2 Historik og Logging](#52-historik-og-logging)
|
||||
* [6. Distribution og Decentralisering](#6-distribution-og-decentralisering)
|
||||
* [6.1 AssetAZ Observables](#61-assetaz-observables)
|
||||
* [6.2 Distribuerede Hubs](#62-distribuerede-hubs)
|
||||
* [7. Brugsscenarier og Eksempler](#7-brugsscenarier-og-eksempler)
|
||||
* [8. Fremtidige Funktioner / TODO](#8-fremtidige-funktioner--todo)
|
||||
<!-- TOC -->
|
||||
|
||||
## 1. Introduktion og Formål
|
||||
SuWiMo (Surveillance Without Moving) er et system udviklet til enkel og effektiv statusovervågning af mange uafhængige
|
||||
sensorer organiseret i en hierarkisk træstruktur. Formålet med SuWiMo er at give et hurtigt, visuelt overblik over
|
||||
systemets tilstand, hvor status let kan aflæses som grøn (OK), gul (advarsel) eller rød (kritisk fejl).
|
||||
|
||||
SuWiMo fokuserer på tillidsvalidering og identificering af afvigelser i realtid, snarere end detaljeret monitorering
|
||||
eller datalogging som traditionelle overvågningssystemer.
|
||||
|
||||
## 2. Arkitektur og Overordnet Design
|
||||
### 2.1 Central Hub (SuWiMoHub)
|
||||
SuWiMoHub fungerer som den centrale orchestrator, der står for al polling, statusvurdering og statuspropagering i
|
||||
træstrukturen. Hubben håndterer ikke selv sensorlogik, men trækker på plugins via interfaces.
|
||||
|
||||
- Centraliseret styring af polling-interval.
|
||||
- Indlæsning af sensor- og notifier-plugins.
|
||||
- Dynamisk opbygning og opdatering af status-træet.
|
||||
|
||||
### 2.2 Plugin-baseret Design
|
||||
SuWiMo benytter en modulær plugin-arkitektur, hvor forskellige typer af plugins implementerer specifikke interfaces
|
||||
efter deres funktion:
|
||||
|
||||
- **Sensor-plugins** implementerer sensorinterface til overvågning og statusrapportering.
|
||||
- **Notifier-plugins** implementerer notifierinterface til at sende notifikationer ved statusændringer.
|
||||
- **Logger-plugins** implementerer logningsinterface til historisk registrering af statusændringer.
|
||||
|
||||
Disse plugins registreres og administreres af Nenjim-systemet, hvilket sikrer nem distribution, versionering og
|
||||
udskiftelighed.
|
||||
|
||||
## 3. Sensorer
|
||||
### 3.1 Sensorinterface
|
||||
Sensorer implementerer et simpelt, standardiseret interface:
|
||||
|
||||
```java
|
||||
public interface SuwimoSensor {
|
||||
SensorStatus poll();
|
||||
}
|
||||
|
||||
public class SensorStatus {
|
||||
StatusLevel level; // GREEN, YELLOW, RED
|
||||
String message; // Kort forklaring på tilstand
|
||||
}
|
||||
```
|
||||
|
||||
### 3.2 Statusniveauer
|
||||
- **Green**: Normal drift.
|
||||
- **Yellow**: Advarsel, kræver opmærksomhed.
|
||||
- **Red**: Kritisk fejl, kræver øjeblikkelig handling.
|
||||
|
||||
### 3.3 Passiv Sensorlogik
|
||||
Sensorer kører ikke aktivt. De er passive komponenter, som kun evaluerer og returnerer deres status, når hubben
|
||||
poller dem.
|
||||
|
||||
## 4. Hierarkisk Struktur (Træstruktur)
|
||||
### 4.1 Dynamisk Træ via Konfiguration
|
||||
Træstrukturen defineres i en JSON-konfigurationsfil, hvor hver node har et unikt ID, et navn, en valgfri sensor og en
|
||||
parent-reference. Eksempel:
|
||||
|
||||
```json
|
||||
[
|
||||
{ "id": "internet", "name": "Internetforbindelse", "sensor": "PingGoogle", "parent": null },
|
||||
{ "id": "zfs-check", "name": "ZFS array", "sensor": "ZfsStatus", "parent": "server01" },
|
||||
{ "id": "server01", "name": "Serverrummet", "sensor": null, "parent": null }
|
||||
]
|
||||
```
|
||||
|
||||
### 4.2 Statuspropagering
|
||||
Den dårligste status blandt børn og egen sensor propagerer op gennem træet. Det gør det muligt at se den værste
|
||||
tilstand hurtigt fra en node eller træets rod.
|
||||
|
||||
## 5. Notifikationssystem og Logging
|
||||
### 5.1 Notifier Interface
|
||||
Notifikationskomponenter implementerer et interface, der reagerer på statusændringer:
|
||||
|
||||
```java
|
||||
public interface SuwimoNotifier {
|
||||
void statusChanged(SensorEvent event);
|
||||
}
|
||||
|
||||
public class SensorEvent {
|
||||
String sensorId;
|
||||
StatusLevel oldStatus;
|
||||
StatusLevel newStatus;
|
||||
String message;
|
||||
ZonedDateTime timestamp;
|
||||
}
|
||||
```
|
||||
|
||||
### 5.2 Historik og Logging
|
||||
Historiske log-events registreres hver gang en sensor ændrer tilstand. Denne funktionalitet implementeres som et
|
||||
separat plugin, der eksempelvis kan logge til fil, database eller anden ekstern tjeneste.
|
||||
|
||||
## 6. Distribution og Decentralisering
|
||||
### 6.1 AssetAZ Observables
|
||||
SuWiMoHub eksponerer sin status som en AssetAZ Observable. Det gør det muligt for andre hubs eller AssetAZ-instanser
|
||||
at abonnere på sensorstatus fra eksterne hubs.
|
||||
|
||||
### 6.2 Distribuerede Hubs
|
||||
Flere SuWiMoHubs kan installeres decentralt, tæt på de ressourcer de overvåger, og udveksle sensorstatus via AssetAZ's
|
||||
P2P-netværk. Dette sikrer effektiv isolation af fejl og lokal robusthed.
|
||||
|
||||
## 7. Brugsscenarier og Eksempler
|
||||
Eksempler på anvendelser af SuWiMo:
|
||||
|
||||
- Overvågning af servermiljøer (CPU, RAM, ZFS arrays)
|
||||
- Netværksstatus (Internet-ping, DNS-opløsning)
|
||||
- Overvågning af applikationstilgængelighed og integritet (HTTP-checks med checksum)
|
||||
- Husovervågning (temperatur, dørsensorer, strøm)
|
||||
|
||||
## 8. Fremtidige Funktioner / TODO
|
||||
- Implementering af GUI med træstruktur (træk-og-slip sensororganisering)
|
||||
- Avanceret historikvisning (grafer og mønstergenkendelse)
|
||||
- Yderligere notifier-plugins (push-notifikationer, SMS, Discord, syslog)
|
||||
- Avancerede permissions og adgangskontrol
|
||||
- Automatisk timeout-tilstand (sensor bliver rød efter manglende respons)
|
||||
@@ -0,0 +1,18 @@
|
||||
# Tekniske termer
|
||||
| Term | Beskrivelse |
|
||||
|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Modul | Et modul er den mindste logiske enhed i r35157-økosystemet. Hvert modul indeholder ét samlet ansvarsområde. Et modul består af én API-artifakt, nul eller flere Implementations-artifakter, og typisk ét Test-artifakt. Moduler kan bruges som afhængigheder af andre moduler. |
|
||||
| Artifakt | Et artifakt er et build-resultat genereret for et modul (fx en JAR-fil, Docker-image eller ZIP-pakke). Artifakter er immutable, signeret og versioneres efter Semantic Versioning. Under udvikling publiceres artifakter typisk til et Maven repository; i drift og distribution håndteres de af Nenjim. |
|
||||
| GroupId | Et artifakt er tilknyttet en gruppe, f.eks 'com.r35157.libs'. I maven er bruges '.' som skilletegn, mens der bruges '_' til repositories. |
|
||||
| ModuleId | Et artifakt er en del af et modul
|
||||
| ArtifaktId | Et artifakt id er unikt og består af <moduleId>-<artifaktType>(-<implId>)
|
||||
| API-artifakt | Et build output som definerer grænseflader og dokumentation for et modul. |
|
||||
| Implementations-artifakt | Et build output som lave en, evt. blandt flere, implementationer af de grænseflader som er defineret i API-artifaktet. |
|
||||
| Test-artifakt | Et build output som er en generel test implementation, som kan teste forskellige Implementations-artifakter for at sikre at det overholder de grænseflader og opførsel som er defineret i API-artifaktet. |
|
||||
|
||||
# Domæne specifikke termer
|
||||
| Term | Beskrivelse |
|
||||
|----------------|-------------------------------------------------------------------------------------------------------|
|
||||
| Position Value | Dette er den samlede nutidsværdi af in position (nuværende pris × antal) |
|
||||
| Base Value | Dette er den pris det har kostet at købe positionen (gennemsnits købspris × antal) |
|
||||
| Margin Value | Dette er den pris man faktisk har skulle betale for at købe en gearet position (base value / gearing) |
|
||||
Reference in New Issue
Block a user