Thoughts on Nostr + long-form, NIP-23, content, media types, publishing loop

[Matthew Bennett]

Posted a version of this yesterday on Nostr and StackSats.io suggested I post it here for the people actually building. So here you go...

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.