ytnozto

TheRealFuture42

_gregor_paul_

hello@sil3ntrunning.net

Als ich mich an meinen kleinen persönlichen (React) TypeScript-Leitfaden gesetzt habe, wusste ich noch nicht, dass es dazu in der Community eine Diskussion gibt, wie und wann typisiert werden sollte. Da ich mir selbst die Frage auch gestellt habe, möchte ich hier kurz aufzeigen, wie meine Erkenntnisse dazu sind.

Lass mir gern ein Kommentar da, wenn du es anders siehst!

# Wann solltest du typisieren?

**Verwende Typisierung bei**

1. Objekten oder Arrays
2. Funktionen und Methoden
3. Generische Typen: Hooks oder andere generische Funktionen
4. Externe Daten, z.B. wenn sie von einer API stammen

**Wann du nicht Typisieren musst**

1. Einfache Typen, z.B. `const count = 10;` da hier TypeScript automatisch ableiten kann das count eine number ist.
2. Hooks mit Initialwerten z.B. `const [isVisible, setIsVisible] = useState(false);` der Initialwert gibt hier den Typ an.

**Vorteile der expliziten Typisierung**

Einer der Hauptgründe, der für eine Typisierung spricht, ist in meinen Augen, dass explizite Typen als Dokumentation für deinen Code dienen. Andere Entwickler (oder du selbst in der Zukunft) können sofort sehen, welche Typen erwartet werden. Das schafft Sicherheit und andere können deinen Code besser verstehen.

Explizite Typen können helfen, Fehler frühzeitig zu erkennen, insbesondere in größeren Codebasen.

**Nachteile der expliziten Typisierung**

Ich gebe zu, ich habe nicht viele Gründe finden können, die gegen eine explizite Typisierung sprechen. Aber ich möchte zumindest einen Gedanken dazu mitgeben.

1. Das Hinzufügen von Typen zu jedem einzelnen Wert kann den Code unnötig aufblähen und die Verwaltung erschweren.
2. Wenn du weitere Nachteile kennst, schreibs in die Kommentare :)

**Fazit**

Wie du sicher schon mitbekommen hast, gehöre ich zur Kategorie "Everything needs a type". Ich denke, es ist nicht wirklich zielführend inkonsistent zu typisieren, auch wenn es nicht immer nötig ist, empfinde ich einen konsistenten Weg zielführender als irgendwas dazwischen.

## Wie du typisierst

## Einfache Typen

Ich denke, das hier ist selbsterklärend.

```typescript
const count: number = 10;
```

## Funktionen und Methoden

Bei der Definition von Funktionen und Methoden gibst du die Typen der Parameter und des Rückgabewerts an.

```typescript
function add(a: number, b: number): number {
  return a + b;
}
```

## Generische Typen (Generics)

Damit ich den Generics gerecht werde muss ich hier etwas tiefer eintauen. Also konzentrieren, es ist ein wichtiger Teil von TypeScript!

Generics ermöglichen es dir, typsicheren Code zu schreiben, der zur Kompilierzeit überprüft wird. Generics bieten eine flexible Möglichkeit, mit verschiedenen Typen zu arbeiten, ohne den Typ im Voraus festlegen zu müssen. Du kannst generische Funktionen, Klassen und Interfaces erstellen, die mit verschiedenen Typen arbeiten können, ohne den Code duplizieren zu müssen.

Wenn du generische Typen verwendest, wie bei useRef, useState oder anderen generischen Funktionen gibst du den Type explizit an. Das bedeutet, dass der generische Typ in diesem Fall nicht flexibel ist, sondern auf `HTMLInputElement` festgelegt wird. Lass uns das genauer betrachten.

```typescript
const inputRef = useRef<HTMLInputElement>(null);
const [isVisible, setIsVisible] = useState<boolean>(false);
```

Der große Vorteil von Generics ist aber wie oben schon erwähnt, dass du mit verschiedene Typen arbeiten kannst, ohne den Typ im Voraus festlegen zu müssen.

**Hee? What?**

Ja du hast richtig gelesen, dass ganze geht zur Laufzeit, daher hier erstmal der Code. Ich erkläre danach, was hier passiert.

```typescript
interface Person {
  name: string;
  age: number;
}

// Die Funktion teilt ein Array von Objekten in mehrere Teile auf
function splitArray<T>(array: Array<T>, numParts: number): Array<Array<T>> {
  const result: Array<Array<T>> = [];

  for (let i = 0; i < array.length; i++) {
    const index = i % numParts;
    if (!result[index]) {
      result[index] = [];
    }
    result[index].push(array[i]);
  }

  return result;
}

const persons: Person[] = [
  { name: 'Alice', age: 30 },
  { name: 'Bob', age: 25 },
  { name: 'Charlie', age: 35 },
  { name: 'Diana', age: 28 },
];

const splitPersons = splitArray(persons, 2);
console.log(splitPersons);
// Ausgabe: [[{ name: "Alice", age: 30 }, { name: "Charlie", age: 35 }], [{ name: "Bob", age: 25 }, { name: "Diana", age: 28 }]]
```

**`<T>`**: Der generische Typ T ist ein Platzhalter für den Typ, der zur Laufzeit festgelegt wird.  
**`array: Array<T>`**: Der Parameter array ist ein Array von Elementen des Typs T.  
**`Array<Array<T>>`**: Die Rückgabe ist ein Array von Arrays, wobei jedes innere Array Elemente des Typs T enthält.

Du hast noch nicht ganz verstanden, wie wir Typsicherheit erreichen, obwohl wir die Typen nicht vorweg festlegen? Ich versuche es hier an einer Analogie zu erklären.

Stell dir vor, du hast eine spezielle Box, die alles Mögliche aufnehmen kann: Bücher, Spielzeug, Kleidung usw. Diese Box hat jedoch eine besondere Eigenschaft: Sobald du etwas hineinlegst, kann sie nur noch Dinge desselben Typs aufnehmen. Wenn du also ein Buch hineinlegst, kann die Box nur noch Bücher aufnehmen. Das sorgt dafür, dass du nicht versehentlich ein Spielzeug in eine Box legst, die für Bücher gedacht ist.

Generics funktionieren ähnlich wie diese Box. Sie ermöglichen es dir, eine Funktion, Klasse oder ein Interface zu definieren, die mit verschiedenen Typen arbeiten kann. Sobald du jedoch einen bestimmten Typ verwendest, sorgt TypeScript dafür, dass nur dieser Typ verwendet wird, was Typsicherheit gewährleistet.

Ich zeigs hier noch einmal an einem simpleren Beispiel, wir haben hier eine Funktion, die einfach den Wert zurückgibt, den sie erhält.

```typescript
function identity<T>(value: T): T {
  return value;
}
```

Wir rufen diese Funktion jetzt einfach mit einem String auf.

```typescript
const result1 = identity<string>('Hello, World!');
console.log(result1); // Ausgabe: "Hello, World!"
```

Wir rufen dieselbe Funktion mit einer Number auf.

```typescript
const result2 = identity<number>(42);
console.log(result2); // Ausgabe: 42
```

TypeScript stellt in jeweils beiden Funktionsaufrufen sicher, dass der Typ entweder vom Type String bei "result1" ist oder von Type Number bei "result2".

## Externe Daten

Wenn du Daten von einer externen Quelle (z.B. einer API) erhältst, ist es hilfreich, die erwartete Struktur der Daten zu typisieren. Dies geschieht z.B. über ein "interface" würde aber auch anonymisiert oder mit einem Type-Alias gehen. Da gehe ich aber weiter unten noch genauer drauf ein wo da die Unterschiede liegen.

```typescript
interface ApiResponse {
  data: string;
  status: number;
}

async function fetchData(): Promise<ApiResponse> {
  const response = await fetch('/api/data');
  return response.json();
}
```

# DOM-Typen

Wenn du dir mein Beispiel der Generische Typen genau angeschaut hast wirst du gesehen haben, dass ich bei dem useRef-Hook eine generische Typendefinition angewandt habe, die ich selbst nicht erstellt habe, `<HTMLInputElement>`. Dies nennt man "DOM-Typen oder DOM-Interfaces". Diese sind Teil der TypeScript-Typdefinitionen, welche mit der TypeScript-Standardbibliothek mitgebracht werden. Diese Typen decken eine Reihe von DOM-Elementen und Schnittstellen ab, die in Webanwendungen verwendet werden.

## Wie finde ich die Typendefinitionen

