Client link: https://create-a-docswiki-page-using-snmx.shakespeare.to/
Read the NIP here: https://flexible-documentation-engine-bdxh.shakespeare.to/ - or on nostrhub.io at address nostr:naddr1qvzqqqrcvypzp2x32cxk5era2qtfj9njgmer0vm0ky3l3ytglks3m36r2vl7c7sgqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqqz3jx7cm4d4jkuarpw35k7m3dwdcxzcm9wvsnsfr5

I also did a new raw events client that even has filter options: https://nostrstream-jx5l.shakespeare.to/

And MKStack is good at non-Nostr things as well: https://blocktime-converter-ic28.shakespeare.to/

Now, I created the first application using my NIP. Thanks to Stacks and MKStack I was able to create an app using a custom NIP by only refering to its naddr. You can also read it here: https://habla.news/de/u/stl1988@stl1988.github.io/1747672991372

The NIP is hosted at https://nostrhub.com/naddr1qvzqqqrcvypzp2x32cxk5era2qtfj9njgmer0vm0ky3l3ytglks3m36r2vl7c7sgqqaxgmmrw4kk2mn5v96xjmmw94skuepdwa5kk6tn94mkjarg94ehqctrv4ej6ctwvskkvmmjd4shgttyv43kcctjv96xjmmwaw8rqc. The naddr is where MKStack gets the NIP from.

Link to the client: https://npub17vcw3v5wsakcd7d4enlzgdn46z5z8g57qgm56h857gfknjxukpns88ghvz.nostrdeploy.com

Please note that this still has some flaws.

I also made a raw event client: https://npub1z9u2zl0dtte4s4n5afayv68dn2wkxg37cqmr3x5n4eeueq6v40lq77ewrn.nostrdeploy.com

This client shows every event, regardless of its kind, and shows all event data. You can also create your own raw events here. This can be useful for debugging purposes of if you just want to know how Nostr works.

Documentation and Wikis with Spaces and Format Declaration

draft optional

Summary

This NIP introduces a system for collaborative documentation and wikis on Nostr. It improves upon earlier efforts by adding namespace-like Spaces, explicit content format declaration, and clearer separation of article types, including redirects and merge requests.

Motivation

Previous approaches to wiki-style collaborative content on Nostr had two key limitations:

1. Format instability – No declared format per event led to breaking changes (e.g. a shift from Markdown to Asciidoc).
2. Lack of namespace separation – All articles existed in a global space, causing confusion and collision between unrelated projects.

This NIP addresses both by introducing:

• Spaces – individually defined wikis or documentation sets.
• Explicit per-article format declaration.
• Dedicated event kinds for articles, redirects, merge requests, and space metadata.

Specification

kind: 31055 – Space Definition

Defines a project namespace for articles.

Tags:

• ["name", "<space title>"]
• ["slug", "<short identifier>"]
• ["description", "<optional description>"]
• ["language", "<ISO language code>"]
• ["license", "<license text or SPDX ID>"]

Content: (optional) full description or README for the space.

kind: 31056 – Article

An article in a specific format belonging to a defined space.

Tags:

• ["space", "<slug>"]
• ["title", "<article title>"]
• ["format", "markdown" | "asciidoc" | "wikitext" | "html"]
• ["format-version", "<format version>"] (optional)
• ["prev", "<event-id>"] (optional)
• ["summary", "<short change summary>"] (optional)

Content: full body of the article in the declared format.

kind: 31057 – Redirect

Redirects from one article title to another within the same space.

Tags:

• ["space", "<slug>"]
• ["from", "<old title>"]
• ["to", "<new title>"]

Content: empty.

kind: 31058 – Merge Request

Proposes a revision to an article without directly altering the original.

Tags:

• ["space", "<slug>"]
• ["title", "<article title>"]
• ["base", "<event-id>"]
• ["format", "<format>"]
• ["comment", "<short summary>"] (optional)

Content: proposed article content.

Format Guidelines

Currently allowed formats:

• markdown
• asciidoc
• wikitext
• html

Clients MUST ignore formats they do not support. Clients MAY apply stricter formatting rules.

