Micro knowledge bases on different relays. Users connects to relays that they believe provides signal, client aggregates notes to a single network.
Now for writing. Maybe ask the relay operators for permission to write? Do they know you? Any other type of payment/service model as a barrier of entry could also work. This alone will reduce spam significantly. I dont really think much work needs to be done on that end other than a little bit more usability in terms of relay management and discovery. Sure a knowledge base on Damus where everything goes can exist, but the signal is likely to be low.
If a user can't convince anyone that their writing is worth it to be on an exclusive relay, maybe thats a good thing. Regardless, they can still put up their own relay for others to read and write to.
Organization of content:
Parametric replaceable notes and modular articles composed out of smaller notes.
At a minimum, think about kind 0(metadata) and kind 1(text notes)
Now make an analogy to articles:
Article Header and article notes (kind 30040 and 30041 in my client indextr)
Article header lists the metadata of the article- title, authors, etc. But also the list of event id's that compose the article.
Article notes: The textual content of the article divided into sections (or even paragraphs, sentences it really doesn't matter). A tag that dictates the functionality of the note (flashcard, article, Jupyter Notebook, recipe. etc) the client can receive pull requests on how to display specific notes (like a Svelte component or a CSS file)
Replacement because knowledge is always updating. So if the author wants to update it they can, but the version history will remain for the article headers and notes.
Modular because you can compose new articles from existing notes. The list in the article header can also contain other article headers, or any other type of note.
Now, an article is not just linear, but it can be branching or whatever other weird structure.
Modularity of articles also creates heterogeneous articles. Take a YouTube tutorial about building an LLM. Take the transcript, split it into sections. For every section now you can link the documentation of the library you are using (as another note) with a jupyter notebooks in each section.
Library documentation: every function is a note with as many various examples as you want. Interoperability also allows for commenting on those notes - now its documentation with stack overflow. Interoperability also means individuals can comment on articles or specific sections.
Still very early, but thats's the basic outline.
https://github.com/limina1/indextr-client/tree/main