From f29013e9c29113f6ab049e6ceaf335ef0bc24681 Mon Sep 17 00:00:00 2001 From: Minimons Date: Sun, 16 Aug 2026 12:25:06 +0200 Subject: [PATCH] X: Moved markdown files from Documentation to keep in sync --- docs/AssetAZ-public.html | 244 +++++++++++++++++++++++++++++++ docs/AssetAZ.md | 110 ++++++++++++++ docs/Evelyn.md | 303 +++++++++++++++++++++++++++++++++++++++ docs/Nenjim-public.html | 129 +++++++++++++++++ docs/Nenjim.md | 264 ++++++++++++++++++++++++++++++++++ docs/NenjimTestTool.md | 28 ++++ docs/SodaTaskManager.md | 1 + docs/Suwimo-public.html | 166 +++++++++++++++++++++ docs/Suwimo.md | 139 ++++++++++++++++++ docs/Terminologi.md | 18 +++ 10 files changed, 1402 insertions(+) create mode 100644 docs/AssetAZ-public.html create mode 100644 docs/AssetAZ.md create mode 100644 docs/Evelyn.md create mode 100644 docs/Nenjim-public.html create mode 100644 docs/Nenjim.md create mode 100644 docs/NenjimTestTool.md create mode 100644 docs/SodaTaskManager.md create mode 100644 docs/Suwimo-public.html create mode 100644 docs/Suwimo.md create mode 100644 docs/Terminologi.md diff --git a/docs/AssetAZ-public.html b/docs/AssetAZ-public.html new file mode 100644 index 0000000..f378c98 --- /dev/null +++ b/docs/AssetAZ-public.html @@ -0,0 +1,244 @@ + + + + + + AssetAZ Documentation + + + +
+

AssetAZ Documentation

+ + +
+

1. Introduction and Purpose

+

+ AssetAZ is not 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. +

+

+ 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. +

+
+ +
+

2. Hubs and Terminals

+

+ 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. +

+

+ There is only one user per AssetAZHub. 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. +

+
+ +
+

3. Plugins and Interfaces

+

+ 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. +

+

+ 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 interfaces survive, but implementations can die. +

+
+ +
+

4. Interaction with Nenjim

+

+ 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. +

+

+ 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. +

+
+ +
+

5. Observables and Subscribers

+

+ 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.). +

+

+ 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. +

+
+ +
+

6. AssetAZ Token and Incentives

+

+ 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. +

+

+ Tokens can also be used by users who wish to have features developed, or as a reward for contributing + knowledge, code, or data. +

+

+ 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). +

+
+ +
+

7. Peer-to-peer and Oracles

+

+ 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. +

+

+ This makes it possible to earn tokens on other types of assets than just financial – knowledge and data + also become assets. +

+
+ +
+

8. User Experience

+

+ 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. +

+

+ 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. +

+
+ +
+

9. Transparency, Trust and Signed Builds

+

+ All plugins are open source. The user can compile them themselves or trust builds that others have + published and cryptographically signed. +

+

+ 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. +

+

+ 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. +

+
+ +
+

10. Distribution and Installation

+

+ 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. +

+

+ This makes it possible to deliver an entire hub with everything preconfigured – you just power it up. +

+
+ +
+

11. Future Topics (TODO)

+
    +
  • Backup and restore via IPFS and encryption
    • +
  • Security and privacy section
    • +
  • AI as users and agents
    • +
  • Governance and community
    • +
  • User scenarios and fictional cases
    • +
  • Semver-enforcer tool and build validation
    • +
  • Further development of the observable concept
    • +
  • Fluid trust and signature replacement
    • +
  • Payment services for signed builds
    • +
+
+ +
+

AssetAZ – The foundation for open, decentralized, and programmable finance.

+
+
+ + diff --git a/docs/AssetAZ.md b/docs/AssetAZ.md new file mode 100644 index 0000000..7bde913 --- /dev/null +++ b/docs/AssetAZ.md @@ -0,0 +1,110 @@ +#

