https://github.com/nostr-protocol/nostr/issues/134

The Nostr coding people are doing cool network, client, relay things. The bitcoin-lightning coders are doing the same. Looking at what's going on with the third pillar, content creation and display, I had some thoughts from a publisher/media/creator point of view that you might want to think about as you code the rest over the next few months. Don't know who has been working on the NIP-23 for long-form content but the current description on git is a very basic model of what it should or could become. Not even sure we really need another event type (vs. better use of existing at protocol level). Maybe we can avoid going down some wrong paths.

And somehow all of this will get mixed in with the ligthning zaps bits.

First, think a bit about **what is going on with content creation,** at pretty much every level in every place:

1. Creator Dudes with gear out in the world somewhere (Ordinary Joe, journalists, advertisers, cinematographers, etc.)

2. Creator Dudes decide to record some things (thoughts, quotes, photos, video, audio, animation, etc.)

3. Creator Dudes now have a bunch of media files of certain types (jpg, png, txt, mov, mp4, mp3, etc.)

4. Creator Dudes decide they now want to express themselves to some Reader Dudes: let's tell The Story!

5. Creator Dudes sit down and edit The Story over several drafts and edits and restructurings

6. Creator Dudes now need to send The Story, composed of several media objects and some structure, to The Reader Dudes

7. The media objects and the structure-flow selected by the Creator Dudes are important: don't mess with The Story

8. Creator Dudes upload media objects (txt, img, video, audio) to some sites and press "publish" and "send"

9. Creator Dudes are happy: they have sent The Story

10. Reader Dudes are happy: they have received and consumed The Story

11. Sometimes, Reader Dudes spot mistakes and shout at Creator Dudes

12. Creator Dudes fix mistake

13. Everyone is now happy

14. Somewhere in the sending-receiving-consuming flow, hopefully The Story causes some Emotions in Reader Dudes

15. And if everyone is really lucky, some kind of value flows back the other way (likes, comments, buzz, coin, sats)

16. Repeat the loop for more creative goodness and joy

That's it. Nowadays, we all do that everyday with our 4K iphones but big media outlets or creative places are just throwing more resources at the same loop, whether it's a million-dollar ad campaign to sell cars or the New York Times sending 10 journalists to report on a war or an earthquake for a couple of months. So now think about coding sites and loops for that:

1. "Article" is just a relevant level container idea for the media objects in The Story

2. The Story can contain much more than some text and a photo

3. The Story can contain multiple media object and multiple types: 1.....n for all the types

4. The order of the media objects in The Story when displayed is important to Creator Dudes and Reader Dudes

5. The media objects for The Story have to be stored in some places

6. The media objects for The Story need to be easily added to The Story structure before publishing and sending

7. Huge editing-save features are NOT necessary. The are already hundreds of apps to save and edit every type of media object

8. But some edit-to-correct-stupid-mistakes feature IS necessary. Look at the Twitter debate on this over the past decade, or legal debates, etc.)

9. And some kind of place to bring the media objects together

10. The Story can be written, edited, contributed to, corrected by more than one person over time

11. Creator Dudes (and their lawyers) are normally very concerned about controlling the content they have spent all that time and effort creating for the Reader Dudes

12. Etc, etc,. if you have your own general coding thoughts to add here....

Now think about what is going on with Nostr and the Creator Dudes Loop and the coding for that (as far as I understand it at this stage, you know more about the details than I do for sure):

1. Normal Nostr notes can already do long-form text entries: do we really need another type?

2. Attaching a single image to another event type does not A Story make in 2023: needs multiple media objects

3. How can Creator Dudes reference and order those multiple 1....n media types in a single Nostr note?

4. How do you express "this Nostr note was written/edited by X multiple people"

5. Some form of edit button (time limited, versions, however you want to do it)

6. If Nostr is a protocol level effort, these considerations need to be coded at protocol level, like the value exchange bits

7. Nostr clients controlling or implementing who gets to see which versions get displayed depending on who can be bothered to code what is not going to work for Creator Dudes (and their lawyers)

8. If zaps + cool Stories, GREAT, but we need more mechanisms for that (paywall, subscription, crowdfuding, etc)

9. So ways of coding the creator-reader-creation-response loop at the protocol level across Nostr

10. And of making sure whatever clients are built enforce those protocol things in some way

11. And if Nostr protocol philosophy/goal is things like redundant relays, ways of doing and referencing the media objects like that

12. Etc, etc, for all the other questions you might come up with for an actual implementation....

When I coded this twice from scratch for my own site (Rails, Stripe, APIs, etc), I ended up with a media_objects table and an articles table and then you just attach it all in interesting ways, and a Content Dude can reference the already uploaded media objects in other articles and all the rest. Then Markdown (or something else) let's you copy and paste the objects into the flow of The Story however you want. Maybe for the media objects uploading-referencing problem you could do upload one file to multiple paid-with-a-few-sats nostr.media sites across the world for redundancy/anti-government, user sets preference but clients can fetch others if primary not responding, or something like that.

Anyway, just thought this perspective might be useful for those of you coding the rest of it.