[ home / bans / all ] [ qa / jp ] [ maho ] [ f / ec ] [ b / poll ] [ tv / bann ] [ toggle-new / tab ]

/b/ - Boson Technology

Also known as Boson /g/

New Reply

Options
Comment
File
Whitelist Token
Spoiler
Password (For file deletion.)
Markup tags exist for bold, itallics, header, spoiler etc. as listed in " [options] > View Formatting "


[Return] [Bottom] [Catalog]

File:a7310cbfebdfb3977b06bbe65c….jpg (193.24 KB,1200x1725)

 No.8005[View All]

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.

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.

Updates:
[det]Software
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.
[det]Nerd Things
People may not fully realize it, but Vichan is a dead end and their HTML and JavaScript implementations leave developers at a dead end. Not that I really endorse alternatives such as JSChan or Lynxchan which think NodeJS doesn't have similar problems as PHP... at least the UI is more moddern
[/det]
Administration
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.
[/det]
Future Tasks:
[det]Software
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.

[/det]
Administration
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
[/det]
684 posts and 107 image replies omitted. Click reply to view.

 No.10082

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

 No.10087

File:C-1655288476127.png (238 B,33x32)

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

 No.10088

>>10087
as of >>10027 the 11th

 No.10101

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!

 No.10105

File:R-1655556273368.png (3.22 MB,1814x2424)

Do filename prefixes de-anonymize people?

 No.10106

File:Question_wave_Yume.gif (377.38 KB,534x343)


 No.10107

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

 No.10108

File:[SubsPlease] RPG Fudousan ….jpg (221.88 KB,1280x720)

>>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?)

 No.10109

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

 No.10110

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

 No.10112

>>>/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.

 No.10113

exhibition bans sounds 4chan as hell to me

 No.10114

>>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)

 No.10115

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

 No.10116

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

 No.10117

>>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

 No.10119

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.

 No.10121

small tweak:

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

 No.10122

>>10121
very nice

 No.10123

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

 No.10124

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

 No.10125

>>10123
I see what you mean

 No.10126

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

 No.10131

some boards will be seemingly broken for the current hour

 No.10135

>>10123
yeah, a matter of permission levels

 No.10136

File:Screenshot 2022-06-22 0005….png (27.12 KB,419x313)

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.

 No.10137

File:Banner 54.gif (797.64 KB,500x90)

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

 No.10138

>>10136
that means it crashed

 No.10139

>>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.

 No.10140

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

 No.10141

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

 No.10142

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

 No.10143

File:054cc20373ce95ea7cd5402a22….jpg (302.35 KB,1378x2039)

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.

 No.10144

>>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.

 No.10145

>>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.

 No.10146

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

 No.10147

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

 No.10152

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.

 No.10153

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

 No.10154

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.

 No.10156

File:C-1656102549563.png (197.04 KB,1118x842)

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.

 No.10158

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.

 No.10170

>>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.

 No.10184

File:test.webm (6.95 MB,854x480)

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.

 No.10185

File:ingrown horn.mp4 (4.51 MB,202x360)

>>10184
Hmm, let me try.

 No.10186

File:ingrown horn.mp4 (4.51 MB,202x360)

And again.

 No.10187

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

 No.10188

>>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

 No.10803

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

 No.10804

>>10803
sure, you can check them




[Return] [Top] [Catalog] [Post a Reply]
Delete Post [ ]

[ home / bans / all ] [ qa / jp ] [ maho ] [ f / ec ] [ b / poll ] [ tv / bann ] [ toggle-new / tab ]