AssetAZ
Documentation

+ +**Indholdsfortegnelse:** + + * [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) + + +## 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 diff --git a/docs/Evelyn.md b/docs/Evelyn.md new file mode 100644 index 0000000..7be7f92 --- /dev/null +++ b/docs/Evelyn.md @@ -0,0 +1,303 @@ +#

Evelyn
Documentation

+ +**Indholdsfortegnelse:** + + * [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) + + +## 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. diff --git a/docs/Nenjim-public.html b/docs/Nenjim-public.html new file mode 100644 index 0000000..a951bd8 --- /dev/null +++ b/docs/Nenjim-public.html @@ -0,0 +1,129 @@ + + + + + Nenjim Documentation + + + +
+

Nenjim Documentation

+
+

Table of Contents

+ +
+

Nenjim Documentation

+

1. Introduction to Nenjim

+

Nenjim is an innovative system that enables handling multiple versions of software packages simultaneously.

+

The system solves the challenge of dependencies and versioning by using unique version numbers in the naming of + packages,

+

which ensures that multiple versions of the same software package can exist side by side without conflicts.

+ +

2. Versioning and Dependencies

+

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.

+

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.

+ +

3. Updates and Security

+

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.

+ +

4. Payment System and Integration with AssetAZ

+

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.

+ +

5. Backing Store and Flexibility

+

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.

+ +

6. Standardized and Automated Package Management

+

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.

+ +

7. Importance of Semantic Versioning

+

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.

+ +

8. Integration of Plugins and Central Registry

+

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.

+ +

9. Integration with AssetAZ and Economic Activity

+

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.

+

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.

+

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.

+

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.

+

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.

+

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.

+ +
+

Translated and rendered from Nenjim.md

+
+
+ + diff --git a/docs/Nenjim.md b/docs/Nenjim.md new file mode 100644 index 0000000..b96aab3 --- /dev/null +++ b/docs/Nenjim.md @@ -0,0 +1,264 @@ +#

Nenjim
Documentation

+ +**Indholdsfortegnelse:** + + * [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) + + +## 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 +``` +``` diff --git a/docs/NenjimTestTool.md b/docs/NenjimTestTool.md new file mode 100644 index 0000000..488ca5f --- /dev/null +++ b/docs/NenjimTestTool.md @@ -0,0 +1,28 @@ +#

Nenjim TestTool
Documentation

+ +## 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. \ No newline at end of file diff --git a/docs/SodaTaskManager.md b/docs/SodaTaskManager.md new file mode 100644 index 0000000..cf0b983 --- /dev/null +++ b/docs/SodaTaskManager.md @@ -0,0 +1 @@ +#

Soda Task Manager
Documentation

\ No newline at end of file diff --git a/docs/Suwimo-public.html b/docs/Suwimo-public.html new file mode 100644 index 0000000..eeb99ab --- /dev/null +++ b/docs/Suwimo-public.html @@ -0,0 +1,166 @@ + + + + + + SuWiMo Documentation + + + +
+

SuWiMo Documentation

+

#

SuWiMo
Documentation

Indholdsfortegnelse: + + * [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) +

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. +

+
+

Part of the r35157 project. See also AssetAZ, Nenjim, Evelyn.

+
+
+ + diff --git a/docs/Suwimo.md b/docs/Suwimo.md new file mode 100644 index 0000000..624e918 --- /dev/null +++ b/docs/Suwimo.md @@ -0,0 +1,139 @@ +#

SuWiMo
Documentation

+ +**Indholdsfortegnelse:** + + * [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) + + +## 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) diff --git a/docs/Terminologi.md b/docs/Terminologi.md new file mode 100644 index 0000000..302b3a4 --- /dev/null +++ b/docs/Terminologi.md @@ -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 -(-) +| 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) |