Skip to content

Nostr CMS

User Stories

What problem does this product solve?

I want to publish a federated wiki that has RBAC, strong provenance, content addressable for linking, plus and can be cloned, forked, and merged. Each of these functionalities has their own reason,

  • RBAC - Role Based Access Control
    • The user must be able to require Authentication of users to read, write, or edit media.
  • Provenance
    • All changes to media much be tracked and preserved by default
  • Content Addressable Linking
    • Today, if you link to a website it can change it's content
  • Cloned / Forked / Merged
    • As you browse the web it should be easy to copy the content you are looking at, and keep it updated, make your own changes, and suggest changes to the creators of said content

Many popular wiki/SVC software that already exist don't quite fit all my requirements.

  • Mediawiki / wikijs
    • Lack of Federation
  • Git / Fossil
    • Lack of RBAC unless you have a repository per document. Which now that I think of it might not be a bad idea.
  • Obsidian / logseq / OrgMode
    • Great editors but each lack federation and RBAC for media. The end product should be compatible with each of these via extensions.
  • tiddlywiki / Trilium Notes
    • Lack of RBAC
What are your different use cases?
What are your different types of users?
  • See the question above and infer examples
What are some example user journeys?
  • Publishing mememaps.net
    • I run a script to add the correct frontmatter to each markdown file in my Obsidian Vault
    • I manually select each file I want to publish in my Obsidian Vault
    • I sync the current version of mememaps.net to my vault
      • The media is all uploaded via Blossom to be embedded into the content
      • The content is all uploaded as Nostr Events
    • I run a script, with my NSEC, which publishes all the new versions of the mememaps.net site
    • I go to mememaps.net and check if the pages have been updated
  • Cloning mememaps.net via CLI
    • One installs the CLI tool
    • One obtains the config for mememaps.net
    • The CLI tool downloads everything
      • All nostr events to a ndjson file
      • All Blossom Assets
  • Linking to a mememaps.net document
    • When linking to a mememaps.net document one links directly to a Nostr event. From that Nostr event's tags they can look up backlinks, assets, plus newer and previous versions
What is the reference design or what helped inspire your product?

Important TODO

Other TODO

Goal

We need take this site that I currently generate from my Obsidian vault and,

  • publish it on nostr, including backlinks
  • publish on nostr linking to specific articles
  • publish on a static site generated from nostr content
  • federate
  • version control

Anything do do with RBAC and the dream of Notion on Nostr comes later. We just want the publication of my nostr from Obsidian to treat Nostr as the single source of truth.

User Journey

Notes

  • If we want to have our own Obsidian Frontend that replaces Obsidian we need to figure out a couple different things for wiki
    • Block/Meme/Paragraph Modularity
    • Version Control
    • Backlinks
    • Labeled Backlinks with Reactions
    • NIP19 Embeds
    • NIP19 Links
      • Include Relay
      • Check for updated meme Document or Meme from User
    • AI conversations
    • Links into personal PKMS
    • Privacy
      • Publish updates that are encrypted
      • Publish updates to private Nostr Server with Auth

To Research

Next Steps

  • dentropys-obsidian-publisher Patches
  • Script that tries over and over to publish Wiki and produces useful logs with errors rather than mindlessly waiting one second between sending events
    • Sore published nostr events in sqlite
    • Sync published nostr events in sqlite
  • Test the nostrudel client with numbers in the d tag and see if it resolves, maybe we add an additional tag with the numbers and see what happens
  • Script to backup published nostr events of of wiki
  • Script to publish wiki to another nostr relay
    • Documentation of this script
  • Attach CID tag to NIP-54 events
  • Back Links integrated somehow for NIP-54
    • How can two events link to one another when they both need a hash one another's nostr event
  • NIP proposal for Per cell/block/line/sentence version control Notion/Anytype.io/Coda style
  • Obsidian Extension for Wiki Editing and Sharing keeping everything up to date
  • Note Pin Integration via NIP51
  • TODO
    • Write NIP-54 events to local nostr relay
    • Deploy local testing node
    • Function to take title, make everything lower case and replace all non letter character as NIP-54
  • Shelved
    • Test naddr rather than nevent for publishing on traditional nostr
      • We can use the uuid of the event for the d tag
    • Loop through all the wiki posts in the nostr file

Completed

Learnings

  • Tags we use for our 308018 events
    • d
    • title
    • a, a link
      • a tag
      • 308018:public_key:d-tag-title
    • e for mentions
    • e for fork
    • e for defer
    • summary, just a short string of what's up single tweet size
    • client (optional)
  • We do not need a nostr relay we needed NIP19 and NIP-54
  • Using NIP-54 we do not need to worry about creating a directory because linking via name of wiki page Obsidian style is supposed, and also makes federation interesting because you see what other people of the same topic generated
  • Using a separate private key for each document and directory is not needed for the changed scope of this project, NIP-54 does version control on the level of the document. Sentence or Line level version control is a completely separate project that is far too complex to be working on right now.
  • Batching events and putting them on S3 to be loaded into a local relay would have required developing our own Nostr Client which we did not end up having to do because we discovered NIP-54 was integrated in nostrudel, wikistr and wikifreedia with nostrudel being the one we actually like and use because you can modify your relay in the UI and it supports NIP19 addressing
  • We have a list of custom event type we were expecting to implement,
    • Custom Event Types
      • Directory
        • Contains documents and Directories
      • Document
        • Contains memes and Documents
      • Meme
        • It a version controlled string of text
    • The Document and Meme types were for line or sentence version control which we removed from the scope of this project for now because that would require a custom Nostr client be written
    • The functionality of the Directory Nostr event type can just be implemented with NIP-54 events with Obsidian style links and we can later check if NIP19 links are supposed
  • Found big need to leave dashes as a dash