Kissu-Fr Version 4.18.0 release

Notable changes:
¥ Undo and Redo will work always.
if you input markup you can undo it. If you link a post you can undo it. If you change item in post queue it will undo it. and so on.
This entire post was ctrl+z and then ctrl+shift+z so it shouldn't destroy anyone's posts by accident

¥ Instead of updates being done by checking main files(for example the catalog or this thread) it will check a 90 byte info.json file which will be downloaded and then if there are changes you will download the up to 200kb file after.
This means lurking on pages will not use as much bandwidth for either server or you. Retarded imageboard devs create a convoluted method of adding websocket functionality to imageboards. This is better.

¥ Fix a bunch of markup related bugs
¥ Fix a bunch of QR preview related bugs
¥ Add the the bottom post form the ability to preview posts and dismiss images.
This form is spam-bot resistant so I'm more inclined to add it to other places as people have requested in the past.
¥ Fix issues related to read-more and previews

Next I have to upgrade the mod tools to allow them to move multiple replies into threads while preserving the cite links.
Soon I will begin tearing apart vichan for the tsukuyomi engine

>>10079
I didn't even know we could do that, thought pic was the only way.

>>10087
as of >>10027 the 11th

Added in notifications that will pop up when you enter a locked thread
> This thread is locked!
And if you're inside of a thread that gets deleted it will output
> This thread is 404 not found!

Do filename prefixes de-anonymize people?

>>10105
How?

Added in a mod feature to move replies and maintain cite links

>>10105
I don't think so. It does, however, blatantly announce that they're hiding their filename while the 4chanx method is more clandestine. (4chanx scrambles it with a unix time going back a year or something?)

>>10107
>Added in a mod feature to move replies and maintain cite links
THANK YOU

messing around with the ban message settings for a bit:

One person thinks that ban message colors should be saturated to stand out from the rest of the posts.
I think they should be discrete since ban messages are just there to serve as a warning or for a mod to say that they think I'm being a dumbass.

Previously ban messages were minimized by default, but I decided they should be default maximized

>>>/test/8046
I seem to have somehow created a thread that gives a 404 error for me when I try to view it on the old UI, but still shows up in the index/catalog and displays fine on the new UI.

exhibition bans sounds 4chan as hell to me

>>10113
Basically yes. I don't want to give off 4chan associations with the feature usage or have people use it for it's intended purpose.

