Community Hub Framework für rpi-virtuell / edufeed

Ein lebendes Strategiedokument, das als Referenz für die Community-Hub-Entwicklung. Es beantwortet die Frage: *"Wie gestalten wir Feature X so, dass Community-Aktivität entsteht und wächst?"*
Community Hub Framework für rpi-virtuell / edufeed

edufeed ist ein dezentrales, Nostr-basiertes Bildungsökosystem für Open Educational Resources (OER). Die protokollbasierte Datengrundlage ist funktional und interoperabel. Was fehlt, ist der Community-Aufbau: deutschsprachige Nutzerinnen und Nutzer, Interaktion, lebendiger Austausch. Dieses Framework liefert den konzeptionellen Rahmen dafür.

Leitgedanke: Community-Aktivität und Personen stehen im Fokus. Materialien und Veranstaltungen sind Artefakte, die Menschen verbinden - nicht umgekehrt.

Theoretische Einordnung

Dieses Framework kombiniert vier Motivations- und Verhaltensmodelle in einer bewussten Hierarchie. Jede Schicht hat eine eigene Funktion:

┌─────────────────────────────────────────────┐
│  SDT – Ethisches Fundament                  │
│  "Fördert es Autonomie, Kompetenz,          │
│   Verbundenheit?"                           │
├─────────────────────────────────────────────┤
│  Octalysis – Strategische Designsprache     │
│  8 Core Drives, White/Black Hat,            │
│  Feature-Check, Cold-Start-Phasen           │
├─────────────────────────────────────────────┤
│  Aktivitätsnetzwerk – Eigenkonzept          │
│  Finden → Verbinden → Mitmachen →           │
│  Gestalten → Einladen (+ Übergänge)         │
├─────────────────────────────────────────────┤
│  Fogg B=MAP – Micro-Diagnostik              │
│  "Warum passiert der Übergang nicht?"       │
│  Prompt? Ability? Motivation?               │
├─────────────────────────────────────────────┤
│  Hook (Investment) – Perspektive            │
│  "Wie macht diese Aktivität die nächste     │
│   wertvoller?"                              │
└─────────────────────────────────────────────┘

Self-Determination Theory (SDT) bildet die Verfassungsebene: Jede Design-Entscheidung muss die drei psychologischen Grundbedürfnisse (Autonomie, Kompetenz, Verbundenheit) fördern. SDT ist das am besten empirisch validierte Motivationsmodell und besonders stark im Bildungskontext.

Octalysis liefert die strategische Designsprache mit 8 Core Drives und der White-Hat/Black-Hat-Unterscheidung. Es übersetzt die abstrakten SDT-Bedürfnisse in konkrete Gestaltungsprinzipien.

Das Aktivitätsnetzwerk (Finden, Verbinden, Mitmachen, Gestalten, Einladen) ist eine Eigenentwicklung dieses Frameworks und ersetzt das lineare Phasenmodell durch ein vollvermaschtes Netz von Aktivitätstypen.

Fogg B=MAP dient als Micro-Diagnostik für einzelne Übergänge: Wenn eine gewünschte Handlung nicht stattfindet, liegt es am fehlenden Prompt (einem sichtbaren Auslöser wie Button oder Hinweis), an mangelnder Fähigkeit (Ability – zu viele Schritte, zu viel Vorwissen nötig) oder an fehlender Motivation?

Investment (aus dem Hook Model) erklärt als Perspektive, warum Aktivität kumulativ bindet: Jede Handlung macht das eigene Fachprofil wertvoller und die nächste Interaktion wahrscheinlicher – nicht durch Lock-in, sondern durch wachsenden Wert.


1. Octalysis-Grundlagen

Das Octalysis-Framework (Yu-kai Chou) identifiziert 8 Core Drives menschlicher Motivation. Sie bilden ein Oktagon, in dem die oberen Drives als “White Hat” (intrinsisch, ermächtigend) und die unteren als “Black Hat” (extrinsisch, drängend) eingeordnet werden.

1.1 Die 8 Core Drives im edufeed-Kontext

White Hat – “Ich will das tun”

Intrinsische Motivation. Fühlt sich gut, sinnvoll und frei gewählt an. Unser Schwerpunkt.

CD1 – Epic Meaning & Calling “Wir bauen gemeinsam an offener religiöser Bildung.” Die Mission hinter OER: Bildungsmaterialien sollen frei zugänglich sein. Verstärkt durch die Dezentralität – kein Konzern kontrolliert die Plattform, die Community besitzt ihre Daten und Infrastruktur.

CD2 – Development & Accomplishment Sichtbar werden als Fachperson. Das implizite Profil wächst mit jeder Aktivität – man sieht die eigene Entwicklung. Nicht durch Punkte und Ranglisten, sondern durch wachsende Vernetzung, Sichtbarkeit und Anerkennung (Badges).

CD3 – Empowerment of Creativity & Feedback Materialien nicht nur konsumieren, sondern remixen, weiterentwickeln, in neuen Kontexten einsetzen. Das Fachvokabular für Religionspädagogik entsteht durch geführtes Taggen: Die Community schlägt Begriffe vor, das System bietet Vorschläge und Cluster an, aber ohne starres Korsett (siehe Abschnitt 6, Emergentes Vokabular). Unmittelbares Feedback: Reaktionen, Kommentare, Sichtbarkeit.

CD4 – Ownership & Possession Meine Materialien, meine Kuratierungen, mein gewachsenes Fachprofil. Durch Nostr: echtes Eigentum an den eigenen Daten – nicht plattformgebunden, portabel, unter eigener Kontrolle.

