Iris has gone really slow/weird.

🖼️ And for those of you who like history and photography and images and stories, this is a masterclass in intepreting perspective and meaning and documenting reality:

📷 Interesting series of short videos about the history of photography:

I hope people building stuff on Nostr keep building it for the whole world at the same time. None of this "cool new features only for dudes in the US" horseshit because someone wants to sell cool and edge and revolutionary but really lawyers and courts and taxes and we're not that rebellious, so if you're in Europe or Africa or Asia you can't have the cool new stuff.

Flow and channels and energy and directions.

⚡ 📝 🖼️ 🎥 Nostr + creators, publishing, media types, stories, long-form. #[0] suggested I post it on Github for the people actually coding, so I structured it a bit more. Here on Git or just keep reading on Nostr: 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.

What is the best way or sites to get a 10-yr old into coding a bit, just to have fun and start learning..?

⚡️Some of the zaps are working, others not.

Don't know who is working on NIP-23 for long-form content but the current description on git is a very basic model of what it should become. Two major problems I see with it from a publisher's point of view: 1) the schema/db model: "article" is a container idea for text + stuff + written by one or more people. You might think of "blog post" as text and maybe a photo, which is the basic idea and clearly what someone has gone for so far, but when you start moving up the publishing ladder in time and effort, you need text + multiple media objects + multiple authors/contributors. The media objects might then be displayed as a gallery of photos, or inline photos with descriptions, or maybe someone wants to associate pdfs with their article. You end up with a media_objects table of different upload types (jpg, png, mov, mp4, mp3, wav, pdf, etc, etc) and some way of associating and displaying 1....n objects within a single article AND it needs to be in the display order that the author wants to tell his story, not the way a client wants to do it. 2) clients controlling who sees a publishers content across the network, or which versions get displayed depending on who can be bothered to code what, is going to be a huge red flag for publishers.

⚡ Is this someone doing lighting crowdfunding already? Asks you to connect to Twitter and lightning...

⚡️⚡️Added Nostr key to the Fountain podcast app:

⚡ 🖼️ So if I, or you, as a content creator, decide to publish on Nostr: i) a short paragraph/message ii) a longer article/chapters/book iii) a photo/gallery/artwork iv) a video/animation v) an audio file/song/podcast ...the value exchange flow back from readers or listeners should be baked in, whatever the clients decide to do to display it all. Maybe: i) Nostr Twitter 1, 2, 3 take the text paragraphs and images ii) Nostr Instagram 1, 2, 3 take the photos iii) Nostr YouTube 1, 2, 3 take the videos iv) Nostr FB 1, 2, 3 try to take it all iv) Nostr Substack-Kindle 1, 2, 3 take the longer texts ...or WHATEVER each client decides to try to do with it all. Then the content people can focus on great content and the client builder people on great clients. Then you would know, and be safe in the knowledge that, as a content creator, it doesn't matter what all of the creative client coder people are inventing with their cool new sites. Your readers or listeners, whichever existing and new client sites they find you on, can still find and read and reward whatever it is they like that you have created. On the client side, instead of clients controlling the value exchange, they are incentivised to build clients that both readers and content creators also WANT to be part of and send sats to because the client is GREAT as a client, not because a client controls the underlying core value exchange between creator and reader.

⚡ I would argue the value exchange bit needs to be in the core of Nostr, right alongside the content message bit. And it should be enforced some way at that protocol level. If it is direct reader-creator with no intermediaries necessary across the whole network, no clients, no companies, no government, no banks, etc, etc, that would be really big. A massive flattening of the content-value-exchange loop. Imagine what that would do to journalism and media and video creation and songs and writing and all the rest, all around the world.

⚡⚡ For me looking at it over the past few weeks, the answer to the question of Nostr's "superpower" would be something like protocol level + relays + zaps. That's it, that's the core, the engine, the increased flow. All of the value exchange bits need to be hard coded, as it were, at the protocol level, so that no one client site (or company, or government), now or in the future, can control that bit either. Protocol level value zaps, available to everyone with just a few clicks.

⚡⚡ If the innovation is creator-reader direct via Nostr at the protocol level, that is wonderful because then people can do different sites that organise it all in different ways but whichever one your note is found on, you as the creator can see the likes or zaps or comments from all of them. The other sites are just displaying them in different ways. But if we start building things in the middle of that, instead of incorporating them at the protocol level (zaps, paywalls, media files, long-form, whatever), then the middle bits become necessary to its functioning, not direct creator-reader-protocol for the whole network wherever the notes are found.

And here #[0] is having a go at a long-form tool,

Habla

Habla

Read, Highlight, Write, Bookmark, Earn

Tremendous innovation from everybody.

⚡⚡ You coding dudes are all opening beachheads and channels to increase the flow.

⚡⚡ Ohhh, look at that, somebody just invented posts by zaps. Well done. Was that you, #[0]?

⚡️Whatever someone is doing with a sats bot appears to be working.