Client Behavior

Clients:

• MUST render only supported formats.
• MUST treat space as a case-sensitive namespace.
• SHOULD allow filtering, browsing and searching within Spaces.
• SHOULD support revision tracking via prev.
• MAY support diff/merge tooling for kind: 31058.

Examples

Space Definition

{
  "kind": 31055,
  "tags": [
    ["name", "Bitcoin Docs"],
    ["slug", "btc-docs"],
    ["description", "Developer documentation for Bitcoin tools"],
    ["language", "en"],
    ["license", "MIT"]
  ],
  "content": "Welcome to the Bitcoin Docs Space."
}

Markdown Article

{
  "kind": 31056,
  "tags": [
    ["space", "btc-docs"],
    ["title", "Installation Guide"],
    ["format", "markdown"]
  ],
  "content": "# Installation\n\nFollow these steps to install the software..."
}

Asciidoc Article

{
  "kind": 31056,
  "tags": [
    ["space", "btc-docs"],
    ["title", "RPC Reference"],
    ["format", "asciidoc"]
  ],
  "content": "= RPC Reference\n\nThis section describes JSON-RPC calls."
}

Wikitext Article

{
  "kind": 31056,
  "tags": [
    ["space", "btc-docs"],
    ["title", "Block Structure"],
    ["format", "wikitext"]
  ],
  "content": "== Block Structure ==\n\nThe structure of a Bitcoin block is..."
}

Redirect

{
  "kind": 31057,
  "tags": [
    ["space", "btc-docs"],
    ["from", "Getting Started"],
    ["to", "Installation Guide"]
  ],
  "content": ""
}

Merge Request

{
  "kind": 31058,
  "tags": [
    ["space", "btc-docs"],
    ["title", "Installation Guide"],
    ["base", "d72fa1..."],
    ["format", "markdown"],
    ["comment", "Added step for testnet"]
  ],
  "content": "# Installation\n\nNow includes setup instructions for testnet users."
}

Acknowledgements

This proposal builds on earlier ideas for decentralized wikis and documentation within Nostr, while solving common issues related to format instability and lack of project separation.

https://free-speech-flag-generator--wholewish91244492.on.websim.ai/

Please also see https://en.wikipedia.org/wiki/Free_Speech_Flag for more information about the Free Speech Flag.

Who can tell me what I encoded in the flag used for this longform post?

https://websim.ai/@wholewish91244492/nostr-desktop

https://websim.ai/@wholewish91244492/nostr-desktop/

What is Nostr?

Nostr stands for "Notes and Other Stuff Transmitted by Relays." Unlike centralized services, it is an open protocol designed to enable decentralized social networks and communication systems. It is based on two core technologies:

• WebSocket for real-time communication.
• JSON as a lightweight data format for information exchange.

Users identify themselves through a cryptographic key pair (public and private keys), ensuring authentication and the integrity of their content. Content is distributed via relays, which act as independent nodes. This decentralized architecture makes Nostr resistant to censorship and central control.

Challenges and Goals

While Nostr offers numerous advantages, it faces several challenges:

• Driving adoption in a world accustomed to centralized platforms.
• Improving usability to attract a broader audience.
• Maintaining its core values of decentralization, privacy, and uncensorability, even as it grows.

To address these challenges, both technical and social aspects must be considered.

1. Improve Usability

A major barrier to Nostr’s adoption is its current complexity, which can deter less tech-savvy users. Addressing this requires a focus on user experience:

• Simplify Onboarding:

  • Key management can be confusing. Automating key generation and secure backup processes can help ease new users into the system.
  • Clear, simple tutorials and visual guides can reduce the learning curve.

• Cross-Platform Apps:

  • Reliable and feature-rich clients for mobile and desktop platforms (e.g., iOS, Android, Windows, Linux) are essential.
  • Consistent interfaces and features such as dark mode or customizable themes can enhance user retention.

• Localization:

  • Supporting multiple languages in clients and tutorials can help Nostr gain traction in diverse regions.

2. Democratize and Decentralize Relays

Relays are the backbone of Nostr, and their availability and decentralization are crucial for the protocol’s long-term success.

