There is no here, there is no there. These apps are not places, they interfaces. (Relays are places, but lets just ignore that side of the story for a second).
When you publish your pictures in kind20 events, it is clear they are pictures. This means any app that supports kind20, will automatically pull up your stuff and show them in whatever fancy way they do it.
When you post your pictures embedded in these kind1 posts, they might as well be you informing us on what you had for breakfast this morning, or that you stumbed your toe...they are 'tweets'.
You are a photographer, and want to have a "photopgraphy presence", those kind20 events will do that for you. Think of it as uploading your portfolio, subsequently every app(that supports kind20) allow people to interface with your porfolio.
Lets take another example. You could tweet that you are going to host an event at some date at some place. Or you post a specific calender event, that interacts with peoples calender apps (that you could also reference in a tweet).
You could tweet how many miles you ran and what route you took, or you can post this particular work-out event that interacts with peoples jogging apps (that you could also then reference i a tweet)...
I hope i am making sense.
For some deeper insight on Nostr, if you are a bit "technical" perhaps my FOSDEM presentation will clarify some things:
https://m.youtube.com/watch?v=Tbt3jL1Ms0w
(The irony of me posting a youtube link is not lost on me, but...early days)
No, it does make sense, thank you - I assumed that an image posted here was a kind20 inside a kind1, similar to the way the fediverse works.
I’m a day in, so I’ll get it figured out, but thank you.
Olas is acting like it’s read only, but it shouldn’t be. I don’t know if that’s my error or the platform, but it *appears* to be the platform.
Well, you a half right. The picture is not actually in the event (regardless what kind), a link to the picture is.
But its not a regular link, its a blossom link. Blossom is this seperate system that evolved out of Nostr where files can be stored on servers with their hash as the ID. Currently your pictures are stored on the primal server. But if lets say the primal server dies tomorrow, you can reupload the picture (as in the file) on another server, and the protocol is such that clients will figure out that the innitial link is dead and look if it is hosted elsewhere (based on another event where you inform the world what blossom servers you use), and a such heal itself automatically.
So your innitial post has this link:
blossom . primal . net /b5a597df5cf2bd0b5427583893e356a01df314e36fe5aaba9595675228f3f990 . jpg
But you can also store it on other servers to ensure that the picture will pop up in the future as well, even if primal goes away.
(Oh and the whole point of Nostr is that Olas is not a platform, its a client :) ).
Well recon that is enough for day 1 on Nostr.
Welcome
I have a fair bit of long form video content too, so I set up an IPFS node for that. Maybe I should just do that for the images too?
IPFS is crap, and blossom makes far more sense :)
Trying to provide data availability guarentees using fancy pancy tricks is a stupid endevour.
Just accept its stuff on drives, and more drives is more redudant. As such the only thing you need is a unique identifier and a method of sharing on what drives those uniquely identified things can be found (Nostr itself follows the same principle). Its the most grugbrain approach and by the looks of it it might actually just work. Whereas....does IPFS actually work?
You can set up your own blossom server if you want. And you can also set up your own relay while you are at it.
Is blossom going to support a 30 minute 400GB 4k video file though?
Is a server going to support a 30 minute 400gb 4K video file? Depends on the server :)
Well it also depends on the protocol, the filesystem, how many levels of abstraction and containerization we're playing with, and a lot of things.
I'm not opposed to blossom, or whatever works, I just want to be able to post a link to a file and have the video play, preferably with a thumbnail and video controls.
