This is the next iteration of Kissu's feedback discussion AKA devblog. Though there's not much in the way of dev there are still bugs to fix. This iteration will hopefully focus on admin-blogging or tool development.684 posts and 107 image replies omitted. Click reply to view.
Important Note: If you want a new software feature (or a really any sort of change) provide me with a detailed proposal. It must be at least 3 sentences long and tell me why it's needed.
Kissu's features are in a good place. There's no reason to rewrite anything, only improve and fix. On the outside, this is a unique site with an appearance you won't find anywhere else yet still your typical imageboard interface. This puts software at the software state we were sitting in 1 1/4 years ago before I started drafting a new UI except with more features that were more optimally integrated into the package.
Positives: No major raids or attacks on the site yet I've still been promoting Kissu. FAQ and Rules have been clarified to make it more clear to newcomers about what Kissu is about or how to use the new UI.
Negatives: Previously noted that we'd have an IRC channel, that exists(rizon#kissu) for when it needs to be used, but there are other ways to communicate that are better. Finances are what they are.
The tl;dr is that I just want to fix bugs at the moment. There are some software that I would like to write, but I can't justify spending the time on it since the gains will be so minimal that it's not effecting anyone except my pride/ego. Chances are the main software that I'll write are tools that support me doing specific tasks.
[det]Though it's in my head that I want to (1) Rewrite/Merge the entire backend in Rust with some other things, (2) Write an IRC server in Rust with some other things, (3) Do major refactors to the UI to make it look pretty and be easy to modify ; Chances are I won't because (1) is a waste of time since the PHP+Golang+NodeJS backend can do everything I want anyways. My spam testing show it can maintain a theoretical PPH of 300 which is faster than any other Japanese themed spinoff. (2) I don't have the means or want or appeal to cater to spammy people and give them a software, Sageru works perfectly fine for everyone and can easily have a bot written in it to do auto-moderation if need be. (3) is more likely to happen hand in hand with optimizations, but refactoring the code to an extent where everything is rewritting would create more bugs and waste time. It's not really worth it.
Further promote the site. Try to expand reach.
Certain organizational issues are present with topics not meshing together. I think this is causing a slight loss in activity. It's a much more blurry question
Kissu-Fr Version 4.18.0 release
¥ 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
as of >>10027
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!
Added in a mod feature to move replies and maintain cite links
>>10107>Added in a mod feature to move replies and maintain cite links
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
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
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)
I found a bug in deletes. Was it a delete through vichan UI?
Yeah, I tried to delete it but it gave me some error message and after that it was stuck in limbo.
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.
Character limit for Read-more on replies: 500 -> 800 characters
Character limit for Read-more on OP: 1000 -> 1600 characters
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
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
yeah, a matter of permission levels
that means it crashed
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
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.
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.
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.
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.
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.
Nice feature, and thanks for having it work on the old frontend as well.
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?
sure, you can check them