• Promote Open Relay Hosting:

  • Provide detailed guides and tools to make it easy for individuals to host their own relays.
  • Hosting kits and optimized configurations can reduce costs and technical barriers.

• Incentivize Relay Operators:

  • Introduce monetization models such as micropayments through Bitcoin/Lightning to make relay operations financially sustainable.

• Simplify Relay Selection:

  • Users should have access to tools that help them identify trustworthy and active relays. Recommendation algorithms or curated lists could be helpful.

3. Educate and Build a Community

An informed and engaged community is critical for Nostr’s success. Public awareness and collaboration efforts should be prioritized:

• Awareness Campaigns:

  • Articles, blogs, and videos can explain the benefits of Nostr, particularly around privacy and censorship resistance.

• Workshops and Hackathons:

  • Events aimed at both developers and users can help spread knowledge about Nostr and encourage new applications.

• Integration with Existing Networks:

  • Tools that allow cross-posting between Nostr and other platforms (e.g., Twitter or Mastodon) could extend its reach and ease the transition for users.

4. Strengthen the Developer Ecosystem

A robust developer ecosystem is essential for creating new applications and features on Nostr.

• Promote Open-Source Projects:

  • Developers should have access to well-documented open-source libraries to build their own projects on Nostr.

• Ensure Modularity:

  • Standards and protocol extensions should allow new features to be added without compromising decentralization or interoperability.

• Enhance Interoperability:

  • Nostr could establish bridges to other protocols, such as Matrix or ActivityPub, to expand its use cases.

5. Prioritize Privacy and Security

Privacy and security are central to Nostr’s promise and should be continually enhanced:

• End-to-End Encryption:

  • Messages between users should be encrypted by default to ensure maximum confidentiality.

• Enhance Anonymity:

  • Integrations with technologies like Tor or VPNs could increase user anonymity.

• Data Ownership:

  • Users should have full control over their content, including the ability to export and delete it as needed.

6. Foster Practical Applications

To drive adoption, Nostr must deliver concrete use cases that go beyond social networking:

• Specialized Apps:

  • Decentralized marketplaces, secure messaging apps, or alternative blogging platforms could be built on Nostr.

• Bitcoin Integration:

  • Connecting with Bitcoin and the Lightning Network could enable micropayments and create financial incentives.

• Experimental Ideas:

  • Creative applications such as decentralized voting systems or educational platforms could attract new audiences.

7. Ensure Resilience Against Regulation

The regulatory landscape, particularly in the EU, could pose challenges for Nostr. Ensuring resilience is key:

• Preserve Censorship Resistance:

  • Nostr’s design should prevent centralized interference or blockades.

• Emphasize Technical Neutrality:

  • Nostr is a protocol, not a service. This distinction should be clearly communicated to mitigate regulatory pressure.

• Guarantee Accessibility:

  • Technologies like proxy relays or alternative connection methods could ensure access in censorship-prone regions.

Conclusion

Nostr offers a promising alternative to centralized platforms by putting decentralization, privacy, and censorship resistance at its core. To gain widespread adoption, it must strike a balance between technical innovation, user-friendly implementation, and the protection of its core values. Through targeted awareness campaigns, a strong developer ecosystem, and an active community, Nostr can become a groundbreaking platform for digital communication—without compromising user freedom or autonomy.

Was ist Nostr?

Nostr steht für "Notes and Other Stuff Transmitted by Relays". Es handelt sich nicht um eine Plattform oder einen zentralen Dienst, sondern um ein offenes Protokoll, das entwickelt wurde, um dezentrale soziale Netzwerke und Kommunikationslösungen zu ermöglichen. Es baut auf zwei Kerntechnologien auf:

• WebSocket für Echtzeitkommunikation.
• JSON als leichtgewichtiges Datenformat zur Übertragung von Informationen.

Die Nutzer identifizieren sich über ein kryptographisches Schlüsselpaar (privater und öffentlicher Schlüssel), was Authentifizierung und Integrität der Inhalte sicherstellt. Inhalte werden über sogenannte Relays verbreitet, die als Knotenpunkte fungieren und unabhängig betrieben werden können. Diese Struktur macht Nostr resistent gegenüber Zensur und zentraler Kontrolle.

