+ 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. +
++ 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. +
++ 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. +
++ 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. +
++ 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. +
++ 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). +
++ 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. +
++ 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. +
++ 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. +
++ 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. +
+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.
+ +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.
+ +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.
+ +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.
+ +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.
+ +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.
+ +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.
+ +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.
+ +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.
+ + +#
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) +
SuWiMo fokuserer på tillidsvalidering og identificering af afvigelser i realtid, snarere end detaljeret monitorering +eller datalogging som traditionelle overvågningssystemer.
Disse plugins registreres og administreres af Nenjim-systemet, hvilket sikrer nem distribution, versionering og +udskiftelighed.
public interface SuwimoSensor {
+ SensorStatus poll();
+}public class SensorStatus {
+ StatusLevel level; // GREEN, YELLOW, RED
+ String message; // Kort forklaring på tilstand
+}
+
[
+ { "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 }
+]
+public interface SuwimoNotifier {
+ void statusChanged(SensorEvent event);
+}public class SensorEvent {
+ String sensorId;
+ StatusLevel oldStatus;
+ StatusLevel newStatus;
+ String message;
+ ZonedDateTime timestamp;
+}
+