nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

We have a censorship bottleneck on our media. Most of what we say here is thru images or videos, and each is stores in few Servers.

So government can just shut them down and we lose our images/videos

Proposal would be to let many media servers be used for each post and store the hash of the image in case they get counterfeit.

We can even use hashes to get media from IPFS, so servers can save on storage

#nostr #amethyst #damus

Reply to this note

Please Login to reply.

Discussion

There have been a few proposals, such as putting the files on nostr in base32, PR 751 media attachments, etc.

I think your comment is important. I don't like the single-URL references. Because events can't easily be censored (we can copy them elsewhere and nothing breaks) but URLs can. It must be that the file reference doesn't break if the files have to be moved.

I suggest using a SHA256 hash of the file as the file reference, with an indication of some sort of distributed storage (DHT, IPFS, etc) which should be flexible so that alternate distributed storage schemes can be added over time. The hash of the file will never become a broken link.

Another possibility is having the choice to store and relay specific content within the app, like Amethyst. Each device then becomes a relay for that content, but not all content, in a specific folder at the expense of performance. Could have connection and upload limits.

Not sure how addressing would work for a relay that is periodically offline.

its called p2p

I think it's incredible that external references on nostr are not hashed.

It's really easy to tamper external references this way.

nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z

They are hashed on Amethyst since April. This is why we implemented NIP94 and NIP95 back in April. NIP 95 is even better because you can migrate pictures from relay to relay when they disappear. People don't even notice the server has changed. It works like a charm. If it was for me, we would never use urls ANYWHERE in nostr.

NIP 96 is next.

That's so cool, nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z! I'm curiousl to see how the json event looks like! Maybe I will have a look using gossip from nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c

In case that someone/government/hacker takes all of the image servers down and someone find an alternative with backup images, what should a regular user do to see all images again?

query a dht

Is it possible for the data to be stored in IPFS or maybe magnet/torrent etc?

ipfs is bad and torrents are banned on ios. I don’t think media should be censorship resistant. I’m happy if child porn is censored.

I'm not think or porn, I'm thinking of videos proving war crimes for instance, like in #israel #palestine

I think links to bittorrent is fine in that case

Difficult one.. noone wants child porn to be eternal, imagine the trauma!

At least maybe some hash so that people know the video claiming to be the original is really the original

torrent is banned wtf lol?

https://news.ycombinator.com/item?id=32767277

>Apple doesn't believe in software that exposes their users to content outside of their walled garden.

I would be a little concerned that images/ videos from the numerous wars western nations are involved in might be censored.

distribution is less important as long as we hash address the files, we can distribute any way then

blake3

What relay implementations support NIP95? Few weeks ago I was unable to find any. Has this changed?

look on github?

Would be easy to add to damus’ imeta data on upload, but it hasn’t been a huge concern for damus atm because nostr.build is pretty trustworthy.

Would be even more useful if damus first downloaded and metadatad/hashed any pasted image url.

It would need to be optional. Nostr is already a data sink, and my mobile does not need to download the 4000x9000 version of an image. Honestly I’m a bit surprised that more native clients don’t support something like imgproxy to reduce this burden and reduce IP address exposure.

Secure, uncensorable image upload/retrieval adds a lot of limitations that aren’t relevant to the average cat photo or meme.

Cat photo or meme for sure it's not very important, but If you have to report on war, like Israel vs Palestine, or anything where government will hunt down inconvenient truths, then you need to be censorship and tempering resistant

I agree, 💯%. It should be as easy as flicking a switch for when things get real. There are definitely two scenarios for using Nostr - the normie one and the one where someone is subject to an oppressive regime. Both should be considered and accounted for.

i wonder if blake3 would allow fetching a lower res from the same data? is there any image formats that allow that?

yes you can partially load data from some image formats to have a lower res/quality image and blake3 will allow this with hash verification

https://blog.codinghorror.com/progressive-image-rendering/

https://www.youtube.com/watch?v=ByH7RMsMxBY

So if government take a nostr.build down or it goes bankrupt and a new Server is made, with the hashes it's possible to know if the images and audios has been tempered with?

ya

Ok, thats a good solution

I can safely say that most of nostriches eggs are in one nostr.build basket.

That is too risky.

ridiculous that we have a distributed social protocol but only for text

and when nost.build goes down? goes woke? goes fed?

not sha256 use blake3

https://www.youtube.com/watch?v=nk4nefmguZk

and check out iroh which is ipfs using blake3

https://github.com/n0-computer/iroh