Herausforderungen und Ziele

Obwohl Nostr viele Vorteile bietet, steht es vor mehreren Herausforderungen:

• Die Akzeptanz in einer Welt, die an zentrale Plattformen gewöhnt ist.
• Die Benutzerfreundlichkeit, die für breite Nutzung entscheidend ist.
• Die Wahrung seiner Werte von Dezentralität, Privatsphäre und Zensurresistenz, selbst bei wachsender Verbreitung.

Um diese Ziele zu erreichen, müssen technische, soziale und regulatorische Aspekte gleichermaßen berücksichtigt werden.

1. Benutzerfreundlichkeit verbessern

Ein zentrales Hindernis für die Verbreitung von Nostr ist seine derzeitige Komplexität, die technisch weniger versierte Nutzer abschrecken kann. Um dies zu ändern, sollte der Fokus auf einer besseren Benutzererfahrung liegen:

• Einfacheres Onboarding:

  • Schlüsselmanagement kann verwirrend sein. Automatisierte, aber sichere Lösungen für die Erstellung und Sicherung privater Schlüssel könnten den Einstieg erleichtern.
  • Klare und einfache Tutorials sowie visuelle Erklärungen könnten dazu beitragen, die Lernkurve zu senken.

• Apps für verschiedene Plattformen:

  • Zuverlässige und funktionsreiche Clients für mobile und Desktop-Plattformen (z. B. iOS, Android, Windows, Linux) sind essenziell.
  • Eine konsistente Benutzeroberfläche und Funktionen wie Dark Mode oder Themes können Nutzerbindung stärken.

• Mehrsprachige Unterstützung:

  • Lokalisierung der Clients und Tutorials in verschiedenen Sprachen kann dazu beitragen, Nostr in unterschiedlichen Regionen populär zu machen.

2. Relays demokratisieren und dezentralisieren

Relays sind das Herzstück von Nostr, und ihre Verfügbarkeit sowie Dezentralität sind entscheidend für die langfristige Stabilität des Protokolls.

• Förderung offener Relay-Betreibung:

  • Detaillierte Anleitungen und Tools sollten bereitgestellt werden, um es Menschen einfach zu machen, eigene Relays zu betreiben.
  • Hosting-Kits und optimierte Konfigurationen könnten Kosten und technische Hürden senken.

• Anreize für Relay-Betreiber:

  • Monetarisierungsmodelle wie Micropayments über Bitcoin/Lightning könnten dazu beitragen, Relays finanziell nachhaltig zu machen.

• Relay-Auswahl vereinfachen:

  • Nutzer sollten leicht erkennen können, welche Relays vertrauenswürdig und aktiv sind. Empfehlungsalgorithmen oder Listen könnten hier helfen.

3. Aufklärung und Community-Bildung

Eine informierte und engagierte Community ist entscheidend für den Erfolg von Nostr. Daher sollte der Fokus auf öffentlicher Aufklärung und Zusammenarbeit liegen:

• Bildungskampagnen:

  • Artikel, Blogs und Videos könnten die Vorteile von Nostr verständlich erklären, insbesondere in Bezug auf Datenschutz und Zensurresistenz.

• Workshops und Hackathons:

  • Veranstaltungen, die sich an Entwickler und Anwender richten, können helfen, das Wissen über Nostr zu verbreiten und neue Anwendungen zu entwickeln.

• Integration mit bestehenden Netzwerken:

  • Tools zur Integration von Nostr mit anderen Plattformen (z. B. Twitter oder Mastodon) könnten die Reichweite erhöhen und den Übergang erleichtern.

4. Entwickler-Ökosystem stärken

Ein starkes Entwickler-Ökosystem ist entscheidend, um neue Anwendungen und Funktionen auf Nostr zu schaffen.

• Open-Source-Projekte fördern:

  • Entwickler sollten Zugang zu gut dokumentierten Open-Source-Bibliotheken haben, um eigene Projekte auf Basis von Nostr umzusetzen.