Übergangszone

CD5 – Social Influence & Relatedness Der wichtigste Drive beim Cold Start. Personen sichtbar machen, Bezüge zwischen Menschen herstellen. “Die arbeitet auch mit Konfirmanden und nutzt ähnliche Materialien wie ich.” Persönliche Einladungen, gegenseitige Anerkennung durch Community-Badges, Zugehörigkeit zu Themenfeldern.

Black Hat – “Ich kann nicht aufhören”

Extrinsische Motivation. Wirksam, aber auf Dauer erschöpfend. In einer Bildungs-Community sparsam und ethisch einsetzen.

CD6 – Scarcity & Impatience Bewusst umgedeutet: Keine Exklusivität, kein frühzeitiger Zugang – alle Features sind grundsätzlich für alle zugänglich. Statt Verknappung setzen wir auf Sichtbarkeit durch Erfahrung: Wer ein Feature regelmäßig nutzt, erhält einen Expertise-Badge (z.B. “Wiki-Kenner”, “Kalender-Profi”, “Netter Kommunikator”). Andere sehen: Diese Person kennt sich damit aus und ist ansprechbar. So entsteht keine Hierarchie, sondern ein Netzwerk von Anlaufstellen. Die “Knappheit” liegt nicht im Zugang, sondern in der Aufmerksamkeit – und die wird durch Expertise-Badges gelenkt.

CD7 – Unpredictability & Curiosity “Was hat sich seit meinem letzten Besuch getan?” Neue Materialien, neue Personen, unerwartete Verbindungen. Der Feed als Entdeckungsraum. Empfehlungen basierend auf Aktivitätsspuren anderer.

CD8 – Loss & Avoidance Bewusst umgedeutet: Keine Bestrafungsmechaniken, kein Sichtbarkeitsverlust bei Inaktivität. Stattdessen sanftes Anstupsen durch Neugier: Personalisierte Empfehlungen (“Vielleicht für dich interessant”), Netzwerk-News (“Neues aus deinen Communities”) oder Hinweise auf Aktivitäten vertrauter Personen. Das Ziel ist nicht Verlustangst, sondern der Impuls: “Da tut sich etwas, das mich betrifft.” So bleibt auch die Darstellung von Communities ehrlich – 500 Follower mit 10 aktiven Mitgliedern ist kein Problem, wenn Folgen und aktive Mitgliedschaft sichtbar unterschieden werden.

1.2 Ethischer Kompass

SDT-Fundament: Drei Grundbedürfnisse

Vor der Octalysis-Analyse steht ein Meta-Check auf Basis der Self-Determination Theory (Ryan & Deci, 2000). Die drei psychologischen Grundbedürfnisse bilden die Verfassungsebene jeder Design-Entscheidung:

  • Autonomie: Fördert das Feature echte Wahlfreiheit? Formulare (Kind 30168) für Community-Beitritt dürfen als Einladung wirken, nicht als Gatekeeper. Nostr-Dezentralität (“eigene Daten, eigene Schlüssel”) ist die technische Grundlage für Autonomie. SDT warnt: Kontrollierende Elemente untergraben intrinsische Motivation – auch wenn sie gut gemeint sind.

  • Kompetenz: Ermöglicht das Feature Wirksamkeitserleben? “Du hast 10 Materialien geliked” ist kein Kompetenzerleben. “3 Personen haben dein Material in ihrem Unterricht eingesetzt” wäre eins. Das implizite Fachprofil bedient Kompetenz elegant – Sichtbarkeit der eigenen Entwicklung ohne Prüfungsdruck.

  • Verbundenheit: Entsteht echte soziale Wertschätzung? Community-Badges, die von Personen vergeben werden, adressieren das. Automatische System-Badges nicht. Verbundenheit entsteht nicht nur durch Sichtbarkeit anderer Personen, sondern durch das Gefühl, verstanden und wertgeschätzt zu werden.

White-Hat-Priorisierung

Leitprinzip: White-Hat-Gamification dominiert. Bei jedem neuen Feature die Frage stellen: “Motiviert das durch Sinn, Wachstum und Zugehörigkeit (White Hat) – oder durch Druck, Verknappung und Verlustangst (Black Hat)?” Im Zweifelsfall White Hat wählen.

Black-Hat-Elemente sind nicht verboten, aber sie müssen:

  • transparent sein (keine versteckten Manipulationsmechaniken)
  • dem Bildungsziel dienen (nicht nur Engagement-Metriken optimieren)
  • verzichtbar sein (die Community funktioniert auch ohne sie)

2. Communikey als Infrastruktur-Grundlage

2.1 Was ist Communikey?

Communikey ist die Nostr-Spezifikation, die das edufeed-Ökosystem zusammenhält. Das Kernprinzip: Jedes bestehende npub kann eine Community werden. Es braucht keinen speziellen Server, keine Registrierung – ein Nostr-Schlüsselpaar und Standard-Relays genügen.

Zentrale Eigenschaften:

  • Communities definieren ihre eigenen Inhaltstypen (Artikel, AMB-Ressourcen, Kalender, Kanban, Chat)
  • Publikationen können mehreren Communities zugeordnet werden (Kind 30222 – Targeted Publication)
  • Zugriffskontrolle über Badges (Kind 30009/8) – clientseitig, nicht relay-seitig
  • Funktioniert auf jedem Standard-Nostr-Relay (im Gegensatz zu NIP-29)

2.2 Communikey-Kinds