There's the possibility of censorship on media or any other external content (governments take down links to fotos, Videos, audios, etc, or the serves themselves delete it). On the current model, our external content storage is the weakest link in the chain of our censorship treat model. As a lot of the communicaton is thru images or videos, that's a very serious issue.

Proposal is to add hashes to our external contents and possible serves to download the content from, so it's easy for clients to search for content elsewhere.

Sha256 might be not enough in future (imagine in 10 or 200 years, quantum computing, etc), so could be better that there's the link, the hash, and the algo used, so that in future it's easy to change the hash algorithm.

If you want to use multiple media, make that a list structure.

If you want to preserve this media position inside the text, you can put a pointer indicating where's the media supposed to appear inside the text, say after character 100, or after byte 800 (I don't know if it's better byte or character.

Puting all together,we have the following structure:

{externalcontents:[{

positionontext:100,

possiblehashes:{

sha256: 0x eeafb2,

sha1024:0x ffeabc4438,

etc},

possiblelinks:[

server1.com/link1,

server2.com/link1,

torrentsite.com/magnet/link1,

ipfs.io/link1, newstorageparadigm.com/link1]},

{

positionontext: 200,

possible hashes: ...

..}]}

/Link can be a traditional link or something that tells the server to fetch a content with the specified hashes. Then you could use torrent, magnet, ipfs or whatever new technology that comes on the future.

If on the future we have a user, say, Snowden, and all his possible media were taken down by government or the server itself he could:

a) do nothing and the clients will go to list of serves he put on his original message and try new ones. If all are down, then B)

b) the user/client developer might specify additional servers to search into

C) Snowden publishes news Servers where his mídia can be found

D) Snowden makes a new event with reference to the original and ask to update the list of sources

D) if Snowden has not the originals anymore, but have something equivalent, he can send a new event asking to update the hashes and the servers (I actually don't know if it's a good idea because someone might steal his key and break havoc with past messages).

Like this, we stop being prone to censorship on external content, which currently is a very high and unmitigated risk.

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c nostr:npub10qk5zpmhv7rspp87shajf7d24yrf4lyr7w0m25wv9w78grs4k0sq0gq8pc

#nostr #amethyst #damus #nostrproposals #censorship

Other possible storages this enables: Odysse, lbry, rumble, dht, etc

this is too complicated just use a versioning scheme and blake3 hash, look into iroh

https://github.com/n0-computer/iroh

Most of what we say is definitely not through images or videos.

I see some hashtags in which most of communication is dona via images or videos, like the ones about war, like #israel or #palestine

a picture is a thousand words

memes are most of social

Maybe we can standardize replying to another event with a NIP-94 containing other sources for the media that are in the original event -- for whoever is interested.

You could make a bot that downloads every image or video you ever see on Nostr, pushes that into IPFS and then publishes that as a NIP-94 event with an "e" tag to the original.

Then clients could display a thing on the side saying something like: "broken link on the picture? try these other sources"

Of course this would be very unsafe, but better than nothing. Maybe just show trusted sources first.

It will not be unsafe if each image/external reference has a hash, the the client can check If the hash matches before accepting the content

Hash should be flexible, so as to allow ipfs standards, torrent, dht, etc

no this is what caused ipfs to suck having too many options, just use a single hash function have a version so you can change it later, bittorrent only went to version 2 recently

with blake3 you can verify any chunk size from 1KB denominations

no

Hashes are needed also

If each image/video has hashes, the client can automatically search on alternative servers for contents with same hash and display it

For this the original event must have the hash of the image, otherwise when someone in the future steals the private key all previous messages would have it's images/links compromised

not needed, just hash address the media inside kind1 notes and let clients and relays decide where to fetch it

My 2c - IPFS already has decentralisation and DHT functionality working at scale, better to piggyback on what works than roll our own

I think that's what I meant: how to use ipfs or torrent/magnet as a backup

iroh which is an improved version of ipfs, uses blake3 hash which unlike bittorrent v2 and ipfs will allow direct hashing of the file for addressing ie we can address media like we do notes

https://github.com/n0-computer/iroh

Sounds interesting. Can we already download movies with that?

its very alpha but we should, someone is working on using blake3 and nostr with torrents

i cant emphasize how powerful the blake3 hash is as it allows so many things particularly direct hashing but also variable chunking, it removes the need for torrent files, a magnet link is a link to the torrent file aka metadata not the actual file

what it means is we can just hash the file and put that in note, clients can then query http repos or indexes or a dht with the hash to find where to get the file ie it can be distributed p2p or nostr relay style etc