• Modularität gewährleisten:

  • Standards und Protokollerweiterungen sollten es ermöglichen, neue Funktionen hinzuzufügen, ohne die Dezentralität oder Interoperabilität zu gefährden.

• Interoperabilität stärken:

  • Nostr könnte Brücken zu anderen Protokollen wie Matrix oder ActivityPub schlagen, um die Nutzungsmöglichkeiten zu erweitern.

5. Datenschutz und Sicherheit priorisieren

Privatsphäre und Sicherheit sind zentrale Versprechen von Nostr und sollten konsequent weiterentwickelt werden:

• Ende-zu-Ende-Verschlüsselung:

  • Nachrichten zwischen Nutzern sollten standardmäßig verschlüsselt werden, um maximale Vertraulichkeit zu gewährleisten.

• Anonymität verbessern:

  • Integration mit Technologien wie Tor oder VPNs könnte die Anonymität der Nutzer erhöhen.

• Selbstbestimmung über Daten:

  • Nutzer sollten die volle Kontrolle über ihre Inhalte haben, einschließlich Export- und Löschoptionen.

6. Praktische Anwendungen fördern

Um Nostr populär zu machen, müssen konkrete Anwendungsfälle geschaffen werden, die über soziale Netzwerke hinausgehen:

• Spezialisierte Apps:

  • Dezentrale Marktplätze, sichere Messenger oder alternative Blogging-Plattformen könnten auf Nostr aufbauen.

• Integration mit Bitcoin:

  • Die Verbindung mit Bitcoin und dem Lightning-Netzwerk kann Micropayments ermöglichen und finanzielle Anreize schaffen.

• Experimentelle Anwendungen:

  • Kreative Ideen wie dezentrale Abstimmungen oder Bildungssysteme könnten neue Zielgruppen ansprechen.

7. Widerstandsfähigkeit gegen Regulierung

Die regulatorische Landschaft, insbesondere in der EU, könnte Herausforderungen für Nostr darstellen. Es ist wichtig, Widerstandsfähigkeit zu sichern:

• Zensurresistenz bewahren:

  • Nostr sollte so gestaltet sein, dass zentrale Eingriffe oder Blockaden schwer umzusetzen sind.

• Technische Neutralität betonen:

  • Nostr ist ein Protokoll, kein Service. Diese Unterscheidung sollte klar kommuniziert werden, um regulatorischen Druck abzumildern.

• Zugang sicherstellen:

  • Technologien wie Proxy-Relays oder alternative Verbindungsprotokolle könnten den Zugang in zensurkritischen Regionen gewährleisten.

Fazit

Nostr bietet eine vielversprechende Alternative zu zentralisierten Plattformen, indem es Dezentralität, Privatsphäre und Zensurresistenz in den Mittelpunkt stellt. Um sich erfolgreich zu verbreiten, muss jedoch eine Balance gefunden werden: zwischen technischer Innovation, benutzerfreundlicher Umsetzung und dem Schutz seiner Kernwerte. Mit gezielter Aufklärung, einem starken Entwickler-Ökosystem und einer aktiven Community kann Nostr zu einer zukunftsweisenden Plattform für die digitale Kommunikation werden – ohne die Freiheit und Selbstbestimmung seiner Nutzer zu gefährden.

For transactions: https://websim.ai/c/Ot6OrpQqLJhfKn6wS

Btw, for sites created with websim.ai, you can download each page and host it yourself. Feel free to do so with my creations there.

I think I later need to fix the cover image for the transaction PDFs since they are always green or blue or something between.

https://websim.ai/c/rBhMUGcLetAtxfn1h

Btw, you can find all my public Websim AI bookmarks here:

https://websim.ai/@wholewish91244492

https://websim.ai/c/tZxeQ9DWZf9bCkTd1

As for the event viewer, making it brought several difficulties, and I'm not really happy with it in its current state. But it does show any event of any kind. If you enter your own pubkey, you can choose to only show events from pubkeys you follow. And you can always choose to either show all events or use a pubkey filter.

https://websim.ai/c/KI87SEQljLys4nVIX