Kind Name Funktion
10222 Community Definition Erstellt eine Community mit Eigenschaften, Content-Typ-Konfiguration, Relay-Einstellungen
30222 Targeted Publication Teilt beliebige Inhalte (Artikel, AMB, Kalender) gezielt mit einer Community
30382 Community Relationship Beitreten/Verlassen von Communities, Mitgliedschafts-Tracking

2.3 Relevanz für das Octalysis-Framework

Communikey macht die Aktivitätstypen des Frameworks technisch möglich:

  • Finden: Inhalte sind über Communities thematisch geordnet und entdeckbar
  • Verbinden: Community-Mitgliedschaft (Kind 30382) schafft Zugehörigkeit
  • Mitmachen: Chat (Kind 9) ist Kern-Feature jeder Community
  • Gestalten: Targeted Publications (Kind 30222) ermöglichen, Inhalte gezielt einzubringen
  • Einladen: Jede Person kann eine Community eröffnen (Kind 10222) und über Badges Rollen vergeben

2.4 Vollständige Event-Kind-Referenz

Alle in edufeed-app genutzten Nostr Event Kinds, gruppiert nach Funktion:

Protokoll-Basis:

Kind Name Zweck
0 User Metadata Profile (Name, About, Picture)
1 Short Text Note Kurznotizen/Posts
3 Contacts Follow-Listen
5 Event Deletion Löschanfragen (NIP-09)
7 Reaction Likes, Emoji-Reaktionen (NIP-25)

Community & Chat:

Kind Name Zweck
9 Chat Message Echtzeit-Chat in Communities
11 Forum Post Thread-basierte Diskussionen in Communities
10222 Community Definition Communikey – Community erstellen/bearbeiten
30222 Targeted Publication Communikey – Inhalte mit Community teilen
30382 Community Relationship Communikey – Community beitreten/verlassen

Formulare & Zugriffskontrolle:

Kind Name Zweck
30168 Form Template Formular-Definitionen (Beitrittsanträge, Umfragen)
1069 Form Response Ausgefüllte Formulare (Mitgliedschaftsanträge)
1070 Form Request P2P-Formular-Einladung an einzelne Nutzer
30000 Follow Set / Profile List Kuratierte Autoren-Sets, ACL-Mitgliederlisten

Badges:

Kind Name Zweck
30009 Badge Definition Badge erstellen (NIP-58)
8 Badge Award Badge an Person vergeben

Relay- & Server-Listen:

Kind Name Zweck
10002 Relay List Metadata Persönliche Relay-Liste (NIP-65)
10063 Blossom Server List Medienserver-Präferenzen (NIP-B7)
30002 Relay Set App-spezifische Relay-Overrides (NIP-51)

Custom Emoji (NIP-30):

Kind Name Zweck
10030 Emoji List Custom-Emoji-Liste eines Users
30030 Emoji Pack Gemeinsam nutzbare Emoji-Packs

Inbox & Notifications:

Kind Name Zweck
30078 App-specific Data NIP-78 – Read-State für Inbox (last-seen Timestamp)

Inhalte & Kuratierung:

Kind Name Zweck
30023 Long-form Article Langform-Artikel (NIP-23)
30040 Publication Bücher, Kurse, Zeitschriften (geplant)
30142 AMB Educational Resource OER-Bildungsressourcen nach AMB-Standard
30818 Wiki Article NIP-54 Wiki-Artikel (Djot/AsciiDoc), kollaboratives Wissen

Social Bookmarks:

Kind Name Zweck
39701 Social Bookmark Geteilte Lesezeichen mit Metadaten

Kalender (NIP-52):

Kind Name Zweck
31922 Date-based Calendar Event Ganztags-/Mehrtages-Termine
31923 Time-based Calendar Event Termine mit Uhrzeit und Zeitzone
31924 Calendar Kalender-Collections
31925 Calendar Event RSVP Zu-/Absagen für Termine

Kanban:

Kind Name Zweck
30301 Kanban Board Board-Definitionen
30302 Kanban Card Einzelne Karten auf Boards

2.5 Features im Entwicklungsstadium (dev-Branch)

Die folgenden Features befinden sich in aktiver Entwicklung und erweitern das Aktivitätsnetzwerk erheblich:

Wave/Poke – niedrigschwelligste soziale Geste: Ein 👋-Wave ist eine Kind-7-Reaktion auf das Profil-Event (Kind 0) einer Person – kein Kommentar, kein Like, sondern ein asynchrones “Hallo, ich sehe dich”. Mit 24h-Cooldown, Toast-Notification und Inbox-Integration. Perfekt für den Cold Start: die einfachste Form der Interaktion zwischen zwei Personen.

  • Octalysis: CD5 (Social Influence) + CD2 (Accomplishment, erste sichtbare Handlung)

Formulare & gesteuertes Onboarding: Communities können über Formular-Templates (Kind 30168) eigene Beitrittsanträge definieren. Mitglieder werden über Profile-Listen (Kind 30000) verwaltet, und Zugriff auf Content-Types kann pro Bereich gesteuert werden (ACL). Das ermöglicht abgestuftes Engagement: erst lesen, dann chatten, dann publizieren.

  • Octalysis: CD2 (Accomplishment, aufsteigende Berechtigungen) + CD4 (Ownership, Zugehörigkeit verdienen)

Wiki – kollaboratives Wissensmanagement: NIP-54 Wiki-Artikel (Kind 30818) mit Djot/AsciiDoc, Wikilinks zwischen Artikeln und Highlight-Overlay für Kommentare auf Textpassagen. Ermöglicht gemeinsame Wissensbasis innerhalb einer Community.

  • Octalysis: CD3 (Creativity) + CD1 (Epic Meaning, gemeinsames Wissen aufbauen)