But it's usage between mods to basically show that one mod disproves with another is fine. This is what I'm trying to achieve with the public ban feature. Not for mods=gods comments.((´・ω・)つ(・(・kneading tits)

>>10112
I found a bug in deletes. Was it a delete through vichan UI?

>>10115
Yeah, I tried to delete it but it gave me some error message and after that it was stuck in limbo.

>>10116
I don't use that UI so bugs can go unnoticed since actions on the UI go through different pathways on the server. Important to include the details in the future

last feature I'm adding to Vichan (by extension both UI).
After this, the UI and server software will be stable while I begin destroying vichan forever to write my own software which handles both UI styles.

Feature in question will be the ability to pick the frame for webm thumbnails. Easy to do on the old UI. I'll just add a new input field.
For new UI it will be integrated into the preview where a slider can be set giving you a preview of whay your thumb will look like.

small tweak:

Character limit for Read-more on replies: 500 -> 800 characters
Character limit for Read-more on OP: 1000 -> 1600 characters

>>10121
very nice

Thread archive doesn't seem to work anymore, now threads 404 immediately after being bumped off.
Is it intentional or some error?

not intentional, but I also see threads in the archive so I have to test

>>10123
I see what you mean

Looks like I forgot to account for something with the linux permission levels so it's failing. I'll test again in a bit after my server file manager slowly sets permissions

some boards will be seemingly broken for the current hour

>>10123
yeah, a matter of permission levels

Having an issue uploading a banner. At first I got an error: "Issue reading banner - 1", but now I get "You are not logged in" even though this happens like within a minute of logging in.

Here's the file in question, if it matters.

>>10136
that means it crashed

>>10137
It now works when I test it

...
In trying to check for duplicates, the server runs out of memory.

If you want to know the nerd stuff

Description="banners"

Restart=always
User=b-data
Group=nogroup
WorkingDirectory=/var/www/banners.kissu.moe/
ExecStart=/var/www/banners.kissu.moe/cb2
MemoryLimit=100M
CPUQuota=10%

WantedBy=multi-user.target


This means I had it set for the banner program to only have 100Megabytes of memory max. This was based on a budget if everything on the site was running at once. There might be certain banner filesizes which will cause the program to crash. I think I have some large preexisting banners to check with.

turned service on and off to test memory limits. Won't crash with <2MB files

Something relatively dry, but my current view of the /f/ board is that content will be semi-permanent like on /b/ or maybe /qa/ where the two boards support much longer time limits on content

Will I support HTML5.... HMMM.... we might have a subdomain eventually for this... Or maybe the /f/ board will be moved into a subdomain, we'll have to see what the future holds

Wouldn't normally respond to a locked thread, but the last part of this post is something to look into if you want to optimize your servers and user experience.
>>>/poll/2002
Nothing particularly wrong with the new UI for those who like more modern UI's, but it's simply not the old UI. Some of us are old geezers.
Can't please everyone with one design, as long as the option to use the old design is there then everyone will be happy.
After a bit more investigation I don't think the new UI is actually laggy as in it's causing performance issues, but the fact that the javascript ajax/fetch loading bar pops up immediately makes it feel delayed. This part isn't that important though as it's psychological and not reality.
With the old UI you have no movement on the page until after things have started to load whereas with the new UI you have instant movement which for old users gives a visual indicator that "things are happening", but in reality what it's actually sending off is "now you have to wait for things to happen" which is a confusing mismatch making it feel less responsive than it is for users who are used to the old style.
There's nothing to do about this part since it's not actually slower, some people just hate change and won't adapt.

This last part should be considered "good feedback" regardless of opinion on best UI as it will speed up your new UI if you choose to do something to fix it.
I found a key difference in the new UI and the old one which explains a bit more what makes the new UI feel slower.
Inspect element and open network to confirm:
When you are post-hovering on vichan UI, as long as the post is displayed somewhere in the page (for example in the thread) it will load the post instantly by taking from the page or a preloaded json or whatever it does. In the new UI even if the post is on the same page and loaded, it will always use the API to load the post meaning you have to wait for something that was previously instant. To make matters worse it does this for every single post instead of loading a json of the entire thread into your cache to make future loads of any post ITT instant.
There's no reason why someone should wait ~100-200ms (or whatever their network delay is) every single time they want to post-hover when the post is already loaded just hiding somewhere off-screen. There's just a lot more waiting for things that are instant on almost every other imageboard. That's probably what I subconsciously noticed that made it feel less responsive, because until this is fixed it technically is less responsive.

>>10143
In the unlikely event that this is a browser specific problem or whatever is the cause I don't know, this happens with both Firefox and Tor. The delay isn't there on vichan UI.

>>10143
Using the elements on the page for various purposes is an interesting idea. React gets you into a situation where posts feel as if they are isolated from one another so fetching from a central resource keeps the code cleaner and less out of control. So picking the JSON resource was the first thing that came to mind. However, each post is also stored into an array of observers/listeners by the Flux/Redux style design, so I should be doing as you say.

>which is a confusing mismatch making it feel less responsive than it is for users who are used to the old style.
that's your fault for being used to a standard that is going extinct on the internet. Every page on the internet written by someone who's not 60 years old is doing this now.

It's fucking hilarious to be considering vichan as a standard for not wasting your data when every n seconds it pulls the entire HTML page out to do what it needs to do. Vichan doesn't even have it's operations integrated into JSON APIs.

It has these optimizations precisely because it is so shitty. But it is not worth disregarding how it worked around being such a terrible design

have to use WASM FFMPEG to solve a use case requested by someone

FFMPEG.wasm might be a write off.
- A security vulnerability forces it to be one core or I have to disable a bunch of site features
- Single core has errors I can't find a resolution to
- Only work around is reloading/rebuilding ffmpeg every time someone want a thumbnail
- It might be causing an occasional tab crash.
- Not sure the project is even maintained
Have to get to a situation where ffmpeg.wasm single core can be used(by end of day) or I'm going to have to use ffmpeg.js.
ffmpeg.js is slower though. By how much I don't know.

after i release video thumbnail preview I'm going to make a poll asking if people want increased accuracy...

bleh, actually i still have time so i'm going to make it so that the inacurate <video> version is attached to the preview system and then clicking on a certain icon will take them to a new tab which they can use the FFMPEG version to more accurately pick a timestamp if they're being memey. On hitting submit in the new tab it will transfer the info from the FFMPEG tab into the creator's tab.

Part one of user selected thumbnails added.
Second part probably starts tommorow. Likely not today.

Issue with the current version: It's not truly frame accurate so the timestamps are not always going to reflect what the server picks as a video thumbnail.
Enhancement of the feature will allow for accurate thumbnails.

Second part is proving to be very advanced/complicated functionality. I don't expect any imageboard in the current decade to possibly do this idea in any comparable level.

>>10145
>that's your fault for being used to a standard that is going extinct on the internet. Every page on the internet written by someone who's not 60 years old is doing this now.
Well they're wrong and I'm right.

New experimental/beta functionality added
Pretty niche feature,
Setting thumbnails for videos was made possible recently. The method available on the QR and Form is fast, but is inaccurate. In order to more accurately set thumbnails a new feature is in an experimental state.
When you have a video in the form and a preview is enabled, there's an icon that will be pressed to bring up a popup window to the FFMPEG Thumbnailer.
You can leave this popup in the background or directly use it to change your current preview and change the milliseconds used to set your thumbnail.

- Still a bit on the buggy side, but issues will be worked out over time and better behavior will be added to it.
- Noticing that private tabs don't have a feature required to run it.
- Some issues with it working on the footer form

Bar those issues, standalone it should be usable on /thumbnailer/
Will be faster on better computers since it's a browser based FFMPEG in web assembly.

>>10184
Hmm, let me try.

And again.

Nice feature, and thanks for having it work on the old frontend as well.

>>10187
By luck really. WebAssembly got completely gutted a few years ago following the Spectre and Meltdown CPU vulnerabilities which ruined multi-threaded applications(2017) and they've only started trying to make it work again(2020).
I can't have kissu.moe/thumbnailer/ work inside of the pages because youtube hasn't enabled a header, meaning that I'd have to use single threaded FFMPEG. And I tried to do exactly that except FFMPEG WASM hasn't had an update in a year and single-threaded breaks.
https://blog.logrocket.com/understanding-sharedarraybuffer-and-cross-origin-isolation/

This tool is really a thing of modern web design
- multi threaded Web Assembly
- React Hooks
- Indexeddb API
- Broadcastchannel API

I want to comb through the banners to find dead links. Can I have your permission?

>>10803
sure, you can check them