Community Hub Framework für rpi-virtuell / edufeed
- Theoretische Einordnung
- 1. Octalysis-Grundlagen
- 2. Communikey als Infrastruktur-Grundlage
- 3. Aktivitätsnetzwerk
- 4. Übergänge und Core Drives
- 5. Implizites Fachprofil
- 6. Emergentes Vokabular
- 7. Cold-Start-Strategie
- 8. Anwendung als Strategiewerkzeug
- 9. Offene Fragen im Team
- Referenzen
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:
- Welchen Aktivitätstyp unterstützt das Feature? (Finden, Verbinden, Mitmachen, Gestalten, Einladen)
- Welche Übergänge ermöglicht oder erleichtert es? (z.B. Finden → Verbinden)
- 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:
- Transparenz: Die Person sieht, wie ihr Profil wächst und was daraus abgeleitet wird
- 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:
- Sammeln: Welche Tags werden verwendet? Welche Begriffe tauchen in Kommentaren auf? Wie beschreiben Personen ihre Materialien?
- Cluster erkennen: Ähnliche Begriffe gruppieren sich – “Konfi-Arbeit”, “Konfirmandenunterricht”, “KA” meinen dasselbe
- Kuratieren: Die Community (oder beauftragte Personen) konsolidiert Begriffe zu einem kontrollierten Vokabular
- 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:
- SDT-Meta-Check: Fördert es Autonomie (Wahlfreiheit), Kompetenz (Wirksamkeitserleben) und Verbundenheit (echte soziale Wertschätzung)?
- Welchen Aktivitätstyp unterstützt es? (Finden / Verbinden / Mitmachen / Gestalten / Einladen)
- Welche Übergänge ermöglicht es? – Für jeden Übergang Fogg-Check: Prompt vorhanden? Handlung in ≤ 2 Klicks? Motivation kontextuell gegeben?
- Welche Core Drives spricht es an? Sind das primär White-Hat-Drives?
- In welcher Cold-Start-Phase wirkt es? Ist es schon bei 3 Personen sinnvoll oder erst ab 20?
- 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:
- Onboarding-Tool (https://edufeed-org.github.io/onboarding-tool/) – muss mit dem Raummodell (Raum 2 – Ankommen) abgeglichen werden
- Kanban-Editor (https://edufeed-org.github.io/kanban-editor/cardsboard) – Board-Definitionen (Kind 30301/30302)
- Technischer Stack: Tailwind CSS + daisyUI, SvelteKit
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
- Yu-kai Chou: Octalysis Gamification Framework – https://yukaichou.com/gamification-examples/octalysis-gamification-framework/
- wb-web: Gamification als Motivator für Nachhaltigkeit – https://wb-web.de/dossiers/nachhaltigkeit/folge-1-nachhaltigkeit-als-thema-in-der-erwachsenenbildung/gamification-als-motivator-fur-nachhaltigkeit.html
- AMB-Metadatenstandards – https://dini-ag-kim.github.io/amb/latest/
- Communikey-Spezifikation – https://njump.me/naddr1qvzqqqrcvgpzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qyghwumn8ghj7mn0wd68ytnhd9hx2tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxmhwden5te0w35x2en0wfjhxapwdehhxarjxyhxxmmd9uqqumnfwqkkxmmdd46ku6ttv4usm6z7r8
- Ryan, R. M. & Deci, E. L. (2000): Self-Determination Theory and the Facilitation of Intrinsic Motivation, Social Development, and Well-Being. American Psychologist, 55(1), 68–78.
- Fogg, B. J. (2009): A Behavior Model for Persuasive Design. Persuasive ’09. https://behaviordesign.info/
- Eyal, N. (2014): Hooked: How to Build Habit-Forming Products. Portfolio/Penguin.
- edufeed Nostr-Infrastruktur – https://git.edufeed.org/edufeed/
Write a comment