Forum (Kind 11) – strukturierte Diskussion: Thread-basierte Diskussionen, abgegrenzt von Chat (Kind 9). Kommentar-Zählung, verschachtelte Antworten. Ermöglicht tieferen fachlichen Austausch.

  • Octalysis: CD3 (Creativity) + CD5 (Social Influence)

Dashboard & Inbox: Aggregierter Feed aller gejointen Communities, Upcoming-Events-Widget, und eine Unified Inbox für alle Notification-Typen (Waves, Formular-Anfragen, Reaktionen, Kommentare, RSVPs). Read-State über NIP-78.

  • Octalysis: CD7 (Curiosity, “Was hat sich getan?”) + CD5 (Social Influence, Benachrichtigungen über soziale Interaktion)

HoverCards, Facepile & Badges auf Profil: Profile werden an jedem Content-Item als Popup sichtbar (Name, Bio, Badges, Wave-Button). Community-Mitglieder erscheinen als Facepile mit überlappenden Avataren. Badge-Awards werden auf der Profilseite angezeigt.

  • Octalysis: CD5 (Social Influence, Personen sichtbar machen) + CD2 (Accomplishment, Badges als Anerkennung)

Custom Emoji (NIP-30): Persönliche Emoji-Listen und gemeinsame Emoji-Packs für Chat und Reaktionen. Communities können eigene Emoji-Sets pflegen.

  • Octalysis: CD3 (Creativity) + CD4 (Ownership, “unsere” Emojis)

3. Aktivitätsnetzwerk

3.1 Grundmodell: Netzwerk statt Trichter

Klassische Gamification-Modelle arbeiten mit linearen Journeys: Discovery → Onboarding → Scaffolding → Endgame. Für edufeed ist das unzureichend, weil:

  • Personen in verschiedenen Bereichen gleichzeitig unterschiedlich erfahren sind
  • Das “Endgame” nicht das Ende ist, sondern der Beginn eines neuen Zyklus
  • Jede Aktivität Einstiegspunkt sein kann – jemand findet edufeed über eine Veranstaltung, eine andere über ein Material, eine dritte über eine Person

Statt eines Trichters verwenden wir ein Aktivitätsnetzwerk mit fünf Typen, die sich frei miteinander verknüpfen. Alles ist mit allem verbunden

3.2 Die 5 Aktivitätstypen

Typ Was passiert Nostr-Artefakte
Finden Material, Veranstaltung oder Person entdecken Kind 30142 (AMB), Kind 31922/31923 (Kalender), Kind 0 (Profile), Kind 30023 (Artikel), Kind 30818 (Wiki), Kind 30301 (Kanban), Kind 39701 (Bookmarks), Dashboard-Feed
Verbinden Kontakt herstellen, folgen, Community beitreten, winken Kind 3 (Follow-Liste), Kind 7 als Wave (👋 auf Profil), Kind 30382 (Community-Mitgliedschaft), Kind 1069 (Beitrittsantrag via Formular), Kind 30000 (Mitgliederlisten)
Mitmachen Reagieren, kommentieren, teilnehmen, diskutieren Kind 1 (Kommentar), Kind 7 (Reaktion mit Custom Emoji), Kind 9 (Chat), Kind 11 (Forum-Thread), Kind 31925 (RSVP), Kind 1069 (Formular ausfüllen)
Gestalten Erstellen, weiterentwickeln, kuratieren, Wissen aufbauen Kind 30023 (Artikel), Kind 30142 (AMB), Kind 30818 (Wiki), Kind 30222 (Targeted Publication), Kind 31922/31923 (Kalender-Events), Kind 30301/30302 (Kanban)
Einladen Austausch moderieren, Community eröffnen, Zugang gewähren, Formulare versenden Kind 10222 (Community-Definition), Kind 31923 (Kalender-Event), Kind 30009/8 (Badge), Kind 30168 (Formular-Template), Kind 1070 (Formular-Einladung), Kind 30000 (Mitglied freischalten)

Die Typen bilden ein vollvermaschtes Netzwerk - jeder kann zu jedem anderen führen. In der Praxis gibt es häufigere und seltenere Übergänge, aber keine vorgeschriebene Reihenfolge.

3.3 Beispiel-Zyklus

Eine konkrete Geschichte, die das Netzwerk durchläuft:

Eine Person findet eine Veranstaltung, auf der ein Lernmaterial präsentiert wird. Darüber verbindet sie sich mit der Person, die es erstellt hat. Gemeinsam gestalten sie eine Weiterentwicklung und laden ein zu moderiertem Austausch darüber. Der Austausch regt andere an, das Material auszuprobieren (mitmachen), sich zu ihren Lehrerfahrungen auszutauschen, was wiederum zu Veranstaltungen führt (einladen), wo über die Qualität von Religionsunterricht diskutiert wird – und der Zyklus beginnt von vorn.

Jeder Knotenpunkt in dieser Geschichte kann Einstiegspunkt für eine neue Person sein.


4. Übergänge und Core Drives

Die eigentliche Kraft des Frameworks liegt in den Übergängen: Was motiviert eine Person, von einem Aktivitätstyp zum nächsten zu wechseln?

4.1 Übergangsmatrix (häufigste Übergänge)

Die folgenden Übergänge sind die in der Praxis häufigsten und wichtigsten. Das Netzwerk ist vollvermascht – weitere Übergänge sind möglich und können bei Bedarf ergänzt werden.

