BV/BO: It seems a few breads went down the toilet.

For example

Q Research General #19480: OSS is Fake Q, Thank You For Deleting His Bread of Lies Edition

Was archived on wayback, currently gives e0001

Was someone banned and it was that baker?

https://web.archive.org/web/20220118010404/https://8kun.top/qresearch/res/15400301.html

Deleting tons of posts should get improved in a way so that the BV/BO gets informed that all sorts of threads are also getting deleted so that stuff like this doesn't happen.

>>15404775

Also down:

Q Research General #19479: Spam Free Q Research Edition

http://web.archive.org/web/20220117230242/https://8kun.top/qresearch/res/15399530.html

>>15404779

BV/BOs should get asked if they want to delete breads too, otherwise only regular posts will get deleted. That would still fuck up these breads in a way, but they wouldn't be gone and notables would still be there.

Weirdly for these 2 breads previews still work fine for notables, so the posts seem to be still there.

>>15404782

BTW. both got fully archived including JSON data on wayback. Maybe Admin can restore them.

Would be appreciated.

>>15404787

There were good notables in them, like one on mRNA ingredients. They shouldn't get lost and ban logic should get improved.

>>15404788

You can keep IP post deletion from deleting breads as well. That isn't difficult to do.

BVs are asked for confirmation on certain actions, just ask if breads are supposed to get deleted or not and list the ones getting deleted.

>>15404791

>lots of notables deleted

They should be all on wayback.

But they should also get restored on here.

In theory I should be able to get them all from archive and at least re-post them if nothing else is possible.

>>15404803

They are in the notables bread.

What I was saying though is reposting the individual notabled posts, not just a list of them.

If restore isn't possible (it should be), that would be possible.

And the original JSON data is stored on wayback too, so all the raw data exists.

>>15404811

When something is copy+pasted over and over that's the definition of spam and we had the protocols for months non-stop over and over and over, I think last year or 2020. I remember having to filter that faggot over and over again. I may have even added filter rules for that shit. So annoying.

Yes, one PDF would be fine, once, not ever bread for months. That's the definition of spam.

>>15404837

>and will die off.

https://en.wikipedia.org/wiki/Graphite_oxide

Graphite oxide (GO), formerly called graphitic oxide or graphitic acid, is a compound of carbon, oxygen, and hydrogen in variable ratios, obtained by treating graphite with strong oxidizers and acids for resolving of extra metals.

How is this supposed to "die off"?

>>15404842

If you told me OSS was CIA, I would believe it, kek.

>>15404848

I doubt MOSSAD wants to restore breads on here.

>>15405063

>Maybe the hash is a symlink hash since the photo already exists?

No.

I figured it out yesterday.

It's PNG getting MODIFIED by 8kun for every upload and the upload time stamp is inserted into the PNG.

That's why hashes are different.

Try to download a jpg and upload it again, you will get the same hash.

For PNGs that's not the case. I already contacted admin about it. Hopefully will get fixed at some point.

And it seems some anon(s) got the original PNG file that produces that hash. That is all (it also seems the hash is calculated based on the original data that was uploaded).

>>15405096

I already wrote why.

PNGs should get treated like that as well, but are modified by 8kun.

Normally that filename is simply the sha-256 hash of the file data. That is all.

PNGs are modified by 8kun, so when you download them from here and upload them again, you will get a different hash, because it's not the same file anymore.

jpgs are not modified. MP4 to my knowledge are also not modified. It's just PNGs.

>>15405113

>Don't see the point of complaining to the admin about it.

It's not good, because normally same files are stored once only even when they are uploaded 100 times. This doesn't happen for PNGs because of that reason, also the hash is incorrect, because it's the hash of the upload, not the hash of the file on media.128donkeys

It's also not good to mark files with the upload time stamp anyway.

>>15405116

Well arggo downloaded it from here, because Q posted it on here and thus it was modified.

Use a binary file viewer and look at the end of the file. You will see a time stamp. That is the upload time on here.

>>15405124

Also think browser caching.

Currently same pic links to same URL, and thus browsers download it once.

Because of this here re-uploads and re-re-uploads are the same pic, but not the same binary data and thus browsers have to download 3 or 5 times.

>>15405133

Because this pic is a JPG, and not a PNG.

JPG is a different file format, and it is not touched by 8kun. PNG however is and the upload time is embedded at the end of the file and it's updated on each re-upload.

>>15405136

>and it is not touched by 8kun

To be on the safe side, it's not touched as far as I know.

For PNGs they may remove meta-data, idk. I have to check this in depth. Removing meta data good. Adding upload time to it bad.

>>15405144

>"Helper Anon" who posted AMERICA.png was able to have same hash that we anons could not.

Either that, or a shill that was just lucky and got the right file. You don't know, and I wouldn't use this as proof for anything.

There are like 1000 versions of that flag PNG out there. Q got his from somewhere.

Maybe it was especially prepared, maybe not.

AMERICA.png was posted 100 times for the last year or so. It seems to me that one or multiple anons were lucky and got the right file.

>>15405153

>That would only be an issue if the same pic is uploaded by multiple anons in the same thread. What is the chance of that?

Browsers cache until they are closed or even longer.

Also think spammers.