Es gibt verschiedene Quellen, welche du nutzen kannst um an die Typendefinitionen zukommen. Du kannst die [Dokumentation von TypeScript](https://www.typescriptlang.org/docs/) nutzen oder den Quellcode von TypeScript anschauen, du findest die Typendefinitionen in der Datei `lib.dom.d.ts`. Der für mich aber beste Weg war bisher über die [MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/API), diese ist eine hervorragende Ressource für Informationen rund um die Web-APIs und der entsprechenden Typen. [Beispiel unser "HTMLInputElement"](https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement)

**Beispielhafte DOM-Typen:**

HTMLInputElement: Repräsentiert ein `<input>`-Element.  
HTMLButtonElement: Repräsentiert ein `<button>`-Element.  
HTMLElement: Der Basistyp für alle HTML-Elemente.  
Event: Der Basistyp für alle Ereignisse.

## "Interfaces" oder "Type Aliases"?

Ein wichtiger Teil von TypeScript sind Interfaces und Type Aliase. Beides ist essenziell, da diese eigentlich fast in jedem Projekt zur Anwendung kommen. Wenn du diese und die Punkte davor kennst und weißt, wie du sie einsetzt, dann hast du 90 % von dem, was du im Alltag brauchst, um mit React und TypeScript zuarbeiten. Zumindest ist es das, was ich bisher am meisten benötigt habe.

## Type-Alias

Type Alias verwendest du für primitive Typen, Union Types, Intersection Types, Tupel und komplexe Typenkombinationen. Type Aliase könne nicht erweitert werden, aber sie lassen sich kombinieren.

**Union Types (Primitive Typen)**

Ein Union Type kann Typen kombinieren, und ein Wert dieses Typs kann einer der enthaltenen Typen sein.

Primitive Union Types kombinieren primitive Typen wie string oder number.

```typescript
type ID = string | number;

let userId: ID;

userId = 'abc123'; // OK
userId = 123; // OK
userId = true; // Fehler: 'true' ist kein 'string' oder 'number'
```

**Union Types (Komplexe Types)**

Komplexe Union Types kombinieren komplexe Typen wie Objekte oder Klassen.

```typescript
type SuccessResponse = {
  status: 'success';
  data: any;
};

type ErrorResponse = {
  status: 'error';
  error: string;
};

type Response = SuccessResponse | ErrorResponse;

function handleResponse(response: Response) {
  if (response.status === 'success') {
    console.log('Data:', response.data);
  } else {
    console.log('Error:', response.error);
  }
}

const success: Response = { status: 'success', data: { id: 1, name: 'Item' } };
const error: Response = { status: 'error', error: 'Something went wrong' };

handleResponse(success); // Data: { id: 1, name: "Item" }
handleResponse(error); // Error: Something went wrong
```

**Intersection Types**

Ein Intersection Type kombiniert mehrere Typen zu einem neuen Typ, der alle Eigenschaften der kombinierten Typen enthält. Ein Wert, der einem Intersection Type entspricht, muss alle Eigenschaften der kombinierten Typen haben.

In dem folgenden Beispiel ist EmployeePerson ein Intersection Type, der alle Eigenschaften von Person und Employee kombiniert. Ein Objekt vom Typ EmployeePerson muss also name, age und employeeId haben.

```typescript
type Person = {
  name: string;
  age: number;
};

type Employee = {
  employeeId: number;
};

type EmployeePerson = Person & Employee;

const employee: EmployeePerson = {
  name: 'John Doe',
  age: 30,
  employeeId: 1234,
};
```

**Tupel**

Wir können mit TypeScript auch Tupel typisieren, also Werte mit einer festen Anzahl von Elementen.

Hier ein kleines Beispiel, Point erwartet immer zwei Elemente vom Typ number.

```typescript
type Point = [number, number];

const point: Point = [10, 20]; // Korrekt

const invalidPoint: Point = [10, '20']; // Fehler: Das zweite Element muss eine Zahl sein

const anotherInvalidPoint: Point = [10]; // Fehler: Es müssen genau zwei Elemente sein
```

## Interfaces

Ein Interface ist eine Struktur, die beschreibt, wie ein Objekt aussehen soll. Interfaces sind besonders nützlich für die Beschreibung von Objekten und Klassen und unterstützen Vererbung und Deklarationszusammenführung. Interfaces kann nicht für primitive Typen oder Unions Types verwendet werden.

**Objektstrukturen**

So schaut die Struktur eines Objektes aus:

```typescript
interface Person {
  name: string;
  age: number;
}
```

**Vererbung**

Du kannst bei Interfaces von einem anderen Interface ableiten.

```typescript
interface Person {
  name: string;
  age: number;
}

interface Employee extends Person {
  employeeId: number;
}

const employee: Employee = {
  name: 'John Doe',
  age: 30,
  employeeId: 1234,
};
```

**Deklarationszusammenführung**

Wenn du mehrere Deklarationen desselben Interfaces haben möchtest, die zu einem einzigen Interface zusammengeführt werden.

```typescript
interface Person {
  name: string;
}

interface Person {
  age: number;
}

// Das resultierende Interface Person hat sowohl name als auch age
const person: Person = { name: 'John', age: 30 };
```

Ich denke, nun kennst du alles Wichtige zu Interfaces und Type Aliases. Beide Ansätze haben ihre eigenen Stärken und Schwächen, und die Wahl zwischen ihnen hängt oft von den spezifischen Anforderungen deines Projekts ab. Wenn du weitere Fragen hast oder mehr Beispiele benötigst, lass es mich wissen!


Grundlagen der Typisierung in TypeScript: Wann und wie man typisiert, Generics, DOM-Typen, Interfaces und Type Aliases.

thumbnail-v1-TypeScript.png

Wann und Wie du typisierst

TypeScript: Typisierungs-Leitfaden

typescript

## React Hooks: Vorwort

  
In dieser Reihe schauen wir uns die verschiedenen React Hooks an und wie wir sie einsetzen können. Ich verfolge dabei keinen tieferen Plan oder ein Skript, daher könnte es gut möglich sein, dass du dich jetzt fragst, wieso fängt der denn jetzt mit dem useRef\-Hook an? Ehrlich gesagt, weiß ich das auch nicht. Seht es mir also nicht nach, ich schreibe hier einfach nur Dinge nieder, und vielleicht hilft es ja doch jemandem da draußen. 

Lange Rede, kurzer Sinn, lasst uns beginnen.

## Wozu dient der useRef Hook?

Der useRef\-Hook in React dient dazu, Referenzen auf DOM-Elemente oder andere mutable Objekte zu erstellen, die während des gesamten Lebenszyklus einer Komponente bestehen bleiben. Im gegensatz zu State-Änderungen, welche ein Re-Rendering auslösen, führt eine Referenz mit useRef nicht zu einem erneuten Rendern der Komponente. 

useRef wird häufig verwendet, um Werte zu speichern, die über Renderings hinweg persistent bleiben sollen, aber nicht in den Render-Prozess einbezogen werden müssen. Beispiele dafür sind das Speichern von DOM-Referenzen, Timer-IDs oder anderen mutierbaren Werten, die keinen Einfluss auf das UI haben.

Um es hier auf den einfachsten Weg darzustellen, wofür der useRef im Kern genutzt werden kann, hier ein kleines Beispiel um den Fokus durch Klick auf einen Button auf das Input Feld zu setzen. 

```javascript
import { useRef } from 'react';

function TextInputWithFocusButton() {
  const inputElement = useRef<HTMLInputElement>(null);

  const onButtonClick = () => {
    // `current` points on the Input-element
    inputElement.current?.focus();
  };

  return (
    <>
      <input ref={inputElement} type="text" />
      <button onClick={onButtonClick}>Focus</button>
    </>
  );
}
```

## Was passiert hier?

  
Wir rufen useRef auf der obersten Ebene unserer Komponente auf. Wir sind hier nicht limitiert und könnten auch weitere Refs deklarieren.

useRefgibt ein Ref-Objekt zurück, mit einer current property,welche wir auf einen Anfangswert gesetzt haben (null).

```typescript
import { useRef } from 'react';

function TextInputWithFocusButton() {
  const inputElement = useRef<HTMLInputElement>(null);
	// ...
```

Dann übergeben wir unser Ref-Objekt deminputElementals ref\-Attribut an das JSX des Dom-Knotens.

```typescript
  return (
    <>
      <input ref={inputElement} type="text" />
      <button onClick={onButtonClick}>Focus</button>
    </>
  );
```

Nachdem React den DOM-Node  erstellt und auf den Bildschirm anzeigt, setzt React die current Eigenschaft ihres Ref-Objekts auf diesen DOM-Node. Damit können wir nun auf das `<input>` Feld zugreifen und Methoden wie focus() aufrufen.

```typescript
  const onButtonClick = () => {
    // `current` points on the Input-element
    inputElement.current?.focus();
  };
```

## Weitere Anwendungsfälle für useRef

Ein typischer Anwendungsfall wäre zum Beispiel der Einsatz bei One-Pager-Applikationen, wo wir zu bestimmten Punkten springen möchten. Mit useRef haben wir Zugriff auf Browser-Methoden wie scrollIntoView(), um zu diesen Punkten zu scrollen.

Weiterführende Links:  
  
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/focus

https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement

https://react.dev/learn/manipulating-the-dom-with-refs

In dieser Reihe schauen wir uns die verschiedenen React Hooks an und wie wir sie einsetzen können.

thumbnail-v1-useRef.png

React Hooks vorgestellt

React Hooks: Der useRef Hook

react

In diesem Beitrag zeige ich euch, wie man mit Server Actions in Next.js arbeitet. Keine Sorge, ich werde es einfach halten und mich nicht in die hitzige Diskussion einmischen, ob es eine gute Idee ist, Server-Logik und Client-Logik zu vermischen. Aber weil diese Diskussion so kontrovers ist (und es immer noch bleibt), möchte ich euch dieses amüsante Meme dazu nicht vorenthalten.

 ![{{ w: 1000, h: 300 }}](/uploads/server_action_is_crazy_v0_yloxtuizn3xb1_4281400aa9.webp) 

Um dieses Bild richtig zu verstehen, solltet ihr euch den Vortrag von Vercel ansehen, in dem das Feature der Server Actions erstmals vorgestellt wurde.

[Hier geht's zum Video.](https://www.youtube.com/watch?v=9CN9RCzznZc)

Da einige ziemlich irritiert davon waren, serverseitigen Code innerhalb von clientseitigem Code auszuführen, und dies von vielen Seiten kritisiert wurde, hat das Internet natürlich direkt ein paar Memes dazu erfunden. Ein gutes Beispiel dafür ist das 2D-Game Redstone-Meme hier.

Ob sich die Server Actions letztendlich durchsetzen werden, wird die Zeit zeigen. Die Community ist dazu gespalten.

## Kopf in den Nacken & Los geht's

Leider komme auch ich nicht ganz um ein bisschen Einführung und Theorie herum. Also hier das Wichtigste: Mit der Einführung des App-Routers in Next.js 13.4 wurde ein neues Feature namens Server Actions vorgestellt. Dieses Konzept soll die Entwicklung von Webanwendungen optimieren, indem es die Kommunikation zwischen Client und Server verbessert und unnötige Komplexität reduziert. Mit Server Actions können bestimmte Aktionen direkt auf dem Server ausgeführt werden, anstatt sie auf der Client-Seite zu behandeln und dann über die /api an den Server weiterzugeben. Dadurch wird die Anwendungsarchitektur vereinfacht, die Leistung verbessert und eine klarere Trennung zwischen Client- und Server-Aufgaben erreicht.

Seit Next.js 14 sind Server Actions offiziell als stabiles Feature verfügbar, und wir können jetzt von den Vorteilen profitieren, wie zum Beispiel der Reduzierung von Client-Server-Roundtrips und der Möglichkeit, serverseitige Mutationen durchzuführen. Allerdings gab es auch einige Kritikpunkte an der Einführung von Server Actions (siehe unser Meme). Einige sahen Ähnlichkeiten zur Arbeitsweise von PHP und kritisierten die Vermischung von Zuständigkeiten zwischen Client und Server. Auch Bedenken hinsichtlich der Skalierbarkeit und Serverbelastung wurden geäußert. Daher ist es wichtig, sorgfältig abzuwägen, ob und wie Server Actions in einem Projekt eingesetzt werden sollten, um die bestmögliche Architektur und Leistung zu erzielen.

Server Actions müssen explizit als solche markiert werden. Das geschieht mit der Anweisung "use server";. Wir werden im Laufe unserer Beispiele noch näher darauf eingehen. Ein Vorteil von Server Actions ist, dass wir Async/Await in unseren Komponenten verwenden können, da Server Actions auf dem Server ausgeführt werden. Was jedoch nicht möglich ist, sind clientseitige React Hooks wie useEffect, useMemo usw. Diese können wie gewohnt nur in Client Components verwendet werden.

Es gibt verschiedene Möglichkeiten, wie wir Server Actions einsetzen können: In einem Formelement, durch Event Handler oder auch in einem useEffect-Hook. Ich werde hier auf alle Varianten mit Beispielen eingehen und hoffe, dass es euch weiterhilft und ihr danach etwas mehr Klarheit habt.

## Server Actions in form Elementen

React hat das HTML <form>-Element mit der Prop action erweitert, die es uns ermöglicht, Server Actions direkt beim Absenden des Formulars auszuführen.

```jsx
  return (
    <form action={createPost}>
      <label className="block">Title</label>
      <input type="text" name="title" className="block mb-2" />

      <label className="block">Text</label>
      <textarea
        name="post-text"
        rows={4}
        className="block mb-2"
        placeholder="Post Text"
      ></textarea>
      <button type="submit" className="bg-slate-600 p-2">
        Create Post
      </button>
    </form>
  );
```
Wenn wir die Action in einem `<form>`-Element aufrufen, erhält sie automatisch das [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData/FormData)-Objekt. Mit diesem Objekt sind wir nicht mehr auf den React Hook `useState` angewiesen, um die Felder zu verwalten. Stattdessen können wir die nativen Methoden von [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData#instance_methods) nutzen und darauf zugreifen.

```jsx
export default function CreatePostForm() {
  async function createPost(formData: FormData) {
    'use server';

    const data = {
      title: formData.get('title') as string,
      body: formData.get('post-text') as string,
    };

    await createPostAction(data);
  }
```
Zuerst kennzeichnen wir mit `"use server";` unsere Funktion explizit als Server Action.

Die eigentliche Verarbeitung haben wir in eine extra Datei namens "action.ts" ausgelagert. Es wäre aber auch möglich, die Funktionalität direkt in unsere Server-Komponente einzufügen, und es würde sogar als Inline-Code innerhalb der `action`-Prop in unserem Formelement funktionieren.

Hier geht es zu unserem **[Beispielcode.](https://stackblitz.com/edit/nextjs-server-actions-form?file=lib%2Factions.ts)**

> Schaut euch auch die [Dokumentation](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations#forms) dazu an dort wird das ganze noch weiter vertieft.

## Server Actions mit Event Handler

Wie schon am Anfang gesagt, lassen sich Server Actions auch außerhalb von Formelementen aufrufen.

Lasst uns also die Möglichkeit betrachten, Server Actions mit Event-Handlern (onClick, onChange, ...) aufzurufen.

Dazu haben wir ein kleines Programm geschrieben, das durch einen Klick auf den Button "Click me" die Server Action aufruft. Dabei wird ein Fake-Eintrag bei unserer API erstellt und die Antwort an unsere Client-Komponente "ShowPost.tsx" weitergegeben.

```jsx
'use client';

import { createPostAction } from '@/lib/actions';
import { useState } from 'react';
import ShowPost from '@/components/ShowPost';
import { Post } from '@/lib/types';

export default function CreatePost() {
  const [post, setPost] = useState<Post>();

  return (
    <>
      <button
        className="bg-stone-500 p-1 rounded"
        onClick={async () => {
          const createPost = await createPostAction();
          setPost(createPost);
        }}
      >
        Click me
      </button>
      <div className="pt-10">{post && <ShowPost post={post} />}</div>
    </>
  );
}
```
Ich denke, dass mein Beispiel hier ganz gut erklärt, was eigentlich passiert. Die onClick-Methode ruft in einer Async-Funktion die Server Action auf und schreibt die Antwort mit dem Hook useState in die Variable "post".

Den kompletten Code dazu könnt ihr euch hier [**anschauen**](https://stackblitz.com/edit/nextjs-server-actions-event-handler-method?file=components%2FCreatePost.tsx). 

## Server Actions mit useEffect aufrufen

Eine weitere Möglichkeit ist es, innerhalb von Client-Komponenten mit dem React useEffect-Hook Server Actions aufzurufen. Ich werde hier kurz darauf eingehen, und am Ende findet ihr wieder den Link zu meinem Code-Beispiel.

Bei jedem Reload der Seite holen wir uns mit unserem useEffect-Hook alle Einträge von unserer API.

```jsx
'use client';

import { useEffect, useState } from 'react';
import { getPostsAction } from '@/lib/actions';
import { Post } from '@/lib/types';

export default function ShowPosts() {
  const [posts, setPosts] = useState<Post[]>([]);

  useEffect(() => {
    const fetchPosts = async () => {
      try {
        const posts = await getPostsAction();
        setPosts(posts);
      } catch (error) {
        console.log(error);
      }
    };

    fetchPosts();
  }, []);

  return (
    <div>
      <ul>
        {posts.map((posts) => (
          <li className="my-5" key={posts.id}>
            {posts.id}. {posts.title}
          </li>
        ))}
      </ul>
    </div>
  );
}
```
Es wird bei jedem Seiten-Reload die API aufgerufen `const posts = await getPostsAction();`, die Antwort unseres Servers speichern wir nun mit useState in einer Variable und liefern sie an unser Frontend aus.

Hier geht es zu dem [Beispielcode](https://stackblitz.com/edit/nextjs-server-actions-useeffect-method?file=components%2FShowPosts.tsx).

## Error Handling mit Server Actions

In unseren bisherigen Beispielen haben wir gänzlich auf die Fehlerbehandlung im Frontend verzichtet, daher würde ziemlich großer Wahrscheinlichkeit unsere App bei Fehlern abstürzen. Deswegen zeige ich hier noch, wie wir in unserem Beispiel mit `<form>`-Elementen und Server Actions Fehler abfangen können.

Damit wir dem Frontend die Fehlermeldung übergeben können, benötigen wir eine Client-Komponente. Damit unser Programm aber nicht abstürzt, müssen wir unsere Komponente dazu etwas umbauen. Da wir Server Actions inline innerhalb unseres Action-Elements in unserem `<form>`-Element aufrufen können, refaktorieren wir unseren Code aus dem ersten Beispiel so, dass wir bei einem Fehler mit useState den Fehler speichern und an unser Frontend übergeben.

Der Code vorher:

```jsx
// CreatePost.tsx

import { createPostAction } from '@/lib/actions';

export default function CreatePostForm() {
  async function createPost(formData: FormData) {
    'use server';

    const data = {
      title: formData.get('title') as string,
      body: formData.get('post-text') as string,
    };

    await createPostAction(data);
  }

  return (
    <form action={createPost}>
      <label className="block">Title</label>
      <input type="text" name="title" className="block mb-2" />

      <label className="block">Text</label>
      <textarea
        name="post-text"
        rows={4}
        className="block mb-2"
        placeholder="Post Text"
      ></textarea>
      <button type="submit" className="bg-slate-600 p-2">
        Create Post
      </button>
    </form>
  );
}
```
Wenn ihr hier auf "Create Post" geht wenn ihr nichts angegeben habt wird euch der Fehler nicht angezeigt nur wenn ihr innerhalb der Server Action die Antwort loggen würdet könntet ihr in der Server Console den Fehler sehen. Im schlimmsten fall stürzt aber auch eure App ab und um das zu verhinden zeigen weißen wir den User darauf hin das er Titel und Text angeben muss.

```ts
// actions.ts
'use server';
import { Post, PostForm } from '@/lib/types';

export async function createPostAction(postData: PostForm): Promise<Post> {
  try {
    const res = await fetch('https://jsonplaceholder.typicode.com/posts', {
      method: 'POST',
      body: JSON.stringify({
        title: postData.title,
        body: postData.body,
        userId: 1,
      }),
      headers: { 'Content-type': 'application/json; charset=UTF-8' },
    });
    // Fake response from API
    const data: Post = await res.json();

    // Show Post when click on "Create Post"
    console.log(data);

    return data;
  } catch (error) {
    console.log(error);
    throw new Error('Failed to create post');
  }
}
```

Der Code nach dem wir ihn Refaktoriert haben:

```jsx
//CreatePost.tsx
'use client';
import { createPostAction } from '@/lib/actions';
import { useState } from 'react';

export default function Form() {
  const [error, setError] = useState('');

  return (
    <form
      action={async (formData: FormData) => {
        const data = {
          title: formData.get('title') as string,
          body: formData.get('post-text') as string,
        };

        const result = await createPostAction(data);
        if ('error' in result) {
          setError(result.error);
        }
      }}
    >
      <label className="block">Title</label>
      <input type="text" name="title" className="block mb-2" />

      <label className="block">Text</label>
      <textarea
        name="post-text"
        rows={4}
        className="block mb-2"
        placeholder="Post Text"
      ></textarea>
      {error && <p className="text-red-400">{error}</p>}
      <button type="submit" className="bg-slate-600 p-2">
        Create Post
      </button>
    </form>
  );
}
```

```ts
// actions.ts
'use server';
import { Post, PostForm } from '@/lib/types';

export async function createPostAction(
  postData: PostForm
): Promise<Post | { error: string }> {
  // Check if title and body is not empty
  if (!postData.title || !postData.body) {
    return { error: 'Title and body are required.' };
  }

  try {
    const res = await fetch('https://jsonplaceholder.typicode.com/posts', {
      method: 'POST',
      body: JSON.stringify({
        title: postData.title,
        body: postData.body,
        userId: 1,
      }),
      headers: { 'Content-type': 'application/json; charset=UTF-8' },
    });
    // Fake response from API
    const data: Post = await res.json();

    // Show Post when click on "Create Post"
    console.log(data);

    return data;
  } catch (error: any) {
    console.log(error);
    return { error: error.message };
  }
}

```
Das war's auch schon! So einfach könnt ihr in Formelementen mit Fehlern umgehen. Diese können natürlich auch anders dargestellt werden, z.B. mit einer Toast-Message oder Ähnlichem.

## Fazit

In diesem Beitrag habe ich euch gezeigt, wie man mit Server Actions in Next.js arbeitet. Wir haben uns angesehen, wie Server Actions in Formelementen, durch Event-Handler und in Kombination mit dem useEffect-Hook verwendet werden können. Dabei habe ich auch erklärt, wie ihr mit Fehlern umgehen könnt.

Server Actions bieten einige Vorteile, wie die Reduzierung von Client-Server-Roundtrips und die Möglichkeit, Async/Await in euren Komponenten zu nutzen. Allerdings gibt es auch Kritikpunkte, wie die Vermischung von Zuständigkeiten zwischen Client und Server und Bedenken hinsichtlich der Skalierbarkeit.

Ob sich Server Actions letztendlich durchsetzen werden, bleibt abzuwarten, da die Community dazu gespalten ist. Aber mit etwas Übung und Anpassung könnt ihr die Vorteile dieser neuen Funktionalität voll ausschöpfen und eure Anwendungen optimieren.

Ich hoffe, dieser Beitrag hat euch einen guten Überblick gegeben und ihr habt nun mehr Klarheit darüber, wie ihr Server Actions in euren Projekten einsetzen könnt. Viel Spaß beim Ausprobieren und Entwickeln!


Next.js Server Actions: Form, Event Handler und useEffect - so geht's!

future42_Security_in_the_Web_Networked_Server_securitya_vinta_b43dd4c2-45d9-4509-9fff-08f231b8f7ef_0.png

Super Simple

Next.js Server Actions

next.js

nextjs

Im Ökosystem der modernen Webentwicklung ist die nahtlose Integration von Frontend und Backend über verschiedene Ursprünge hinweg ein wesentliches Element. Doch diese Integration stellt Entwickler:innen oft vor eine Herausforderung: die 'Same-Origin Policy' (SOP), eine Sicherheitsmaßnahme, die verhindert, dass eine Webseite Skripte ausführt, die auf Daten von einem anderen Ursprung als dem eigenen zugreifen. Hier kommt CORS, oder Cross-Origin Resource Sharing, ins Spiel.

CORS ist eine Technik, die es Webanwendungen ermöglicht, die Einschränkungen der SOP zu umgehen und sicher auf Ressourcen von anderen Ursprüngen zuzugreifen. Es ist ein Konzept, das in der heutigen vernetzten Welt, in der APIs und externe Dienste eine zentrale Rolle spielen, von großer Bedeutung ist. Bevor CORS weit verbreitet war, griffen Entwickler:innen oft auf Lösungen wie JSONP (JSON with Padding) zurück, die zwar funktional, aber nicht ohne Sicherheitsbedenken waren.

In diesem Artikel werden wir uns anschauen, wie CORS funktioniert, warum es für die Entwicklung moderner Webanwendungen unerlässlich ist und wie es in Node.js mit dem CORS-Paket implementiert wird. Von den Grundlagen der 'Simple Requests' bis hin zu den komplexeren 'Preflight-Requests' decken wir alle wichtigen Aspekte ab, die wir als Entwickler:in wissen müssen, um die Kommunikation zwischen verschiedenen Ursprüngen sicher und effizient zu gestalten.

## Einführung in CORS (Cross-Origin Resource Sharing) und JSONP (JSON with Padding)

Im Bereich der Webentwicklung ist das Konzept von Cross-Origin Resource Sharing (CORS) von zentraler Bedeutung. Es ermöglicht Webanwendungen, die Einschränkungen der 'Same-Origin Policy' (SOP) zu überwinden.

Vor der Etablierung von CORS griffen Entwickler:innen oft auf JSONP (JSON with Padding) zurück, um Cross-Origin-Datenabrufe zu ermöglichen. JSONP nutzte Skript-Tags, um Daten von anderen Ursprüngen zu laden, indem es die Einschränkungen der SOP umging. Obwohl diese Methode funktionierte, war sie nicht ohne Mängel. Sicherheitsbedenken, wie die Anfälligkeit für Cross-Site Scripting (XSS) Angriffe, und Designeinschränkungen, wie die Begrenzung auf GET-Anfragen, machten JSONP zu einer suboptimalen Lösung.

CORS hingegen bietet eine sicherere und flexiblere Alternative. Durch das Definieren spezifischer Regeln und Header ermöglicht CORS Webseiten den sicheren Zugriff auf Ressourcen über Ursprünge hinweg. Es erlaubt Entwickler:innen, moderne Webanwendungen zu erstellen, die nahtlos Dienste und APIs von verschiedenen Ursprüngen integrieren können. Von der einfachen Abfrage von Daten bis hin zu komplexen API-Interaktionen hat CORS die Art und Weise, wie Webanwendungen kommunizieren, revolutioniert.

## Grundlagen und Anwendungsfälle von CORS

CORS (Cross-Origin Resource Sharing) ist eine Technik, die ein grundlegendes Problem in der Webentwicklung adressiert, welches durch die 'Same-Origin Policy' (SOP) entsteht. Die SOP dient als Sicherheitsmaßnahme, indem sie festlegt, dass Skripte auf einer Webseite nur auf Ressourcen desselben Ursprungs zugreifen dürfen. Obwohl dies eine wichtige Sicherheitsvorkehrung ist, kann es die Funktionalität legitimer Anwendungen, die auf die Integration verschiedener Online-Dienste angewiesen sind, einschränken.

CORS ermöglicht die Kommunikation zwischen unterschiedlichen Ursprüngen, ohne die Sicherheit zu beeinträchtigen, indem es spezielle HTTP-Header verwendet. Es ist nicht auf bestimmte HTTP-Methoden wie GET, POST oder DELETE beschränkt und bietet somit eine vielseitige Lösung für eine Vielzahl von Anwendungen. Im Gegensatz zu JSONP, das nur GET-Anfragen unterstützt, ist CORS flexibler und sicherer.

Die Notwendigkeit von CORS entsteht hauptsächlich, wenn eine Webanwendung auf Ressourcen oder Dienste zugreifen muss, die auf einem anderen Ursprung als dem eigenen gehostet werden. Ein typisches Beispiel hierfür ist eine Benutzeroberfläche (UI), die unter einer Domain wie 'www.beispiel-ui.com' läuft und auf eine API unter einer anderen Domain wie 'api.beispiel-service.com' zugreifen muss.

Es ist wichtig zu erwähnen, dass CORS nicht für alle Arten von Cross-Origin-Anfragen benötigt wird. Browser erlauben beispielsweise das Laden von JavaScript oder CSS von einem CDN oder das Einbinden von iFrames von anderen Webseiten, solange diese Anfragen die GET-Methode verwenden. Für komplexere Interaktionen, insbesondere solche, die POST- oder PUT-Anfragen beinhalten oder Benutzerdaten und authentifizierte Sessions verarbeiten, wird CORS jedoch unerlässlich.

In der Praxis müssen Entwickler:innen verstehen, wann und warum CORS in ihren Anwendungen erforderlich ist. Es ist ein Balanceakt zwischen der Sicherheit und der Funktionalität der Anwendung. CORS ermöglicht es, diese Interaktionen auf eine sichere und kontrollierte Weise zu handhaben, was es zu einem unverzichtbaren Werkzeug in der modernen Webentwicklung macht.

## CORS Konfiguration auf dem Server

Die Implementierung von CORS ist primär eine serverseitige Aufgabe. Während die Client-Seite, zum Beispiel die Benutzeroberfläche einer Webanwendung, CORS-Anfragen initiieren kann, liegt es am Server, diese Anfragen entsprechend den definierten CORS-Richtlinien zu akzeptieren oder abzulehnen. Diese Herangehensweise stellt sicher, dass die Kontrolle über die Zugriffsrechte bei der vertrauenswürdigen Seite – dem Server – liegt.

Die Konfiguration von CORS auf dem Server beinhaltet in der Regel die Definition spezifischer HTTP-Header, die festlegen, welche Ursprünge Zugriff auf die Ressourcen des Servers haben dürfen. Der wohl bekannteste dieser Header ist Access-Control-Allow-Origin, der entweder einen spezifischen Ursprung oder ein Wildcard-Symbol (*) enthalten kann. Während die Verwendung eines Wildcards für öffentlich zugängliche Ressourcen wie Schriftarten oder Bibliotheken aus einem CDN sinnvoll sein kann, ist es für sensible Daten empfehlenswert, spezifische Ursprünge anzugeben, um die Sicherheit zu erhöhen.

*Ein wichtiger Aspekt bei der Konfiguration von CORS ist, dass alle modernen Browser CORS-Regeln unterstützen und durchsetzen. Sogar ältere Browser wie der Internet Explorer 11 bieten Unterstützung für CORS.*

Im Falle eines Cross-Origin-Zugriffs sendet der Browser automatisch einen 'Origin-Header' mit der Anfrage. Dieser Header informiert den Server über den Ursprung der Anfrage. Der Server prüft dann diesen Ursprung gegen seine CORS-Richtlinien und entscheidet, ob die Anfrage akzeptiert oder abgelehnt wird. Wird die Anfrage akzeptiert, fügt der Server den entsprechenden Access-Control-Allow-Origin-Header zur Antwort hinzu. Dieser Prozess ist transparent und wird vollständig vom Browser und dem Server gehandhabt, sodass die Client-Anwendung in der Regel keine zusätzliche Konfiguration benötigt.

## Methoden in CORS (Simple Requests & Preflight-Requests)

### Simple Requests

Simple Requests in CORS sind Anfragen, die bestimmte Kriterien erfüllen und daher keiner vorherigen Genehmigung durch den Server bedürfen. Diese Anfragen verwenden üblicherweise Methoden wie GET, HEAD oder POST. Eine wichtige Bedingung für Simple Requests ist, dass der Content-Type der Anfrage entweder application/x-www-form-urlencoded, multipart/form-data oder text/plain sein muss.

Bei einem Simple Request fügt der Browser automatisch den Origin-Header hinzu. Der Server prüft diesen Origin und, wenn er mit den CORS-Richtlinien des Servers übereinstimmt, antwortet er mit dem Access-Control-Allow-Origin-Header in seiner Antwort. Diese Vorgehensweise ermöglicht eine einfache und effiziente Abwicklung von Cross-Origin-Anfragen für alltägliche Szenarien.

In Node.js können Simple Requests mit dem CORS-Paket und Express wie folgt implementiert werden:

```js
const express = require('express');
const cors = require('cors');

const app = express();

// Einfache CORS-Konfiguration: Erlaubt Zugriffe von allen Ursprüngen
app.use(cors());

app.get('/simple-route', (req, res) => {
    res.json({ msg: 'Simple Request erfolgreich' });
});

app.listen(3000, () => {
    console.log('Server läuft auf Port 3000');
});
```
*Dadurch das wir hier keine Optionen festlegen wird automatisch ein Wildcard gesetzt `Access-Control-Allow-Origin: *` also alle Clienten haben zugriff.*

Unser Beispiel oben erlaubt ja alle externen Anfragen, Simple Requests erlaubt aber auch die Spezifiierung was erlaubt ist:

- HTTP-Methoden: GET, HEAD, POST.
- Nur bestimmte Standard-Header wie `Accept`, `Accept-Language`, `Content-Language`, `Content-Type `(aber nur mit bestimmten Werten wie `application/x-www-form-urlencoded`, `multipart/form-data`, `text/plain`) sind erlaubt.
- Keine zusätzlichen manuellen HTTP-Header.

Hier ist ein Beispiel, wie ein Simple Request mit spezifischem Origin Header in Node.js aussehen könnte:

```js
const express = require('express');
const cors = require('cors');

const app = express();

// CORS für Simple Requests mit spezifischem Origin
app.use(cors({
    origin: 'http://example.com'
}));

app.get('/simple-route', (req, res) => {
    res.json({ msg: 'Simple Request mit spezifischem Origin' });
});

app.listen(3000, () => {
    console.log('Server läuft auf Port 3000');
});
```

### Preflight-Requests

Preflight-Requests sind für komplexere Anfragen vorgesehen, die nicht den Kriterien für Simple Requests entsprechen. Dazu zählen Anfragen, die andere HTTP-Methoden als GET, HEAD oder POST verwenden oder Anfragen, die einen anderen Content-Type als die für Simple Requests zugelassenen haben. Ein Preflight-Request wird mit der HTTP-Methode OPTIONS vor der eigentlichen Anfrage gesendet und enthält Header wie Access-Control-Request-Method und Access-Control-Request-Headers, die dem Server mitteilen, welche Art von Anfrage folgen wird.

Der Server antwortet auf den Preflight-Request mit Headern, die angeben, ob die eigentliche Anfrage zulässig ist. Diese Antwort kann Header wie Access-Control-Allow-Methods und Access-Control-Allow-Headers enthalten, die spezifizieren, welche Methoden und Header in der tatsächlichen Anfrage verwendet werden dürfen.

Wenn die Anfragen über die Kriterien von Simple Requests hinausgehen was folgende Punkte einschließt:

- Verwendung anderer HTTP-Methoden als GET, HEAD, POST.
-Hinzufügen von nicht standardmäßigen HTTP-Headern oder Verwendung von Content-Types außerhalb der für Simple Requests erlaubten.
- Anfragen, die mit Credentials (wie Cookies) gesendet werden.

Hier ist ein Beispiel für eine CORS-Konfiguration, die einen Preflight-Request benötigen würde:

```js
const express = require('express');
const cors = require('cors');

const app = express();

// Detaillierte CORS-Konfiguration für Preflight-Requests
const corsOptions = {
    origin: 'http://example.com', // Spezifischer Ursprung
    methods: 'POST', // Erlaubte Methoden
    allowedHeaders: ['Content-Type', 'Authorization'] // Erlaubte Header
};

// Aktiviert CORS nur für diese spezielle Route mit den definierten Optionen
app.options('/complex-route', cors(corsOptions)); // Preflight-Request
app.post('/complex-route', cors(corsOptions), (req, res) => {
    res.json({ msg: 'Preflight Request erfolgreich bearbeitet' });
});

app.listen(3000, () => {
    console.log('Server läuft auf Port 3000');
});
```

### Preflight-Requests Responses

Die Antwort des Servers auf einen Preflight-Request kann verschiedene Header enthalten, die die Regeln für die folgende eigentliche Anfrage festlegen. Zu diesen Headern gehören Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Expose-Headers, Access-Control-Max-Age, Access-Control-Allow-Methods und Access-Control-Allow-Headers. Diese Header geben an, welche Ursprünge, Methoden und Header für die Cross-Origin-Anfrage erlaubt sind und wie lange die Antwort des Preflight-Requests gültig bleibt.

Durch die Kombination dieser CORS-Methoden können Entwickler:innen in Node.js aber auch jeder anderen Programmiersprache die Kommunikation zwischen verschiedenen Ursprüngen auf eine sichere und kontrollierte Weise handhaben, was die Entwicklung von robusten und interaktiven Webanwendungen ermöglicht.

***Sources:***

[Express CORS Docs](https://expressjs.com/en/resources/middleware/cors.html) 


[Wikipedia](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing)

CORS: Ermöglicht sichere Web-Interaktionen über verschiedene Hosts

retro-cors.png

Cross-Origin Resource Sharing

CORS

security

Von for und while bis zu forEach und map, entdecke die Javascript Schleifen-Typen.

javascript-loops.webp

Javascript und seine Schleifen-Typen

Ein Ritt durch Iterationen

javascript

tutorial

howto

Worker Threads stehen seit der Node.js-Version 10.5 als experimentelles Feature zur Verfügung und wurden in der [Version 12.11.0](https://nodejs.org/docs/v12.11.0/api/worker_threads.html) auch als stabil eingestuft. Zum Zeitpunkt dieses Artikels war die Node.js-Version 20.9.0 die aktuelle LTS-Version.

JavaScript ist traditionell eine Singlethreaded-Sprache, was bedeutet, dass alle Operationen nacheinander in einem einzigen Thread ausgeführt werden. Dies hat zur Folge, dass unser Programm warten muss, bis die letzte Aufgabe im Main-Thread abgearbeitet ist, was dazu führen kann, dass unsere Anwendung einfriert. 
Um dieses Problem zu lösen, wird in JavaScript die Aufgabenbearbeitung über den sogenannten Event-Loop gesteuert. Der Event-Loop ermöglicht es, asynchron und nicht-blockierend zu agieren, selbst wenn JavaScript eine Single-Threaded-Sprache ist. I/O-Aufgaben (Netzwerkanfragen, Dateizugriffe und Benutzereingaben), die in der Regel nicht rechenintensiv sind, können somit durch den Event-Loop asynchron abgearbeitet werden.

Wer mehr über den Event-Loop erfahren möchte dem lege ich zwei Videos ans Herz, das eine etwas kürzer das andere etwas länger.

https://www.youtube.com/watch?v=lqLSNG_79lI https://www.youtube.com/watch?v=cCOL7MC4Pl0

Die asynchrone Bearbeitung unserer Aufgaben ist in der Regel der synchronen Verarbeitung und den Worker Threads vorzuziehen. Leider trifft dies nicht auf rechenintensive Aufgaben wie beispielsweise Bildkomprimierung oder komplexe Berechnungen zu. Diese könnten den Main-Thread blockieren und somit unsere Anwendung zum Einfrieren bringen. Genau aus diesem Grund wurden Worker Threads eingeführt.

Worker Threads ermöglichen es uns, Aufgaben auf verschiedene Threads zu verteilen. Dies hat den Vorteil, dass der Main-Thread frei bleibt und unsere Anwendung reibungslos weiterlaufen kann. Die Verteilung der Aufgaben auf mehrere Threads kann zudem zu einem Leistungsgewinn führen.

Jetzt könnte man logischerweise annehmen, einfach alle Aufgaben in Worker Threads auszulagern. An dieser Stelle muss ich jedoch enttäuschen: In der Regel ist das asynchrone Abarbeiten von Aufgaben die effizientere Methode und meistens den Worker Threads vorzuziehen. Dies liegt häufig daran, dass Worker Threads einen hohen Overhead mit sich bringen, da jeder Worker erst gestartet werden muss. Das führt dazu, dass die asynchrone Bearbeitung der Aufgaben in den meisten Fällen auf aktuellen Computern schneller ist. Nur bei wirklich rechenintensiven Aufgaben könnte es sinnvoll sein, auf Worker Threads zurückzugreifen.

Ich möchte anhand der Berechnung von Fibonacci-Zahlen erläutern, wann es sinnvoll ist, auf Worker Threads zu setzen und wann man darauf vielleicht verzichten sollte.

## Exkurs: Fibonacci-Folge

Damit alle wissen was Fibonacci-Zahlen sind und auch um den Code weiter unten besser zuverstehen hier ein versuch das euch etwas näher zubringen. Ihr könnt es aber auch überspringen da ich einfach eine möglichkeit gebraucht habe Komplexe berechnungen durchzuführen. Aber auch ganz unabhängig vom Nutzen von Fibonacci-Zahlen.

### Was ist nun die Fibonacci-Folge?

Die Fibonacci-Folge ist eine Folge von Zahlen, bei der jede Zahl die Summe der beiden vorherigen Zahlen ist. Die Sequenz beginnt typischerweise mit 0 und 1.

```bash
n-0 + n-1 + n-1
n-2 + n-3 + n-5
n-8 + n-13 + n-21
n-34 + n-55 + n-89
n-144 ...
```
Eine kleine kleine Analogie für Dummies ;-)

Stell dir die Fibonacci-Folge als eine Reihe von Boxen vor welche hintereinander aufgereit sind. Jede der Boxen enthält eine Zahl. Die ersten zwei Boxen haben also die Zahl 0 und 1.

Wenn du die Zahl der nächsten Box wissen möchtest addiere die zahlen aus den letzten beiden Boxen:

```bash
Box1: 0
Box2: 1
Box3: 1 // 0 + 1
Box4: 2 // 1 + 1
Box5: 3 // 1 + 2
Box6: 5 // 2 + 3
```
## Vergleich zwischen Main-Thread und Worker-Thread

Ich habe hier eine iterative Fibonacci-Funktion in node.js erstellt, die alle Fibonacci-Zahlen nur einmal berechnet und sie in einem Array speichert. Diese Methode ist sehr effizient und hilft uns gut zu simulieren, wann der Einsatz von Worker Threads aus Performance-Gründen sinnvoll ist und wann eher nicht.

## Ohne Worker Threads

```js
const rounds = 100;

const fibonacci = (n) => {
  const numbers = [0, 1];
  for (let i = 2; i <= n; i++) {
    numbers[i] = numbers[i - 1] + numbers[i - 2];
  }
  return numbers[n];
};

const startWithoutWorker = Date.now();
for (let i = 0; i < rounds; i++) {
  fibonacci(100);
  process.stdout.write(`\r${i + 1}/${rounds}`);
}
const endWithoutWorker = Date.now();
console.log(
  ` Total duration without worker threads (ms): ${
    endWithoutWorker - startWithoutWorker
  }`
);
```
Wir beginnen mit der Berechnung und legen fest, dass diese 100-mal durchgeführt werden soll. Dies wiederholen wir 100-mal damit wir die Auslastung besser simulieren. Das Ergebnis sieht wie folgt aus:

```bash
100/100 Total duration without worker threads (ms): 5
```
100.000-mal:
```bash
100/100 Total duration without worker threads (ms): 127
```
1.000.000-mal:
```bash
100/100 Total duration without worker threads (ms): 1378
```
10.000.000-mal:
```bash
100/100 Total duration without worker threads (ms): 10790
```
All unsere Berechnungen wurden im Event-Loop ausgeführt (Single-Threaded). Zum Vergleich schauen wir uns nun die gleichen Berechnungen mit Worker Threads an.

## Mit Worker Threads

![Javascript Worker Threads {{ w: 1000, h: 300 }}](/uploads/Javascript_Worker_Threads_67c1927e7b.svg) 

Dazu erstellen wir zwei Dateien: eine "worker.js", der wir die Aufgaben zur Berechnung übergeben, und eine Datei, die den Worker aufruft, "index.js". Beginnen wir mit der letzteren. Ich werde hier nicht auf die Funktionsweise und die Implementierung von Worker Threads eingehen; dafür empfehle ich, die [Node.js-Dokumentation](https://nodejs.org/docs/v20.9.0/api/worker_threads.html)!

```js
// index.js
import { Worker } from "worker_threads";

const rounds = 100;
const maxConcurrentWorkers = 16;

let completedRounds = 0;

const startWithWorker = Date.now();

function runWorker() {
  if (completedRounds >= rounds) {
    return;
  }

  const worker = new Worker("./worker.js");
  worker.on("message", (result) => {
    completedRounds++;
    process.stdout.write(`\r${completedRounds}/${rounds}`);
    if (completedRounds === rounds) {
      const endWithWorker = Date.now();
      console.log(
        `\nTotal duration with worker threads (ms): ${
          endWithWorker - startWithWorker
        }`
      );
      process.exit();
    } else {
      runWorker();
    }
  });
  worker.postMessage(100);
}

for (let i = 0; i < maxConcurrentWorkers; i++) {
  runWorker();
}
```
Genau wie in unserem Beispiel ohne Worker Threads führen wir die Berechnung 100-mal durch (const rounds = 100;). Da wir nun aber mit Worker Threads arbeiten, können wir diese Berechnungen auf die Worker auslagern und sie parallel durchführen, was als "Parallelisierung" bezeichnet wird. Hierbei ist zu beachten, dass man bei CPU-intensiven Aufgaben in der Regel einen Worker pro CPU-Thread verwenden möchte. Bei stark I/O-lastigen Aufgaben in einem Worker Thread könnte es jedoch sinnvoll sein, mehr Worker pro CPU-Thread zu nutzen. Da wir eine stark CPU-gebundene Berechnung durchführen, macht es Sinn, nur so viele Worker zu erstellen, wie wir CPU-Threads zur Verfügung haben. In meinem Fall sind das bei meiner CPU (Ryzen 5800X3D) 16 Threads.

Und hier noch der Code für den Worker:

```js
// worker.js
import { parentPort } from "worker_threads";

const fibonacci = (n) => {
  const numbers = [0, 1];
  for (let i = 2; i <= n; i++) {
    numbers[i] = numbers[i - 1] + numbers[i - 2];
  }
  return numbers[n];
};

parentPort.on("message", (n) => {
  const result = fibonacci(n);
  parentPort.postMessage(result);
});
```

Beginnen wir also nun mit unseren Berechnungen, dieses Mal jedoch mit Worker Threads.

100-mal:
```bash
Total duration with worker threads (ms): 605
```
100.000-mal:
```bash
Total duration with worker threads (ms): 730
```
1.000.000-mal:
```bash
Total duration with worker threads (ms): 1222
```
10.000.000-mal:
```bash
Total duration with worker threads (ms): 5237
```
10.000.000-mal (mit nur einem Worker):
```bash
Total duration with worker threads (ms): 14259
```
Was wir jetzt sehen, ist folgendes: Bis zu 1.000.000 Durchläufen ist die Fibonacci-Berechnung im Main-Thread deutlich schneller als die Berechnung mit Worker Threads. Erst bei einer sehr hohen Anzahl an Fibonacci-Berechnungen machen sich die Worker Threads bemerkbar. Und auch das nur, wenn wir genügend Worker bereitstellen. Begrenzen wir dies auf nur einen Worker, dauert die Berechnung sogar deutlich länger. Die Gründe dafür sind vielfältig, der wichtigste ist jedoch der hohe Overhead den Worker Threads mit sich bringen.

Jeder Worker muss zunächst eine V8-Instanz starten, was sowohl Zeit kostet als auch zusätzlichen Speicher belegt. Das bedeutet, das man zusätzlich auch den Speicherbedarf im Auge behalten muss.

## Fazit

Unser kleines Experiment zeigt, dass in den meisten Fällen der Einsatz von Worker Threads nicht empfehlenswert ist, zumindest wenn es darum geht, die Performance der Anwendung zu steigern. Nur für wirklich rechenintensive Aufgaben könnten Worker Threads relevant sein.

Ein weiterer Pluspunkt für Worker Threads könnte bei Aufgaben liegen, die parallel im Hintergrund ablaufen können und nicht auf Benutzereingaben angewiesen sind. Zum Beispiel könnte ein Programm einen Bilderupload anbieten und die Bilder im Hintergrund komprimieren. Dadurch bleibt der Main-Thread und somit der Event-Loop frei, und die Anwendung läuft nicht Gefahr, einzufrieren.

Ich hoffe, ich konnte etwas Licht ins Dunkel von "Worker Threads" bringen. Falls ich Fehler gemacht habe oder etwas unklar ist, lasst es mich gerne in den Kommentaren wissen.


Ich möchte hier zeigen wann es sinn macht Worker Threads einzusetzen und wann ihr es vielleicht lassen solltet

JavaScript-Worker-Threads-Single-Threaded-vs-Mult-Threaded.png

Singlethread- vs. Multithread

Javascript Worker Threads

nodejs

Obwohl es eine ausführliche [Dokumentation](https://domo-2.gitbook.io/brc-20-experiment/) von den Erstellern des BRC20 Token Standards gibt, ist diese in vielen Teilen sehr theoretisch. Das ist grundsätzlich gut, aber wenn man nur alle paar Monate Zeit hat, sich mit dem Thema Ordinals und dessen Ökosystem auseinanderzusetzen und jedes Mal erneut die Dokumentation durchgehen muss, finde ich das eher lästig als hilfreich. Deshalb habe ich mich entschlossen, eine kleine Schritt-für-Schritt-Anleitung zu erstellen, wie man Tokens erstellt, mintet und transferiert.

Dieses Tutorial setzt voraus, dass eine vollständig synchronisierte Bitcoin-Core Wallet und Ord Wallet installiert wurde. Weiterhin gehe ich davon aus, dass jemand, der die Ord Wallet installiert hat, auch weiß, wie er sie bedienen muss. Daher werde ich in diesem Beitrag nicht weiter darauf eingehen. Solltet ihr dennoch Interesse an einer Anleitung dazu haben, lasst es mich in den Kommentaren wissen.

**Vorrausetzungen zusammengefasst:**

- Vollständig synchronisierte Bitcoin-Core Wallet
- [Ord Wallet Installiert](https://github.com/ordinals/ord)
- Einige UTXOs auf der Ord Wallet vorhanden

## 1. Deploy: Wie du deinen eigenen BRC20 Token erstellst

### 1.1 Deploy Textdatei erstellen

Zuerst erstellen wir eine Textdatei. Dabei ist es wichtig, dass der MIME-Typ: "text/plain" und der Zeichensatz "charset=utf-8" ist.

Wie dies funktioniert, variiert je nach Betriebssystem. IDEs und Editoren wie Notepad++ zeigen jedoch in der Regel an, welcher Zeichensatz und welcher MIME-Typ gesetzt ist. In dieser Anleitung erkläre ich den Vorgang für Linux bzw. die Shell. Dies sollte auch unter Windows in einer WSL-Shell funktionieren.

Ich erstelle meine Textdatei mit "iconv" und nenne meinen Token beispielhaft "sil3":

```bash
echo "" | iconv -t UTF-8 > deploy-sil3.txt
```
### 1.2 Token Spezifizieren

Jetzt bestimmen wir, wie unser Token heißen soll und welche Menge davon vorhanden sein wird. Im Grunde spezifizieren wir unseren Token, um ihn später fest und unveränderlich in der Timechain zu verankern.

Bearbeitet nun die Textdatei und fügt den folgenden Inhalt ein. Passt dabei natürlich den Namen "tick", die maximal verfügbare Menge an Token "max" und das Limit "lim" für die maximale Anzahl an Token pro Minting-Vorgang an.

```json
{
  "p": "brc-20",
  "op": "deploy",
  "tick": "sil3",
  "max": "21000000",
  "lim": "1000"
}
```
Hier eine Kurze Erklärung was die Einzellnen Schlüssel bedeuten:

"p": = Protokoll: Hilft anderen Systemen, Brc-20-Ereignisse zu identifizieren und zu verarbeiten
"op": = Operation: Art des Ereignisses (Bereitstellen, Mint, Transfer)
"tick": = Ticker: max. 4-Buchstaben-Kennung des BRC-20
"max": = Max. Versorgung: Stellen Sie die maximale Versorgung des BRC-20 ein
"lim": = Max. Limit pro Mint

### 1.3 Token einschreiben (Inscribe)

Jetzt können wir unseren Token deployen. Dies geschieht mit dem folgenden Befehl und bitte lesst vorab die Erläuterung durch:

```bash
ord wallet inscribe --destination  ZIEL_ADRESSE ~/deploy-sil3.txt --fee-rate 26
```

**Erläuerung:**

--destination:

Dies ist ein optionaler Befehl, den ich euch jedoch empfehlen würde einzusetzen. In unserem Fall gehen wir davon aus, dass wir uns vorab eine Adresse mit dem Befehl `wallet receive generiert haben. Diese Adresse sollten wir immer beim Minten und Transferieren angeben. Der Grund dafür ist, dass die Ord Wallet bei Nichtangabe jede Inscription auf eine neue Adresse schreibt. Das bedeutet, wenn wir z.B. 10 Mal eine Mint-Inscription für unsere Tokens erstellt haben, besitzen wir auch 10 verschiedene Adressen. Möchten wir nun 10.000 Tokens (10 x 1.000) versenden, müssten wir für jede dieser Adressen eine Transfer-Inscription erstellen, da die Tokens der einzelnen Adressen nicht zusammengefasst werden können. Dies ist nur möglich, wenn alle Tokens auf derselben Adresse liegen. So sparen wir letztendlich sowohl Zeit als auch Transaktionsgebühren.

--fee-rate:

> Wichtig: Prüft Vorab auf https://mempool.space/ welche Gebühren aktuell erhoben werden, setzt diese nicht zu niedrig!

![Mempool_TX_Fees {{ w: 590, h: 223 }}](
/uploads/Mempool_TX_Fees_8afcd1a1b2.png?format=webp&quality=100) 

> Notiz: Ihr könnt als Ziel-Adresse natürlich auch jede andere Taproot Adresse angeben. Beachtet aber dabei das nicht alle Wallets wissen wie Sie mit Inscriptions umgehen sollen. Daher nutzt nur Offiziel unterstützte Wallet (Unisat, Xverse, Hiro, Ordinalsafe).

> Optional: Wenn ihr den Befehl vorab testen wollt schreibt einfach ein `--dry-run` hinter `wallet inscribe`.

Nach dem ihr den Befehl abgesendet habt, solltet ihr eine ähnliche Ausgabe erhalten:

```json
{
  "commit": "..",
  "inscription": "...",
  "reveal": "...",
  "fees": 9594
}
```

commit: Ist die TXID welche ihr jetzt mit Mempool verfolgen könnt. Einfach danach suchen.

### 1.4 Prüfen

Ob alles erfolgreich war prüfe ich immer auf OKX da ich finde das dieser den besten Ordinals Explorer bietet. Ihr könnt aber auch jeden anderen nutzen der euch genug Informationen liefert.

Beispiel ORDI Token: [OKX-Explorer](https://www.okx.com/explorer/btc/inscription/brc20/348020) 

## 2. Mint: Token erstellen

Nach dem wir mit "Deploy" unseren Token definiert haben kann nun jetzt jeder User mit dem "Mint" Prozess sich seinen Anteil an Tokens sichern.

### 2.1 Mint Textdatei erstellen

Genau wie beim Deployment erstellen wir uns wieder ein Textdatei.

```bash
echo "" | iconv -t UTF-8 > mint-sil3.txt

```

Der Inhalt schaut nur ein wenig anders aus:

```json
{
  "p": "brc-20",
  "op": "mint",
  "tick": "sil3",
  "amt": "1000"
}
```
Erläuterung:

amt: Gibt den zu prägenden Betrag des BRC-20 an.

> Wichtig: "amt" darf nicht das Limit überschreiten welches wir im Deployment festgelegt haben.

### 2.2 Mint einschreiben (Inscribe)

Der Befehl ist der selbe wie beim Deployment vorgang, wir müssen nur das richtige Textfile angeben. Ich empfehle hier auch wieder immer auf die gleiche Adresse (destination) die Tokens zu Minten.

```bash
ord wallet inscribe --destination  ZIEL_ADRESSE ~/mint-sil3.txt --fee-rate 26
```

Nach dem ihr den Befehl abgesendet habt, solltet ihr eine ähnliche Ausgabe erhalten:

```json
{
  "commit": "..",
  "inscription": "...",
  "reveal": "...",
  "fees": 9594
}
```
Ob alles geklappt hat kann wieder mit dem [OKX-Explorer](https://www.okx.com/explorer/btc/inscription/brc20/348032) überprüft werden.

> Notiz: Natürlich könnt ihr beim Minten auch direkt in eure Unisat oder Xverser Wallet Minten. Dann ist "Punkt 3. Transfer" für euch nicht mehr wichtig.

## 3. Transfer: Tokens versenden

Der Transfer ist etwas umständlich und besteht aus folgenden schritten:

- Einschreiben (Inscribe) "Transfer"
- Senden von "Transfer" Inscription an Zieladresse

### 3.1 Vorbereitung

Wir müssen hier stets eine "--destination" angeben, die ausreichend Token besitzt. Deshalb ist es so wichtig, dass wir beim Minten immer dieselbe Adresse verwenden. Nehmen wir an, dass wir 10-mal 1.000 Tokens auf die gleiche Adresse gemintet haben, können wir nun bis zu 10.000 Tokens direkt transferieren.

Wie beim Deployment und Minten, erstellen wir uns wieder ein Textdatei.

```bash
echo "" | iconv -t UTF-8 > transfer-sil3.txt

```

Dieses Mal fügen wir folgenden Inhalt hinzu und geben bei der zu transferierenden Menge (amt) in unserem Beispiel "5000" Tokens an, die wir versenden möchten:

```json
{
  "p": "brc-20",
  "op": "transfer",
  "tick": "TokenName",
  "amt": "5000"
}
```
### 3.2 Transfer einschreiben

Wie auch schon beim Deployen und Minten ist auch hier die vorgehensweise die selbe. Wir geben bei unserem Befehl die --destination an welche genug Tokens hält (min. soviele wie wir versenden möchten) und achten darauf das wir die eben erstellte transfer-sil3.txt Datei angeben.

```bash
ord wallet inscribe --destination  ZIEL_ADRESSE ~/transfer-sil3.txt --fee-rate 26
```
Nach dem ihr den Befehl abgesendet habt, solltet ihr eine ähnliche Ausgabe erhalten:

```json
{
  "commit": "..",
  "inscription": "...",
  "reveal": "...",
  "fees": 9594
}
```
### 3.3 Prüfen

Sobald die Transaktion bestätigt wurde könnt ihr wieder in eurem [Explorer](https://www.okx.com/explorer/btc/inscription/brc20/348126) eurer Wahl prüfen ob der Token Transfer gültig ist. 

## 4. Versenden von Tokens an eine andere Adresse

Dieser vorgang ist jetzt relativ simpel. Ihr sendet einfach die eben erstellte "Transfer" Inscription an eine andere Ordinals fähige Adresse.

Dies geht mit folgenden Befehl:

```bash
ord wallet send --fee-rate 26 DESTINATION ADRESSE INSCRIPTION_ID
```

**Erläuterung:**

Destination Adresse: Wohin ihr die Tokens verschiecken wollt
INSCRIPTION_ID: Die Inscription ID von der eben erstellten "Transfer" Inscription.

## Fazit

Der Umgang mit dem BRC20-Token kann anfangs überwältigend erscheinen. Trotz umfassender Dokumentationen fehlt es oft an praxisnahen Anleitungen. Deshalb habe ich dieses Tutorial erstellt, um die Token-Erstellung, -Prägung und -Transferierung verständlich darzustellen. Besonders hervorzuheben ist die Bedeutung von einheitlichen Adressen beim Minten. Dies spart nicht nur Zeit, sondern auch Transaktionsgebühren. Mit dieser Anleitung hoffe ich, Einsteigern einen klaren und einfachen Weg im Umgang mit dem BRC20-Token und der Ord Wallet aufzuzeigen.






Praxisnaher Leitfaden zum Erstellen, Prägen und Transferieren von BRC20-Tokens.

future42_Coriolis_effect_4465e033-9a97-4b39-8ab8-3a6f42d05a1d.png

Alles was du wissen musst

Deploy, Mint und Transfer mit der Ord Wallet

bitcoin

brc20

ordinals

Es ist vermutlich ein normaler Werdegang, dass sich Gemeinschaften ihre eigene Sprache und Bezeichnungen aneignen. Grundsätzlich ist das nicht verwerflich. Gerade dann wenn diese noch nach einer Identität suchen.

Es sollte jedoch spätestens dann hinterfragt werden, wenn es möglicherweise Menschen ausschließt oder sogar rechte Narrative bedient. Daher möchte ich am Beispiel der "Bitcoin-Zitadelle" darauf eingehen und erklären, warum ich sie für gefährlich halte.

## Bitcoin-Zitadellen

Das Konzept der "Bitcoin-Zitadellen" ist ein futuristisches Szenario, das in der Bitcoin-Community diskutiert wird. Es basiert auf der Idee, dass, wenn der Wert von Bitcoin weiter steigt, es zu einer neuen Gesellschaftsordnung führen könnte. In dieser leben Menschen, die früh in Bitcoin investiert haben, in befestigten Städten (Zitadellen). Diese Städte würden als Zufluchtsorte dienen, um die Reichtümer und den Lebensstil der Bitcoiner:innen zu schützen.

![Lina Seiche Citadel {{ w: 1000, h: 300 }}](/uploads/lina_seiche_citadel_98a3bd0051.jpg) 
Source: Lina Seiche https://thelittlehodler.com/de/gallery/

Im Jahr 2013 veröffentlichte ein Reddit-Benutzer namens Luka Magnotta einen [Beitrag](https://www.reddit.com/r/Bitcoin/comments/1lfobc/i_am_a_timetraveler_from_the_future_here_to_beg/), in dem er behauptete, ein Zeitreisender aus dem Jahr 2025 zu sein. Er beschrieb eine dystopische Zukunft, in der Bitcoin-Investoren in befestigten Städten, den sogenannten "Bitcoin Zitadellen", leben.

Zusammengefasst beschreibt der Artikel von Magnotta die Zukunft als eine extrem ungleiche Gesellschaft. In dieser ist Bitcoin so wertvoll geworden, dass nur diejenigen, die in Bitcoin investiert haben, überleben.

Es ist wichtig zu erkennen, dass das ursprüngliche Konzept als dystopische Warnung gedacht war, aber von einigen in der Community als utopisches Ideal aufgegriffen wurde. Der Artikel legt nahe, dass, während einige das Konzept buchstäblich nehmen, es für viele eine Metapher für finanzielle Souveränität und Unabhängigkeit von traditionellen Regierungen und Finanzsystemen ist. Es gibt auch Beispiele für tatsächliche Versuche, solche Gemeinschaften zu schaffen, obwohl diese nicht erfolgreich waren (Bitcointopia, MS Satoshi). Auch wenn hier wichtig ist zu erwähnen das dass Scheitern nicht auf Bitcoin zurückzuführen war sondern vielmehr etwas mit den Menschen welche diese Projekte durchführten zutun hatte.

Ein Beispiel (wenn auch nicht direkt bezugnehmend auf Bitcoin) für solche Gemeinschaften aus der Gegenwart sind die sogenannten "Private Cities". Private Cities sind städtische Gebiete, die von privaten Unternehmen statt von Regierungen verwaltet werden. Diese Unternehmen sind dafür verantwortlich, grundlegende Dienstleistungen wie Sicherheit, Infrastruktur und Versorgungseinrichtungen bereitzustellen. Die Idee hinter Private Cities ist es, effizientere und wettbewerbsfähige städtische Umgebungen zu schaffen, indem man die Bürokratie reduziert und mehr unternehmerische Freiheit ermöglicht.

Für viele Bitcoiner:innen klingt dieses Konzept schlüssig und aus einem marktspezifischen Blickwinkel sicherlich auch logisch. Das Problem ist jedoch, dass Private Cities soziale Ungleichheit fördern können, da sie nur für diejenigen zugänglich sind, die entweder das passende Kleingeld besitzen oder mindestens zur Philosophie dieser Stadt/Zitadelle passen.

Einfach ausgedrückt, könnten Bitcoin-Zitadellen möglicherweise Diskriminierung fördern, da nur diejenigen willkommen sind, die vermeintlich dazu passen und die nötigen SATS (kleinste Einheit von Bitcoin) besitzen.

Natürlich sind das nur meine subjektiven Annahmen und vielleicht darf man auch ohne Bitcoins in diese Städte. Aber wenn wir einmal für fünf Minuten das Thema Geld ausblenden und darüber nachdenken, ob wir nicht in einer offenen Welt leben möchten, in der jeder Mensch überall willkommen ist, weil er in erster Linie 'Mensch' ist, dann sind Mauern und unternehmerisch geführte Kommunen womöglich nicht die beste Wahl.

Mir ist natürlich bewusst, dass, wie bereits oben erwähnt, nicht alle dieses Konzept buchstäblich nehmen und es für viele nur eine Metapher für finanzielle Souveränität ist. Leider wird dass meiner Meinung nach in der Community nicht ausreichend hinterfragt, was es tatsächlich bedeutet, in Zitadellen zu leben.

## Warum ich glaube das Bitcoin-Zitadellen eher konträr zur Idee von Bitcoin stehen

Ich war vor einigen Wochen mit einer Freundin auf der [Ostrale](https://ostrale.de/de/Archiv/OSTRALE-O23.html) in Dresden, einer Ausstellung zeitgenössischer Kunst. Dort ist mir vor allem das Kunstwerk von "Matteo Suffritti" aufgefallen, da es sich mit dem Phänomen auseinandersetzt, dass wir in einem Glashaus leben und der Großteil der Welt in Armut vor unseren Toren hockt. Das Kunstwerk definiert einen privilegierten Raum, in Höhe, Tiefe und Breite. Dieser Raum ist fast unpassierbar und nur schwer zu erschließen. Innerhalb dieses Raums geht es allen Menschen gut, aber am Rand stapeln sich die Favelas. Auch wenn der Künstler ein Problem der Gegenwart anspricht, war es für mich ein Ansporn, diesen Artikel hier zu schreiben da ich viele parallelen zu den Bitcoin-Zitadellen befürchte.
![Matteo Suffritti Host Communities 3 {{ w: 1000, h: 300 }}](/uploads/IMG_3673_4168361d5a.jpg) 

#### Damit alle verstehen warum ich glaube das Zitadellen nicht zum Konzept von Bitcoin passen hier eine kurze Auflistung.

**Dezentralisierung**: Bitcoin wurde ursprünglich als dezentralisiertes Zahlungsmittel entworfen, das der Kontrolle einzelner Einheiten entzogen ist und das weltweit verfügbar ist. Die Konzentration von Bitcoin in bestimmten geographischen Standorten oder Gemeinschaften, wie es in einer "Bitcoin-Zitadelle" der Fall wäre, könnte als eine Form der Zentralisierung betrachtet werden.

**Zugänglichkeit und Inklusion**: Eine der Hauptziele von Bitcoin ist es, ein inklusives Finanzsystem zu schaffen, das für alle zugänglich ist, unabhängig von ihrer geographischen Lage oder ihrem wirtschaftlichen Status. Die Idee von Bitcoin-Zitadellen könnte diese Zugänglichkeit einschränken, indem sie Gemeinschaften schafft, die nur für diejenigen zugänglich sind, die bereits Bitcoin besitzen oder die finanziellen Mittel haben, um darin zu investieren.

**Risiko von Ungleichheit**: Bitcoin-Zitadellen könnten das Potenzial haben, soziale und wirtschaftliche Ungleichheiten zu verstärken. Wenn der Zugang zu diesen Gemeinschaften auf diejenigen beschränkt ist, die bereits in Bitcoin investiert haben, könnte dies die Kluft zwischen den "Haves" und den "Have-nots" (arm und reich) vergrößern.

**Entgegenwirken der Dezentralisierung der Macht**: Die Grundidee von Bitcoin ist es, die Macht zu dezentralisieren und sie in die Hände der vielen zu legen, statt sie bei wenigen zu konzentrieren. Bitcoin-Zitadellen könnten jedoch genau das Gegenteil bewirken, indem sie die Macht in den Händen einer kleinen Gruppe von Menschen oder Organisationen konzentrieren, die die Kontrolle über diese Gemeinschaften haben.

## Mangelnde Kritikfähigkeit in bestimmten Teilen der Community

In einer Podcast-Folge des YouTube-Kanals "Blocktrainer", die vor einigen Jahren ausgestrahlt wurde, durfte Titus Gebel über seine Privatstädte in Honduras berichten. Anhand dieses Beispiels möchte ich aufzeigen, dass Narrative in der Community oft festgefahren sind und der Diskurs aus ideologischer Sicht verhindert wird. Was mich an dem Gespräch störte, war die fehlende Kritik und die ausschließliche Debatte darüber, wie Bitcoin dabei helfen kann, diese Projekte voranzutreiben.

Als ich mich kritisch zu dem Gespräch in den Kommentaren äußerte und auf die vermeintlichen Interessen und Verbindungen (Degusa Goldhandel, Peter Thiel) von Titus Gebel hinwies und auf die Arbeit von Andreas Kemper aufmerksam machte, wurde mir vom Blocktrainer entgegengetreten. Er sagte, dass er Andreas Kempers Arbeit kennt und einige davon zwar gut findet, aber weil Andreas Kemper ein bekennender Sozialist ist, dem Ganzen nichts abgewinnen kann. Leider kann ich den Wortlaut nicht mehr vollständig wiedergeben, da diese Podcast-Folge gelöscht wurde und somit auch sämtliche Kommentare. Ich möchte auch gar nicht gänzlich gegen die Idee schießen doch sind die Verbindungen und Interessen dieser Leute vermutlich eher Konträr zu dem was Bitcoin will.

*Generell, ich habe nichts gegen den Blocktrainer! Ich halte einen großen Teil seiner Arbeit zur Aufklärung über Bitcoin, besonders im Blick auf komplexe technische Aspekte, für wichtig. Da er jedoch auch eine große Reichweite hat und vermutlich die erste Anlaufstelle für viele neue Bitcoiner:innen hinsichtlich der Informationsbeschaffung ist, finde ich es wichtig, ihn zu kritisieren.*

Wir könnten jetzt noch über einige weitere Begrifflichkeiten sprechen (Gesundes Geld, Steuern sind Raub, ...) aber ich denke ich belasse es dabei und hoffe das ich zumindest etwas zum nachdenken anregen konnte. Denn manchmal steckt hinter einem vermeintlich Harmlosen Narrativ mehr als man zuerst vermuten mag.

Ich kann das Buch von Andreas Kemper empfehlen "[Privatestädte: Labore für einen neuen Manchesterkapitalismus](https://www.thalia.de/shop/home/artikeldetails/A1062788947)". Mir hat es geholfen die Idee hinter Privatstädten besser einordnen zu können.

Das Konzept der "Bitcoin-Zitadellen" ist ein futuristisches Szenario, das in der Bitcoin-Community diskutiert wird.

bitcoin-citadel.png

Warum ich glaube das Bitcoin-Zitadellen keine gute idee sind

Bitcoins Narrative

*"Seit ich Bitcoin entdeckt habe, lese ich Bücher"* - ein Satz den ich so oder so ähnlich, in den letzten Jahren immer häufiger in meinem Umfeld und auf Twitter lese und der mich zu tieferen Überlegungen anregt.

An diesem Satz ist prinzipiell nichts auszusetzen und natürlich spielt der Kontext eine große Rolle. Man könnte argumentieren, dass das Entdecken neuer Wissensgebiete - sei es noch so spät - stets zu begrüßen ist. Dennoch bereitet mir diese Aussage ein gewisses Unbehagen. Seit 2013 vertiefe ich mich regelmäßig in Themen wie Politik, Ökonomie und natürlich Bitcoin. Und bis heute habe ich keine endgültige Meinung darüber, ob die von der Österreichischen Schule und von Menger propagierte Grenznutzenlehre wirklich die ultimative ökonomische Theorie darstellt, unter deren Prämissen Bitcoin gedeihen kann. Oder ob das nicht doch nur ein feuchter Traum von ein paar ziemlich Libertären Typen ist. Who cares...

Wenn ich mich ausschließlich mit Literatur beschäftige, die unausweichlich die gleichen Narrative verfolgt, wie kann ich dann eine fundierte, umfassende Meinung entwickeln? Meiner Ansicht nach ist dies nur Menschen möglich, die sich bereits im Vorfeld entschieden haben, was sie glauben wollen und was nicht. Denn je mehr ich lese, je mehr Blogbeiträge, Podcasts und Videos ich konsumiere, desto stärker wird mir bewusst: Die Welt ist nicht schwarz und weiß. Um uns ein differenziertes Urteil zu erlauben, müssen wir allen Stimmen Gehör schenken und in Betracht ziehen, ob unsere Überzeugungen hin und wieder hinterfragt und neu bewertet werden müssen.

Die nächsten zwei Artikel, wobei der zweite noch in Arbeit ist, setzen sich kritisch mit der "Bitcoin Community" auseinander - hauptsächlich, aber nicht ausschließlich, richten sie sich an Bitcoiner:innen. Die Vielfalt in dieser Szene wird oft unterschätzt und viele plappern nur nach, was gut klingt. Genau das steht hier zur Debatte.

## Kenne beide Seiten der Medaille

Es wird zunehmend herausfordernd für mich, ständig den Behauptungen von Bitcoiner:innen begegnen zu müssen. Diese vertreten unablässig die Meinung, dass eine frühzeitige finanzielle Bildung der Schlüssel dafür sei, die Notwendigkeit eines stabilen Wertspeichers zu verstehen. Darüber hinaus insistieren sie vehement darauf, dass Bitcoin als einzige geeignete Lösung für dieses Bedürfnis betrachtet werden sollte.

Es wird vorgeschlagen, dass wir die Grundlagen unseres Geld- und Wirtschaftssystems bereits frühzeitig in den Schulen vermitteln sollten. Dies geschieht in der Erwartung, dass Kinder eigenständig zu dem Schluss kommen, Inflation sei schädlich und Deflation - insbesondere in Form von Bitcoin - die Rettung der Menschheit darstellt. Jedoch bin ich der Ansicht, dass die Realität nicht so schwarzweiß ist. Es erfüllt mich immer wieder mit Fragen, wie Bitcoiner:innen sich dieses Bildungsmodell konkret vorstellen. Sollen wir einfach jedes Kind mit dem "[Bitcoin Standard](https://www.thalia.de/shop/home/artikeldetails/A1056553952)" ausstatten und sagen: Lies dies und du wirst die Überlegenheit von Bitcoin erkennen? Oder sollten wir vielleicht zunächst sorgfältig in Erwägung ziehen, ob es nicht sinnvoller wäre, unsere Kinder und alle Menschen, die möglicherweise keine Fachkenntnisse haben, selbst über die Wahl zwischen einer deflationären oder inflationären Welt entscheiden zu lassen?

Es fällt mir schwer, die Selbstzufriedenheit zu akzeptieren, die behauptet, wir könnten einfach alle Menschen aufklären, indem wir sie dazu anhalten, die "richtigen" Bücher zu lesen und den "richtigen" Stimmen Gehör zu schenken. Selbstverständlich bin ich davon überzeugt, dass Bildung essentiell ist. Gleichwohl ist es von ebenso großer Bedeutung, dass Bildung nicht zu einer Einbahnstraße wird. Wir benötigen kritisch und unabhängig denkende Menschen, um den zukünftigen Herausforderungen gewachsen zu sein. Daher ist es unabdingbar, dass wir Menschen ermutigen, beide Seiten der Medaille zu erkunden - und dies betrifft nicht nur Finanzen, sondern auch die allgemeine, soziale und ethische Bildung.

Die Vorstellung, man könne lediglich die richtige "Orange Pill" (eine Anspielung auf die [Matrix](https://en.wikipedia.org/wiki/Red_pill_and_blue_pill) und übrigens auch fast ein eigener [Artikel](https://www.deutschlandfunkkultur.de/matrix-pille-verschwoerungstheorie-100.html) wert) zu sich nehmen, um eine Art finanzielle Erleuchtung zu erlangen, halte ich für mindestens diskussionswürdig. Was wir stattdessen anstreben sollten, ist eine offene, vielfältige Bildungslandschaft, welche den Menschen die Möglichkeit bietet, sich eine fundierte eigene Meinung zu bilden. Und das bedeutet zwangsläufig, sich über das Lesen von dem "Bitcoin Standard" oder anderen themenrelevanten Büchern hinaus zu informieren.

Ich möchte nicht behaupten, dass wir keine finanzielle Bildung benötigen. Doch ich möchte betonen, dass niemand das Monopol auf Weisheit besitzt. Daher schlage ich vor, anstatt voreilige Urteile wie "Inflation ist schlecht, Deflation ist gut" zu fällen, erst einmal eine Vielzahl von Büchern und Quellen heranzuziehen und zu sehen, wo wir schlussendlich landen. Und das bedeutet auch, sich mit konträrer Literatur zu befassen, die sich eingehend mit der anderen Seite der Medaille auseinandersetzt.

Es ist von größter Bedeutung zu betonen, dass niemand fälschlicherweise den Eindruck gewinnen sollte, ich würde die Bedeutung von Deflation nicht anerkennen. Im Zuge meiner Recherchen bin ich zu der Erkenntnis gelangt, dass wir aufgrund technologischer Fortschritte zunehmend in eine deflationäre Welt hineinsteuern. Angesichts dieser Veränderungen ist es durchaus möglich, dass ein deflationäres Zahlungsmittel in einer solchen deflationären Welt sich als die optimale Wahl erweisen könnte.

Ich möchte diesen Artikel mit einem Zitat von [Niels Bohr](https://de.wikipedia.org/wiki/Niels_Bohr) beenden.

Aus dem Englischen:

> There are trivial truths and there are great truths. The opposite of a trivial truth is plainly false. The opposite of a great truth is also true.

Frei übersetzt:

> Es gibt trivialer Weise zwei Arten von Wahrheiten: tiefe Wahrheiten, die von ihrem Gegenteil anerkannt werden, und oberflächliche Wahrheiten, deren Gegenteil unwahr ist.

Dieses Zitat stammt aus "[The Philosophical Writings of Niels Bohr, Volume 1: Atomic Theory and the Description of Nature](https://www.amazon.com/gp/product/091802451X/ref=x_gr_bb_amazon?ie=UTF8&tag=x_gr_bb_amazon-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=091802451X&SubscriptionId=1MGPYB6YW3HWK55XCGG2)". Es drückt für mich die Komplexität der Wahrheit aus und impliziert, dass es oft mehrere Perspektiven oder Interpretationen gibt.

### Literatur empfehlungen

["Der Preis der Zukunft"](https://www.thalia.de/shop/home/artikeldetails/A1061748452) in diesem Buch argumentiert Jeff Booth, dass technologischer Fortschritt zu einer unausweichlichen Deflation führt, was radikale Änderungen in unserer Wirtschaftsstruktur erfordert, um Wohlstand und soziale Stabilität zu sichern.

In ihrem Buch ["Dieses Mal ist alles anders: Acht Jahrhunderte Finanzkrisen"](https://www.thalia.de/shop/home/artikeldetails/A1058898641) analysieren die Wirtschaftswissenschaftler:innen Carmen M. Reinhart und Kenneth S. Rogoff Finanzkrisen über einen Zeitraum von 800 Jahren und argumentieren, dass trotz technologischer oder institutioneller Fortschritte Finanzkrisen ein wiederkehrendes Phänomen sind, das durch exzessive Schuldenausweitung getrieben wird.

In ["Allgemeine Theorie der Beschäftigung, des Zinses und des Geldes"](https://www.duncker-humblot.de/buch/allgemeine-theorie-der-beschaeftigung-des-zinses-und-des-geldes-9783428150489/?page_id=1) argumentiert John Maynard Keynes, dass bei unzureichender Nachfrage Arbeitslosigkeit auftreten kann und dass in solchen Zeiten staatliche Interventionen und Ausgaben notwendig sind, um die volle Beschäftigung und wirtschaftliche Stabilität zu fördern. Ich habe nie Ökonomie Studiert aber ich frage mich ob dieses Buch teil des Studiums ist?

Und zu guter Letzt noch die bei Bitcoiner:innen verhasste MMT (Modern Monetary Theory) und einem Buch von Maurice Höfgen [Mythos Geldknappheit: Modern Monetary Theory oder warum es am Geld nicht scheitern muss](https://www.amazon.de/Mythos-Geldknappheit-Modern-Monetary-scheitern-ebook/dp/B088R6PNZW) - ich finde, man sollte es zumindest einmal gelesen haben, um vielleicht besser argumentieren zu können, auch wenn der Autor so gerne alle Bitcoiner:innen so unangenehm polemisch über einen Kamm schert.

*Title Image Midjourney:*

```bash
 A open book divided into two, with war raging on both sides
```

"Seit ich Bitcoin entdeckt habe, lese ich Bücher" - Eine Aussage dir mir zudenken gibt.

Bildung sollte keine Einbahnstraße sein - Bitcoin - Sil3ntrunning

Bildung_sollte_keine_einbahnstraße_sein.png

Kenne beide Seiten der Medaille

Bildung sollte keine Einbahnstraße sein

## Vorwort

Kriege, Flüchtlingswellen, Populismus: all das hat mich dazu gebracht, zu hinterfragen, warum die Welt so ist, wie wir sie kennen. Eine wichtige - wenn auch nicht die einzige - Antwort auf diese Frage ist unser Geld und wie Regierungen, durch Entwertung und [monetären Kolonialismus](https://bitcoinmagazine.com/culture/bitcoin-a-currency-of-decolonization) die Kontrolle über ganze Länder innehaben. Beispiel Frankreich mit dem [CFA-Franc](https://www.bpb.de/shop/zeitschriften/apuz/geldpolitik-2022/507738/der-cfa-franc/). Ich glaube Bitcoin kann weit mehr sein als nur ein Investment, ein Klimasünder oder das Geld für Kriminelle. Das ist also ein versuch das Interesse bei dir zu wecken und zuzeigen was mit Bitcoin möglich ist.

Ich bin kein Ökonom und es gibt sicherlich viele Menschen, die ein detaillierteres Wissen zu diesen Themen haben. Ich habe darüber nachgedacht, ob ich mir überhaupt eine Meinung dazu bilden kann und darf. Trotzdem habe ich den Mut gefasst und versuche hier, einen kurzen Überblick darüber zu geben, warum Bitcoin für so viele Menschen auf der Welt eine Hilfe sein kann und warum es mich nach über 10 Jahren immer noch nicht los lässt.

Schüttel also deine Vorurteile ab und viel Spaß beim Lesen 😀 

![ {{ w: 1000, h: 300 }} ](/uploads/Bitcoin_Eine_globale_Perspektive_fuer_Finanzielle_Inklusion_c61c729376.png) 

## Bitcoin: Eine Bottom-up-Bewegung

In seinem Artikel ["Bitcoin Is A Trojan Horse For Freedom"](https://bitcoinmagazine.com/culture/bitcoin-is-a-trojan-horse-for-freedom), veröffentlicht im Bitcoin Magazine, entfaltet [Alex Gladstein](https://hrf.org/team/alex-gladstein/) eine tiefgründige Analyse. Er argumentiert, dass Bitcoin weit mehr ist als nur eine "Number-Go-Up"-Technologie, die Gier und Eigeninteresse befeuert. Vielmehr sieht er Bitcoin als eine "Freedom-Go-Up"-Technologie, die eine uneinnehmbare Bastion gegen jegliche Form von Autorität darstellt.

Gladstein zieht eine faszinierende Parallele zur griechischen Mythologie des ["Trojanischen Pferdes"](https://de.wikipedia.org/wiki/Trojanisches_Pferd). Diese hölzerne Skulptur in Pferdegestalt, platziert vor den Toren Trojas, verbarg in ihrem Inneren griechische Krieger:innen. Nachdem die Trojaner:innen das Pferd in ihre Stadt gebracht hatten, nutzten die verborgenen Soldat:innen die Dunkelheit, um die Stadttore von innen zu öffnen und den Weg für das restliche griechische Heer zu ebnen.

Gladstein nutzt diese Metapher, da sie treffend illustriert, warum Bitcoin einerseits unzerstörbar ist und andererseits mit der Zeit die Finanzsysteme von innen heraus verändern wird. Die Gier der westlichen Welt nach mehr Reichtum und Wohlstand hat Bitcoin erst zu dem gemacht, was es heute ist. Bitcoin ist das Trojanische Pferd, das den Eliten von innen die Möglichkeit raubt, sich einen finanziellen Vorteil ([Cantillon-Effekt](https://de.wikipedia.org/wiki/Cantillon-Effekt)) zu verschaffen. Denn im Gegensatz zu konventionellen Geldsystemen, die zentral von Staaten und Banken gesteuert werden, ist es bei Bitcoin nicht möglich, diese Kontrolle zentral auszuüben. Diesen Vorteil nutzen nun Menschen weltweit, um sich von der Abwertung und Fremdbestimmung durch ihre Regierungen zu befreien. Für die Ärmsten dieser Welt kann Bitcoin also eine Lösung sein.

Die Schriften und Arbeiten von Alex Gladstein, [Anita Posch](https://anitaposch.com/) und vielen anderen haben meine Überzeugung bestärkt, dass Bitcoin nicht nur für uns in der westlichen Welt von Bedeutung ist. Tatsächlich stellen wir eine Minderheit im globalen Kontext dar, da die Mehrheit der Menschen - etwa 4 Milliarden - in Ländern mit politischer Unterdrückung, hoher Inflation und Korruption lebt. Für diese Menschen kann Bitcoin eine lebensrettende Leine und ein Ausweg aus finanzieller Unterdrückung sein.

Um dies bildlich zu veranschaulichen, hat die Human Rights Foundation eine Grafik veröffentlicht, die zeigt, dass über 50 % der Weltbevölkerung unter autoritären Regierungen leben, in denen es nicht möglich ist, frei zu sprechen und zu leben.

![Human rights foundation {{ w: 1000, h: 300 }}](/uploads/Authoritarianism_map_151a473477.png) 

*Source: https://hrf.org/about/mission/*

## Wahrnehmung und Realität

In den Medien besteht weitgehend der Konsens, dass Bitcoin nichts weiter ist als eine Spekulationsanlage und ein Pyramidensystem ohne intrinsischen Wert. Aus der Perspektive einer Person aus Mitteleuropa oder Nord Amerika erscheint die Notwendigkeit eines Zensurresistenten und dezentralen Zahlungsmittels oft nicht gegeben. Dies liegt daran, dass wir das Privileg haben, in stabilen Demokratien mit funktionierenden Finanzsystemen und mit zuverlässigen Dienstleistern wie PayPal zu leben.

Ich denke daher, dass unsere Systeme vorerst weiterhin so funktionieren werden, wie sie es derzeit tun. Soziale und wirtschaftliche Probleme werden wir durch unsere etablierten Mittel der Geldschöpfung lösen und versuchen über Gesetze zu lenken. In diesem Kontext wird Bitcoin wohl nur eine untergeordnete Rolle spielen. Aber die Gier der Menschen wird Bitcoin weiter wachsen lassen und es ist zu spät das jemand etwas dagegen unternehmen kann. 

## Bitcoin als Werkzeug der Emanzipation: Das Beispiel Roya Mahboob

Es gibt zahlreiche Beispiele, in denen Bitcoin Menschen geholfen hat, Repressionen zu überwinden und ihre Lebensumstände zu verbessern, oder zumindest ihre Hoffnungen und Möglichkeiten erweitert hat.

Ein inspirierendes Beispiel ist das von [Roya Mahboob](https://de.wikipedia.org/wiki/Roya_Mahboob), einer afghanischen Unternehmerin, die Bitcoin zur Förderung der finanziellen Unabhängigkeit von Frauen in Afghanistan einsetzt. Sie gründete Citadel Software, ein Unternehmen, das hauptsächlich Frauen beschäftigt. Sie begann, ihre Mitarbeiter:innen in Bitcoin zu bezahlen, was es ihnen ermöglichte, ihr Einkommen vor den Männern in ihrem Land zu verbergen. Einige dieser Frauen konnten ihre Bitcoin-Ersparnisse nutzen, um ein neues Leben in anderen Ländern zu beginnen.

Artikel (engl.): https://bitcoinmagazine.com/culture/bitcoin-financial-freedom-in-afghanistan
Übersetzung (dt.): https://bitcoinsozial.de/der-weg-zu-finanzieller-freiheit-in-afghanistan/ 

Ich könnte viele weitere Beispiele bringen, doch glaube ich, sollte ich in dir Interesse geweckt haben wirst du selbstständig deinen Weg finden. Wenn du aber einen kleinen anstoß benötigst liste ich am ende des Artikels noch einige Links zu Podcasts und Büchern auf.

Es liegt jetzt also an dir, herauszufinden, ob Bitcoin einen Mehrwert bieten kann, jenseits von Spekulation und Gier. Und falls du auf eine andere Schlussfolgerung kommst lass es mich gerne wissen. Auch ich habe noch nicht alle Antworten gefunden und bin offen für andere Sichtweisen.

----------
#### Weiterführendes

Mein Artikel basiert zu einem großen Teil auf den Artikeln von Alex Gladstein welche im [Bitcoin Magazine](https://bitcoinmagazine.com/authors/alexgladstein) veröffentlicht wurden.

Wenn du diese Artikel gerne auf Deutsch lesen möchtest kann ich dir das Buch ["Das Trojanische Pferd der Freiheit: Bitcoin als Chance im Kampf um Selbstbestimmung und Menschenrechte"](https://www.amazon.de/gp/product/B0C6FDZZS3/ref=dbs_a_def_rwt_hsch_vapi_tkin_p1_i0) empfehlen.

![Das Trojanische Pferd der Freiheit {{ w: 300, h: 150 }}](/uploads/Das_Trojanische_Pferd_der_Freiheit_dbed2b0ee7.jpg) 

Dann gibt es noch ein Interview mit Anita Posch, sie ist regelmäßig in Afrika unterwegs und hilft Menschen Bitcoin zu verstehen und zu verwenden. Beim Podcast "Bitcoin verstehen" gibt es ein Interview mit ihr.

https://www.youtube.com/watch?v=a5jPDldaaQw

*Midjourney Prompt (Title image):*

```bash
People watch to the horizont, Sun as Bitcoin symbol, art by Hayao Miyazaki, style of Robert McCall and Jean Giraud Moebius and Craig Mullins, highly detailed, dynamic, expressive, clean lines, cinematic, stunning, realistic lighting and shading, vivid, vibrant
```

Mehr als nur Spekulation: Wie Bitcoin weltweit zur finanziellen Inklusion beiträgt

Bitcoin: Eine globale Perspektive für Finanzielle Inklusion

Bitcoin: Eine globale Perspektive für Finanzielle Inklusion.png

Wie Bitcoin das leben von so vielen verbessern kann

Hier ist ein kurzes Tutorial, wie ich meine SSH-Keys verwalte. Ich arbeite hauptsächlich mit der Shell und nutze keine Tools wie Putty.

Zuerst werde ich dir zeigen, wie ich mittels ssh-keygen meine Schlüssel generiere und dann möchte ich dir auch zeigen, wie ich über Aliase diese bequem auf der Shell verwende.

Als erstes legst du folgende Ordner und Dateien an:

Der Hauptordner für SSH:

```shell
mkdir -p ~/.ssh && chmod 700 ~/.ssh
```
Eine Datei, welche die Configs einbindet. Du gibst ihr direkt die entsprechenden Rechte, in diesem Fall Lese- und Schreibrechte (600), aber nur für den ausführenden Benutzer:

```shell
touch ~/.ssh/config && chmod 600 ~/.ssh/config
```
Einen Ordner für die Configs:
```shell
mkdir -p ~/.ssh/ssh_configs
```
Config Dateien:
```shell
touch ~/.ssh/ssh_configs/private.ssh_config
touch ~/.ssh/ssh_configs/work.ssh_config
``` 
Ich nutze eine Config für meine privaten SSH-Zugänge und eine Config für meine dienstlichen. Du kannst es so gestalten, wie du möchtest, oder auch alle in einer Datei verwalten und ggf. mit Kommentaren trennen.

Einen Ordner für die SSH Keys:

```shell
mkdir -p ~/.ssh/ssh_keys
```
Erstelle jeweils einen Ordner für die privaten und öffentlichen Schlüssel. Ich benenne sie nach den Kategorien in meinem Beispiel: 'private' und 'work':

```shell
mkdir -p ~/.ssh/ssh_keys/private
mkdir -p ~/.ssh/ssh_keys/work
```
Jetzt hast du alle Ordner und Dateien, welche du brauchst, um deine SSH-Keys über Aliase zu verwalten.

## SSH Key Algorithmus ed25519

Ich erstelle mittlerweile alle meine SSH-Keys nur noch mit dem Algorithmus `ed25519`, da dieser viele Vorteile bietet. `ed25519` ist ein Algorithmus, der auf der elliptischen Kurve [Curve25519](https://en.wikipedia.org/wiki/Curve25519) basiert. Curve25519 gehört zu einer Familie von Algorithmen der elliptischen Kurvenkryptographie (ECC), die für ihre hohe Sicherheit und Leistungseffizienz bekannt sind.

## Vorteile von ed25519

**Sicherheit**: ed25519 bietet eine sehr hohe Sicherheit, sogar bei relativ kurzen Schlüssellängen. Ein ed25519-Schlüssel mit einer Länge von 256 Bit bietet eine Sicherheit, die mit einem 3072-Bit-RSA-Schlüssel vergleichbar ist.

**Effizienz**: Im Vergleich zu anderen Algorithmen wie RSA benötigt ed25519 weniger Ressourcen (sowohl hinsichtlich des Speicherplatzes als auch der Prozessorzeit), um Schlüssel zu erzeugen, zu signieren und zu verifizieren.

**Kollisionsresistenz**: Während SHA-1, der in DSA und älteren Versionen von RSA verwendet wird, anfällig für Kollisionsangriffe ist, ist ed25519 gegen solche Angriffe resistent. [Kollisionsresistenz](https://de.wikipedia.org/wiki/Kollisionsresistenz)

**Schutz vor Side-Channel-Angriffen**: ed25519 wurde entwickelt, um widerstandsfähig gegen verschiedene Side-Channel-Angriffe zu sein, einschließlich Timing-Angriffen. [Side-Channel-Angriffen](https://de.wikipedia.org/wiki/Seitenkanalattacke)

*Für den fall das du dich tiefer einlesen möchtest habe ich einige quellen verlinkt.*

## SSH Key erstellen

Einen SSH-Key erstellst du mit folgendem Befehl:

```shell
ssh-keygen -t ed25519 -C "COMMENT" -f ~/.ssh/ssh_keys/private/<my_ssh_key>
```
Die einzelnen Optionen haben folgende Bedeutungen:

`-t ed25519`: Gibt den Typ des zu generierenden Schlüssels an. In diesem Fall wird ein ED25519-Schlüssel erzeugt.

`-C "COMMENT"`: Fügt einen Kommentar zum Schlüssel hinzu.

`-f ~/.ssh/ssh_keys/private/my-key`: Bestimmt den Dateipfad und den Namen der Schlüsseldatei. In diesem Fall wird der Schlüssel unter ~/.ssh/ssh_keys/private/my-key gespeichert. Wenn das Verzeichnis noch nicht existiert, muss es vor der Ausführung dieses Befehls erstellt werden.

Nachdem du diesen Befehl eingegeben hast, wirst du nach einer [Passphrase](https://en.wikipedia.org/wiki/Passphrase) gefragt. Wähle eine sichere und nur dir bekannte aus und bestätige diese Eingabe ein zweites Mal. Wenn alles erfolgreich durchgelaufen ist, solltest du nun folgende Ausgabe erhalten und im Ordner ssh_keys deinen Private und Public Key liegen haben.

```shell
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/ssh_keys/private/my-key
Your public key has been saved in /home/user/.ssh/ssh_keys/private/my-key.pub
The key fingerprint is:
SHA256:csdfsdfsdfsdfjeowiurff9weujfoiwefjowpef COMMENT
The key's randomart image is:
+--[ED25519 256]--+
|      o..+o      |
|     . +-=.      |
|    . .oO.=      |
| . o . B.B.+ .   |
|. = F + S.B = .  |
| o o o . + C .   |
|  . . o . =      |
| o-.   o .       |
|o*o              |
+----[SHA256]-----+
```
Den Public Key musst du nun auf deinem Server hinterlegen. Logge dich dazu mit ssh auf diesen ein und bearbeite die Datei `nano ~/.ssh/authorized_keys`.

Den Public Key findest du in der Datei `~/.ssh/ssh_keys/private/my-key.pub`, du erkennst die richtige Datei an der endung .pub diesen key kannst du auch mit anderen Kollegen
teilen da sich daraus nicht der Private-Key ableiten lässt.

Es kann sein das du deinen SSH Service auf deinem Server neuladen musst das kannst du in regel mit folgenden Befehl tun `service ssh reload`

## Aliase anlegen

Als erstes müssen wir in der `config` Datei den Pfad mit den Configs hinterlegen.

```shell
nano ~/.ssh/config
```
Und fügen dort folgende Zeile ein:

```shell
Include ~/.ssh/ssh_configs/*.ssh_config
```
Zuletzt müssen wir in der Config den Pfad zu unserem Private-Key hinterlegen:

Dazu bearbeite die folgende Datei:
```shell
nano ~/.ssh/ssh_configs/private.ssh_config
```
Nun fügen wir unsere Konfiguration ein:

```shell
# Irgendein Kommentar was dir hilft deine Settings zu unterscheiden
Host private private.myServer myServer
        HostName <DNS oder IP von deinem Server>
        User admin
        Port 22
        IdentityFile ~/.ssh/ssh_keys/private/my-key

#Weitere Keys...
...
```
Ich werde nicht weiter auf die Konfiguration eingehen da ich davon aussgehe das diese selbsterklärend ist.

Nun speicherst du die Datei und solltest über folgenden Befehl auf dich mit deinem Server verbinden können:

```shell
ssh private.myServer
```
*Tipp: Mit der Tabulator-Taste (TAB) kannst du dir deine Aliase anzeigen lassen, z.B. ssh private. TAB-Taste.*

## Fazit

Du hast gelernt, wie du mit der Shell und dem ssh-keygen Befehl eigene Schlüssel generierst. Zudem haben wir aufgezeigt, wie du diese Keys dank der Verwendung von Aliase bequem in der Shell verwalten kannst.

Mit dem Einsatz des ed25519 Algorithmus sorgst du für eine hohe Sicherheit deiner Schlüssel und profitierst gleichzeitig von dessen Effizienz.

Die Verwendung von Config-Dateien ermöglicht dir eine saubere Trennung zwischen privaten und dienstlichen SSH-Zugängen und erleichtert somit die Verwaltung deiner SSH-Keys. Der finale Schritt war das Erstellen eines SSH-Keys und das Hinzufügen von Aliase in deiner Konfigurationsdatei, um schnell und einfach auf deine Server zugreifen zu können.


*Quelllen:*

*Image: Midjourney*

```bash
A computer designed as a surreal chain lock, twisted and intricate, in the distinctive style of Moebius --ar 16:9 
```




Dieser Leitfaden zeigt dir, wie du SSH-Keys sicher generieren und effizient verwalten ...

SSH-Keys-Config-ed25519.png

Verwaltung von SSH-Keys mit der Shell

Von der Schlüsselgenerierung bis zur Verwaltung: SSH-Keys effektiv nutzen

shell

So schnell kann es gehen! Gerade habe ich meinen Blog online gebracht, in dem festen Glauben, dass hier alles funktioniert, da erhalte ich auch schon die erste Nachricht von einem Freund. Er wies mich darauf hin, dass ihm der Inhalt der Blogbeiträge nicht angezeigt wird. Ich wusste, dass dieser Freund seine Macs/iPhone-Geräte kaum aktualisiert, daher dachte ich mir, solange nicht jeder zweite mit diesem Problem konfrontiert wird, ignoriere ich es erst einmal. Da ich ausschließlich aktuelle Browser nutze und wir hier NextJS mit Client Side Rendering (CSR) verwenden (wodurch Benutzerfehler nicht protokolliert werden), habe ich vorsichtshalber Sentry in das Frontend eingebaut, um informiert zu werden, wenn jemand einen Fehler erhält.

## Was ist Sentry?

Ich werde sicher bald ein eigenes Tutorial zu Sentry schreiben, bis dahin hier eine kurze Erklärung: Sentry ist ein Open-Source-Tool zur Fehlerverfolgung, das Entwicklern dabei hilft, Probleme in ihrer Software zu erkennen und zu beheben. Es überwacht und protokolliert Fehler in Echtzeit, sodass Entwickler*innen sie analysieren und beheben können, um die Leistung ihrer Anwendungen zu verbessern.

## Wie lautet der Fehler?

Es dauerte nicht lange, bis ich weitere Meldungen von anderen Nutzern erhielt, die über das gleiche Verhalten informierten. Auch das Sentry-Log war gut gefüllt mit immer dem gleichen Fehler:

```js
React ErrorBoundary Error: Invalid regular expression: invalid group specifier name
```

![sentry Invalid regular expression {{ w:1000 h:300 }}](/uploads/Sentry_Invalid_Regular_Expression_a3bdb7e4c9.png) 

Nach etwas Recherche konnte ich den Fehler eingrenzen. Es war ein Problem mit dem ECMAScript 2018 (ES9) Feature „Lookbehind assertion“. Dazu später mehr.

Ich konnte es kaum glauben, laut [caniuse.com](https://caniuse.com/js-regexp-lookbehind) unterstützen im Jahr 2023 nur 83.97 % der Browser „Lookbehind assertion“. Hauptsächlich betrifft das natürlich fast ausschließlich ziemlich alte Browser und bei Sentry waren es meistens ältere iOS-Geräte.

## Was ist: Lookbehind assertion

Ich wage hier mal den Versuch, „Lookbehind assertion“ zu erklären. Ich gehe davon aus, dass du weißt, was reguläre Ausdrücke sind, wenn nicht, kannst du das [hier](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions) nachlesen.

"Lookbehind Assertion" ist ein Konzept in regulären Ausdrücken (RegEx), das es ermöglicht, Übereinstimmungen basierend auf dem Kontext zu finden, der einem bestimmten Muster vorausgeht.

Eine Lookbehind Assertion erweitert RegEx, indem es ermöglicht, Muster zu finden, die von einem bestimmten Kontext vorausgegangen sind. Zum Beispiel würde der reguläre Ausdruck `/(?<=@)username/` den String "username" finden, aber nur, wenn er von einem "@"-Zeichen vorausgegangen ist.

#### Es gibt zwei Arten von Lookbehind Assertions:

- Positive Lookbehind: „(?<=Y)X“ findet "X", aber nur, wenn "Y" direkt davor steht.
- Negative Lookbehind: „(?<!Y)X“ findet "X", aber nur, wenn "Y" nicht direkt davor steht.

## Einsatz von "Lookbehind Assertion"

Auf sil3ntrunning.net war es so das ich meine Beiträge im Markdown Format schreibe und damit ich meinen Bildern die Deminsionen direkt mitgeben kann habe ich diese in folgenden Format dem Alt Attribute mitgegeben:

```markdown
![MEIN-ALT-TAG {{ w: 1000, h: 500 }}](/uploads/PAPH-TO-IMG.png)
```

Mit "{{ w: 1000, h: 1000 }}" gebe ich meinem Bild über den Markdown-Editor die Größe mit. Ich habe eine Komponente, welche mein Markdown rendert und dort wird nach diesen Werten gefiltert. Dazu habe ich das RegEx-Feature "Lookbehind Assertions" genutzt.

```js
img: function ({ ...props }) {
    const substrings = props.alt?.split('{{');
    const alt = substrings[0].trim();

    const width = substrings[1]
      ? substrings[1].match(/(?<=w:\s?)\d+/g)[0]
      : 800;
    const height = substrings[1]
      ? substrings[1].match(/(?<=h:\s?)\d+/g)[0]
      : 400;

    return ( 
        <Image src={props.src} alt={alt} width={width} height={height} /> 
    );
},
```
Ich verwende in meinem Code also eine "positive Lookbehind Assertion": "/(?<=w:\s?)\d+/g".

`(?<=w:\s?)` ist die Lookbehind Assertion. Sie sagt: "Suche nach einem Muster, das von 'w: ' vorausgegangen wird". Das \s? bedeutet, dass ein Leerzeichen optional ist. Daher wird dieses Muster sowohl auf "w:1000" als auch auf "w: 1000" passen.

` \d+` ist das eigentliche Muster, nach dem gesucht wird. Es steht für eine oder mehrere Ziffern. In meinem Fall repräsentiert es die Breite des Bildes, welche ich im Alt-Attribut angebe.

Das `g` am Ende bedeutet, dass der reguläre Ausdruck global ist, d.h. er sucht nach allen Übereinstimmungen im gesamten String und nicht nur nach der ersten Übereinstimmung.

In meinem Beispiel würde die Sequenz also die Breite "1000" finden. Genau das Gleiche passiert natürlich auch für die Höhe.

## Die Lösung des Problems

Da aber anscheinend einige Browser dieses Feature nicht unterstützen und doch recht viele Nutzer ältere Geräte wie z.B. ein iPhone XS mit veraltetem Safari-Browser nutzen, habe ich mich daran gesetzt und meinen Code umgeschrieben.

```js
img: function ({ ...props }) {
    const substrings = props.alt?.split('{{');
    const alt = substrings[0].trim();

    const width = substrings[1]
      ? substrings[1].match(/w:\s?(\d+)/)[1]
      : 800;
    const height = substrings[1]
      ? substrings[1].match(/h:\s?(\d+)/)[1]
      : 400;

    return ( 
        <Image src={props.src} alt={alt} width={width} height={height} /> 
    );
},
```

#### Was mein RegEx nun macht:

`w:\s?` sucht nach dem Muster "w: " mit einem optionalen Leerzeichen.

`(\d+)`  ist eine Gruppe, die eine oder mehrere Ziffern darstellt. Die Klammern erzeugen eine "erfassende Gruppe", was bedeutet, dass der Teil des Strings, der mit diesem Muster übereinstimmt, separat von den anderen Teilen des Matches gespeichert und später abgerufen werden kann.

Das `[1]` am Ende des .match()-Aufrufs holt den Wert, der mit der ersten (und einzigen) Gruppe im regulären Ausdruck übereinstimmt.

Der Unterschied zu meinem ursprünglichen Code besteht darin, dass dieser Code nicht nach Zahlen sucht, die von "w: " bzw. "h: " vorausgegangen werden (was eine Lookbehind Assertion wäre), sondern stattdessen nach der gesamten Sequenz "w: " gefolgt von Zahlen bzw. "h: " gefolgt von Zahlen sucht und dann nur den Zahlenanteil extrahiert.

## Was ist besser?

Diese Frage lässt sich nicht so einfach beantworten. Im Hinblick auf die Browser-Kompatibilität würde ich empfehlen, auf die Variante zu setzen, die von den meisten JavaScript-Engines unterstützt wird.

Die Lesbarkeit von Lookbehind Assertions ist nicht gerade die einfachste. Auf der anderen Seite können Lookbehind Assertions den Code in einigen Fällen sauberer und einfacher gestalten, indem sie es ermöglichen, genauer zu definieren, wonach man sucht.

Letztendlich musst du selbst entscheiden, was du einsetzen möchtest. Ich habe mich letztendlich für die Browser-Kompatibilität entschieden.


Quellen:

Image: Midjourney

```javascript
/imagine prompt  A Computer screen with an error message in a dark room, watercolored pencil, comic, vivid, vibrant --ar 16:9
```

TypeScript: Typisierungs-Leitfaden

Wann und Wie du typisierst

30.05.2024

React Hooks: Der useRef Hook

React Hooks vorgestellt

23.05.2024

Next.js Server Actions

Super Simple

14.04.2024

CORS

Cross-Origin Resource Sharing

22.02.2024

Ein Ritt durch Iterationen

Javascript und seine Schleifen-Typen

31.10.2023

Javascript Worker Threads

Singlethread- vs. Multithread

28.10.2023

Deploy, Mint und Transfer mit der Ord Wallet

Alles was du wissen musst

23.09.2023

Bitcoins Narrative

Warum ich glaube das Bitcoin-Zitadellen keine gute idee sind

14.07.2023

Bildung sollte keine Einbahnstraße sein

Kenne beide Seiten der Medaille

11.07.2023

Bitcoin: Eine globale Perspektive für Finanzielle Inklusion

Wie Bitcoin das leben von so vielen verbessern kann

09.07.2023

Von der Schlüsselgenerierung bis zur Verwaltung: SSH-Keys effektiv nutzen

Verwaltung von SSH-Keys mit der Shell

14.06.2023

Error: Invalid regular expression - „lookbehind assertion“

Ein ES9-Feature legte meinen Blog lahm

12.06.2023