Jeder Übergang wird auf drei Ebenen beschrieben: die motivierenden Core Drives (Octalysis), die konkrete Mechanik und ein Fogg-Check (B=MAP), der diagnostiziert, warum ein Übergang scheitern kann. Die drei Fogg-Faktoren: Prompt (ein sichtbarer Auslöser, der zur Handlung einlädt – z.B. ein Button, ein Hinweis, eine Benachrichtigung), Ability (wie einfach die Handlung auszuführen ist – Klicks, Schritte, Vorwissen) und Motivation (ob der Kontext einen ausreichenden Handlungsimpuls liefert).

Finden → Verbinden “Das Material ist spannend – wer steckt dahinter?”

  • CD7 (Curiosity): Wer ist diese Person? Was hat sie noch gemacht?
  • CD5 (Social Influence): Sichtbares Profil mit Aktivitätsspuren macht die Person greifbar
  • Mechanik: Beim Material wird die Autorin mit ihrem impliziten Fachprofil angezeigt – nicht nur ein Name, sondern Themenfelder, Aktivität, Vernetzung
  • Fogg-Check: Prompt – Ist das Profil der Autorin am Material sichtbar, mit klickbarem Link? Ability – Ist Folgen in ≤ 2 Klicks möglich? Motivation – Zeigt das Profil genug Substanz, um Neugier auszulösen?

Finden → Mitmachen “Das will ich ausprobieren / dazu habe ich eine Erfahrung”

  • CD2 (Accomplishment): Niedrigschwellige erste Aktion – ein Like, ein Bookmark
  • CD3 (Creativity): Eigene Erfahrung teilen, Material in eigenem Kontext einordnen
  • Mechanik: Einfache Reaktionsmöglichkeiten direkt am Material, Einladung zum Erfahrungsbericht
  • Fogg-Check: Prompt – Sind Reaktionsbuttons (Like, Emoji, Bookmark) direkt am Material sichtbar? Ability – Geht die erste Reaktion ohne Anmeldung/Bestätigung? Motivation – Gibt der Kontext (z.B. “5 andere haben reagiert”) einen sozialen Impuls?

Verbinden → Gestalten “Wir könnten das zusammen weiterentwickeln”

  • CD1 (Epic Meaning): Gemeinsam etwas Größeres schaffen als allein möglich
  • CD4 (Ownership): Geteilte Autorenschaft, gemeinsames Werk
  • Mechanik: Materialien können Fork/Remix-Beziehungen haben, Co-Autorenschaft wird sichtbar
  • Fogg-Check: Prompt – Gibt es am Material einen “Remix”- oder “Weiterentwickeln”-Button? Ability – Ist der Weg von “ich kenne die Person” zu “wir arbeiten zusammen an einem Material” klar und kurz? Motivation – Wird sichtbar, dass Remix/Co-Autorenschaft wertgeschätzt wird (z.B. durch Badges)?

Mitmachen → Einladen “Andere sollten das auch erfahren / darüber diskutieren wir mal”

  • CD5 (Social Influence): Ich kenne Leute, die das interessiert
  • CD1 (Epic Meaning): Austausch organisieren als Dienst an der Community
  • Mechanik: Aus einem Kommentar-Thread eine Veranstaltung machen, aus einer Diskussion ein moderiertes Format
  • Fogg-Check: Prompt – Gibt es in Diskussionen einen Hinweis “Daraus eine Veranstaltung machen”? Ability – Kann aus einem Thread mit wenigen Klicks ein Kalender-Event entstehen? Motivation – Sieht die Person, dass andere an einer Vertiefung interessiert sind?

Einladen → Finden Der Kreislauf schließt sich: Veranstaltungen bringen neue Materialien und Personen ins Netzwerk

  • CD7 (Curiosity): Was bringen die Teilnehmenden mit?
  • CD2 (Accomplishment): Sichtbarer Impact – “aus meiner Veranstaltung sind 3 neue Materialien entstanden”
  • Fogg-Check: Prompt – Werden Veranstaltungen im Feed und Dashboard prominent angezeigt? Ability – Ist die Teilnahme (RSVP) in ≤ 2 Klicks möglich? Motivation – Zeigt die Veranstaltung, wer noch teilnimmt (Facepile)?

Gestalten → Einladen “Ich habe etwas erstellt – wer will es ausprobieren?”

  • CD5 (Social Influence): Feedback und Anerkennung suchen
  • CD3 (Creativity): Sehen, was andere aus dem eigenen Material machen
  • Fogg-Check: Prompt – Wird nach dem Publizieren vorgeschlagen, das Material in einer Community zu teilen? Ability – Ist Targeted Publication (Kind 30222) ein integrierter Schritt im Publish-Flow? Motivation – Sieht die Person, in welchen Communities Interesse am Thema besteht?

4.2 Anwendung als Designwerkzeug

Wenn ein neues Feature für einen edufeed-Client geplant wird, stellt dieses Modell drei Fragen:

  1. Welchen Aktivitätstyp unterstützt das Feature? (Finden, Verbinden, Mitmachen, Gestalten, Einladen)
  2. Welche Übergänge ermöglicht oder erleichtert es? (z.B. Finden → Verbinden)
  3. Welche Core Drives spricht es an? (und sind das primär White-Hat-Drives?)

5. Implizites Fachprofil

5.1 Grundidee

Statt Formulare auszufüllen, entsteht das fachliche Profil einer Person durch ihre Aktivität. Jede Interaktion mit einem Material, das AMB-Metadaten trägt, verrät etwas über die Person. Die AMB-Tags (Schulart, Zielgruppe, Fachgebiet) “färben” auf die interagierende Person ab.

Warum implizit statt explizit:

  • Niedrigere Einstiegshürde – kein Formular steht zwischen Ankommen und Mitmachen
  • Authentischer – das Profil zeigt, was jemand tatsächlich tut, nicht was sie in ein Formular schreibt
  • Dynamisch – das Profil entwickelt sich mit der Person weiter
  • Octalysis-konform – CD3 (Creativity): Das Profil entsteht als kreatives Nebenprodukt, nicht als Pflichtaufgabe

5.2 Datenspuren

Aktivität Profilwirkung Nostr-Event
Material liken / Emoji-Reaktion Interesse am Themenfeld Kind 7 (Reaktion)
Kommentar schreiben Expertise/Perspektive im Themenfeld Kind 1
Forum-Diskussion starten Fachliches Engagement, Diskursbereitschaft Kind 11
Im Chat beitragen Zugehörigkeit, informeller Austausch Kind 9
Material publizieren Fachgebiete und Zielgruppen (über AMB-Tags) Kind 30023 + Kind 30142
Wiki-Artikel bearbeiten Expertise, Wissensaufbau Kind 30818
RSVP zu Veranstaltung Interesse am Veranstaltungsthema, Teilnahme Kind 31925
Person folgen Fachliche Nähe/Netzwerk Kind 3
Jemandem winken (Wave) Soziale Initiative, Vernetzungsbereitschaft Kind 7 (auf Kind 0)
Community beitreten Thematische Zuordnung Kind 30382
Beitrittsformular ausfüllen Selbstbeschreibung, Motivation Kind 1069
Social Bookmark teilen Kuratierung, Interessenfeld Kind 39701
Material in Liste aufnehmen Kuratierungskompetenz Kind 30004

5.3 Darstellung

Das Profil wird nicht als Score oder Rangliste angezeigt, sondern als lebendiges Aktivitätsportrait:

  • Grafische Darstellung der Aktivitätsfelder – in welchen Themen aktiv, wie stark, Überschneidungen mit anderen Personen
  • Aktivitäts-Timeline oder Heatmap – wann zuletzt aktiv, wie regelmäßig
  • Thematische Schwerpunkte – abgeleitet aus den AMB-Tags der Materialien, mit denen interagiert wurde
  • Vernetzung – mit wem verbunden, in welchen Themenfeldern

5.4 Badges (über Badger)

Ergänzend zum impliziten Profil können Badges explizite Anerkennung sichtbar machen:

System-Badges (automatisch vergeben):

  • Meilensteine: “Erste Veröffentlichung”, “10 Kommentare”, “Vernetzt in 3 Themenfeldern”
  • Pionier-Badges: “Early Contributor” – ehrliche Anerkennung der Ersten, nicht als Exklusivitätsmerkmal, sondern als sichtbare Geschichte der Community
  • Aktivität: “Aktiv seit 6 Monaten”, “Regelmäßig beitragend”

Community-Badges (von Personen vergeben):

  • “Hilfreiche Rückmeldung”, “Inspirierende Veranstaltung”, “Wertvoller Beitrag”
  • Stärkt CD5 (Social Influence) und CD2 (Accomplishment)
  • Authentischer als System-Badges, weil sie menschliche Wertschätzung transportieren

Technisch: Nostr Kind 30009 (Badge Definition) und Kind 8 (Badge Award) – existierende NIPs.

5.5 Investment-Perspektive: Kumulative Bindung durch Aktivität

Jede Aktivität im Netzwerk ist zugleich eine Investment – sie macht das eigene Fachprofil wertvoller und die nächste Interaktion wahrscheinlicher. Wer publiziert, taggt, kommentiert und kuratiert, baut ein reichhaltiges Aktivitätsportrait auf, das mit jeder Handlung an Aussagekraft gewinnt.

Das ist kein Black-Hat-Mechanismus, solange zwei Bedingungen erfüllt sind:

  1. Transparenz: Die Person sieht, wie ihr Profil wächst und was daraus abgeleitet wird
  2. Portabilität: Die Person kann jederzeit ihre Daten mitnehmen – Nostr-Schlüssel und Events gehören ihr, nicht der Plattform

Unter diesen Bedingungen ist Investment ein White-Hat-Mechanismus: “Dein Profil wächst mit dir” statt “Du verlierst alles, wenn du gehst.” Die Bindung entsteht durch wachsenden Wert, nicht durch Wechselkosten.

Design-Implikation: Bei jedem Feature fragen: “Welche Investment tätigt die Person bei dieser Aktivität, und wie macht sie die nächste Interaktion wertvoller?” Ein Like ist eine minimale Investment (Interesse signalisieren). Ein publiziertes Material ist eine starke Investment (Fachprofil wird sichtbar). Ein Wiki-Beitrag ist eine geteilte Investment (persönliches Wissen wird Gemeinschaftswissen).


6. Emergentes Vokabular

6.1 Ausgangslage

Für die Religionspädagogik fehlt noch ein kontrolliertes Vokabular. Die AMB-Metadatenstandards existieren, aber die fachspezifischen Begriffe (Schularten, didaktische Ansätze, Zielgruppen) sind noch nicht systematisiert.

6.2 Bottom-up statt Top-down

Statt das Vokabular vorab zu definieren, entsteht es aus der Community-Aktivität:

  1. Sammeln: Welche Tags werden verwendet? Welche Begriffe tauchen in Kommentaren auf? Wie beschreiben Personen ihre Materialien?
  2. Cluster erkennen: Ähnliche Begriffe gruppieren sich – “Konfi-Arbeit”, “Konfirmandenunterricht”, “KA” meinen dasselbe
  3. Kuratieren: Die Community (oder beauftragte Personen) konsolidiert Begriffe zu einem kontrollierten Vokabular
  4. Rückkoppeln: Das Vokabular wird als Vorschlag beim Taggen angeboten – nicht als Zwang, sondern als Hilfe

Dieser Prozess ist selbst ein Aktivitätsfeld, das mehrere Core Drives anspricht:

  • CD3 (Creativity): Begriffe finden und formen
  • CD4 (Ownership): “Unser Vokabular” als gemeinsames Werk
  • CD1 (Epic Meaning): Standards schaffen, die der ganzen Fachcommunity dienen

7. Cold-Start-Strategie

7.1 Das Problem

Mit unter 5 aktiven Personen greifen die meisten Community-Mechaniken nicht. Ein Feed wirkt leer, Badges fühlen sich sinnlos an, “Vernetzt mit 0 Personen” motiviert niemanden.

7.2 Phasen

Phase 0: Bühne vorbereiten (vor dem ersten Nutzer)

Bestehendes sichtbar machen:

  • Vorhandene Materialien aus der Pipeline (FOERBICO, rpi-virtuell) sind bereits auf den Relays. Im Client so darstellen, dass der Raum belebt wirkt
  • Personen hinter den Materialien erkennbar machen – auch ohne aktive Interaktion haben sie durch Publikationen ein implizites Fachprofil

Grundrauschen erzeugen:

  • Institutionelle Accounts (Comenius-Institut, rpi-virtuell, relilab) publizieren regelmäßig
  • Bridge-Bots tragen Aktivitäten aus anderen Netzwerken (Mastodon, RSS, WordPress) ein – als solche erkennbar, transparent
  • Core Drive: CD1 (Epic Meaning) – “Hier entsteht etwas, und es gibt schon Substanz”

Phase 1: Keimzelle (3-5 Aktive)

Persönliche Einladung mit konkretem Anlass:

  • Nicht “komm auf unsere Plattform”, sondern: “Wir bereiten die nächste relilab-Veranstaltung vor – dein Material taucht hier schon auf, magst du dein Profil ergänzen?”
  • Core Drive: CD5 (Social Influence) – persönliche Einladung durch jemanden, den man kennt

Sofortige Sichtbarkeit:

  • Jede Aktivität wird sichtbar – bei 3-5 Personen ist nichts irrelevant
  • Pionier-Badges: “Early Contributor” – ehrliche Anerkennung der Ersten
  • Core Drive: CD2 (Accomplishment) + CD6 (Scarcity)

Akteure:

  • Der Initiator selbst als aktiver Modellierer – zeigt durch eigenes Verhalten, was man tun kann
  • Institutionelle Accounts für Regelmäßigkeit
  • Bots für Inhaltsfluss aus bestehenden Netzwerken

Phase 2: Erste Netzwerkeffekte (5-20 Aktive)

Übergänge aktiv anregen:

  • “Du hast 5 Materialien zu Konfirmandenarbeit geliked – kennst du schon [Person], die dazu publiziert?” → Finden → Verbinden
  • Nach RSVP: “3 andere Teilnehmende haben ähnliche Interessen” → Verbinden
  • Core Drive: CD7 (Curiosity)

Community-Badges werden sinnvoll:

  • Gegenseitige Auszeichnung ab 5+ Personen
  • Erste thematische Cluster werden sichtbar

Vokabular-Emergenz beginnt:

  • Erste Muster in Tags und Begriffen erkennbar
  • Noch kein formales Vokabular, aber kuratierbare Tendenzen

Phase 3: Selbsttragendes Wachstum (20+ Aktive)

  • Neue Personen finden eine belebte Community vor
  • Implizite Fachprofile sind aussagekräftig
  • Vokabular kann formalisiert werden
  • Community-Badges haben soziale Bedeutung
  • Veranstaltungen entstehen aus der Community heraus

Der Übergang von Phase 2 zu 3 ist der kritischste Punkt – hier entscheidet sich, ob die Community selbsttragend wird.


8. Anwendung als Strategiewerkzeug

8.1 Feature-Check

Bei jedem neuen Feature für einen edufeed-Client diese Fragen stellen:

  1. SDT-Meta-Check: Fördert es Autonomie (Wahlfreiheit), Kompetenz (Wirksamkeitserleben) und Verbundenheit (echte soziale Wertschätzung)?
  2. Welchen Aktivitätstyp unterstützt es? (Finden / Verbinden / Mitmachen / Gestalten / Einladen)
  3. Welche Übergänge ermöglicht es? – Für jeden Übergang Fogg-Check: Prompt vorhanden? Handlung in ≤ 2 Klicks? Motivation kontextuell gegeben?
  4. Welche Core Drives spricht es an? Sind das primär White-Hat-Drives?
  5. In welcher Cold-Start-Phase wirkt es? Ist es schon bei 3 Personen sinnvoll oder erst ab 20?
  6. Trägt es zum impliziten Fachprofil bei? Hinterlässt die Nutzung eine auswertbare Datenspur? Und: Macht die Investment die nächste Interaktion wertvoller?

8.2 Geltungsbereich

Dieses Framework gilt clientübergreifend und plattformunabhängig. Es ist relevant für:

  • edufeed-app (SvelteKit-Client)
  • grimoire (Nostr-Explorer)
  • Jeden zukünftigen Client, der auf edufeed-Relays zugreift
  • Infrastruktur-Entscheidungen (Relay-Konfiguration, Event-Kinds)
  • Externe Clients (Habla, Yakihonne) – soweit deren Features genutzt werden

8.3 Weiterentwicklung

Dieses Dokument ist ein lebendes Strategiedokument. Es wird weiterentwickelt, wenn:

  • Neue Erkenntnisse aus der Community-Praxis vorliegen
  • Neue Aktivitätstypen oder Übergänge identifiziert werden
  • Die Cold-Start-Phasen durchlaufen werden und Erfahrungen einfließen
  • Technische Möglichkeiten sich ändern (neue NIPs, neue Clients)

9. Offene Fragen im Team

Die folgenden Punkte sind im Team aufgekommen, zu diskutieren und können nicht allein aus dem Framework heraus beantwortet werden.

9.1 Governance und demokratische Gestaltung

Wie gestalten wir das Miteinander im Hub demokratisch? Konkret:

  • Autonomie vs. Leitplanken: Können Communities ihre Zusammenarbeit völlig frei gestalten, oder brauchen sie gemeinsame Regeln (Policies, Netiquette)? Wenn ja – wer legt sie fest und wer koordiniert?
  • Teilhabe und Bildungsgerechtigkeit: Wie stellen wir sicher, dass auch marginalisierte Gruppen einbezogen werden? Welche Barrieren (technisch, sprachlich, kulturell) müssen wir aktiv abbauen?
  • Moderation: Braucht es Community-übergreifende Moderationsstrukturen oder reicht Community-interne Selbstverwaltung?

9.2 Mitgliedschaft vs. Followerschaft

Ginas Vorschlag: Folgen und aktive Mitgliedschaft als zwei getrennte Beziehungstypen, sichtbar im Profil. Folgen zeigt Interesse, Mitgliedschaft bedeutet aktive Beteiligung und erweiterte Möglichkeiten. Mitgliedschaft schließt Followerschaft ein. Das betrifft:

  • Wie Community-Größe dargestellt wird (nicht verfälscht durch passive Follower)
  • Welche Beteiligungsrechte an Mitgliedschaft vs. Followerschaft geknüpft sind
  • Technische Umsetzung: Community Relationship (Kind 30382) müsste zwischen Folgen und Mitgliedschaft unterscheiden

9.3 Rollen, Raummodell und bestehende Bausteine

Stand der Arbeit

Greg hat vier Kern-Personas entwickelt (Consumer, Creator, Community-Manager, Operator) mit konkreten User Journeys. Jörg hat diese um fünf weitere Rollen ergänzt (Curator, Reviewer, Moderator, Maintainer, Metadata Steward, Facilitator), die stärker auf Community-Pflege und Qualitätssicherung ausgerichtet sind.

Gregs Whimsical-Diagramm (https://whimsical.com/gep43/ux-ui-community-hub-Xw7ScFQa8D2a7zfSBwUyu1) verwendet eine Raummetapher mit Zonen:

  • Raum 1 – Entdecken (nicht eingeloggt): Material finden, Kalender, öffentliche Inhalte
  • Raum 2 – Ankommen (Anmeldung/Onboarding): Login, Profil einrichten
  • Eingeloggt: “Mein Edufeed” (persönlicher Bereich), Communities, Erstellen-Button auf allen Seiten

Der “Erstellen-Button” soll auf allen Seiten verfügbar sein (nicht nur in Communities versteckt). Content-Typen sollen global erstellbar sein.

Mapping Personas → Aktivitätstypen

Noch zu klären: Wie ordnen sich die 4+5 Rollen den 5 Aktivitätstypen zu? Erster Entwurf:

Rolle Primäre Aktivitätstypen Offene Fragen
Consumer Finden, Mitmachen Übergang zu Verbinden aktiv fördern?
Creator Gestalten, Einladen “Mein Edufeed” als Vorstufe zu Community?
Community-Manager Einladen, Verbinden Wie entsteht eine Community aus einem Profil?
Operator (Infrastruktur) Kein direkter Aktivitätstyp – Enabler
Curator Finden, Gestalten Thematische Sammlungen als eigener Content-Typ?
Reviewer Mitmachen Qualitätslabels als Badge-System?
Moderator Verbinden, Mitmachen Community-übergreifend oder nur intern? (→ 9.1)
Maintainer Gestalten Pflege als sichtbare Aktivität im Profil?
Metadata Steward Gestalten Verbindung zum emergenten Vokabular (Abschnitt 6)
Facilitator Einladen, Mitmachen OEP-Prozessbegleitung als Feature?

Bestehende Bausteine

Aus den Sprint-Teams sind bereits Prototypen entstanden:

Offene Punkte für das nächste Treffen mit Greg

  • Raummetapher und Aktivitätsnetzwerk zusammenführen: Sind die “Räume” Phasen oder parallele Perspektiven?
  • “Mein Edufeed” als persönlicher Hub: Wie wird aus einem Profil mit Followern eine Community? (Greg: “let’s become edufeed-influencer”)
  • Mitgliedschaft vs. Followerschaft in der UI sichtbar machen (→ 9.2)
  • Gregs Whimsical in maschinenlesbare Form überführen
  • Kontakt zu Moritz (religionen-entdecken.de / reli-lehrerzimmer.de) als potenzieller Community-Partner

9.4 Technische Umsetzung des geführten Taggens

Das emergente Vokabular (Abschnitt 6) beschreibt den konzeptionellen Ansatz. Die technische Umsetzung – wie werden Vorschläge generiert, wie entsteht aus Community-Tags ein kuratiertes Vokabular – ist noch offen.

Ideen, Steffen?


Referenzen


Write a comment
No comments yet.