No.2301[View All]
The site's core features are still good, but the battle against bugs is never ending.
Joining the bugs now is poor design decisions and maintenance of Vichan over the decade that has left it in a poor state and even making some bugs impossible to fix. An example of this is the 0-NF database design (where all file information is put into an SQL column) makes it impossible to cleanly fix a bug where the home page runs out of images when people post lots of .mp4 files.
In no particular order:
- Database needs to be put into a more normalized format for easier bug fixes and maintenance
-
After PHP7.4 related issues the Twig1.x template engine should be ripped out and replaced with a Twig3.x version - API page generation will be less strenuous on servers and allow for clearer code. Exceptions might be on the installer and mod pages which will continue to use legacy page generation... but maybe they won't
-
Dumping YouTube IFRAME elements into the page is slow for users and forces a lot of unescicary JavaScript on them. YouTube videos need to be thumbnailed. - API page generation will simplify this issue.
- There's a lot of "kind of but not really OOP design" all dumped into a functions file or spread out hap-haphazardly. The design is already pretty close to being OOP, so might as well just take it all the way.
- Making modifications such that the kissu-board is usable for others
After these changes the software can't really be called Vichan anymore because even if some functions still exist, the core has been completely altered.
Old Thread:
https://web.archive.org/save/>>>/b/1884Some posts from there will be moved over.
No.3991
mobile input busted
No.4000
right click on a post and select hide. I need to make this more clear somehow
I'm seeing if that's a possible alternative, but I might switch to something more mainstream depending on reception
No.4001
unless you mean for vichan in which case I'm not adding frontend features to it at this time
No.4041
Could you allow other file types for /f/ I want to upload pdfs of books so that I don't have to use mega, please?
No.4043
I'll think about it...
No.4046
It adds another question of how to moderate the site. I need to consider the possible cases where people upload content others make money off of for a purpose that isn't educational.
Useless to most people, but the search feature is an aspect of kissu's frontend-redesign on the homepage.
https://kissu.moe/search.php?search=vermin&board=noneHowever basic modifications aren't enough to fix this shitshow to work across the site. The list of things that vichan fails at grows even larger.
No.4047
forced it into working by doing something inefficient. Might be problem in future who knows...
No.4063
update update
No.4064
last thing is to make vichan communicate with the API server. This is to say that I need to add a few lines into one of the functions and the software is in a state of bug fixing and quality of life changes
No.4065
Looks like I've programmed every use case I wanted in for a front-end imageboard software... next is debugging, then put it into an open beta debugging where people can evaluate what's broken or not.
React SSR server communicating with both kissu's modified vichan and an enhanced Golang API server for DB reading and JSON writting
No.4077
Seems like lots of game developers are releasing products next week so I'll see about getting it into a usable form by then as well.
Stylesheets are still not decided because I'm not sure what aspects of the layout to drop and which to keep
No.4081
Not sure I like the right click thing. I doubt there's a way to do it that's uniform across browsers while not clashing with the native right-click menu. I liked the <menuitem> proposal but Chrome won't implement it and I wouldn't be surprised if Firefox drops it in the future since they're the only ones supporting it.
No.4082
On /megu/ the score counter, a <div>, is inside a <p> element, which is invalid HTML. This is causing my browser to parse the page differently than intended and breaking 4chan X image hover and other features.
No.4083
>>4082i see, that was the issue
No.4086
narrowing down to two final aspects before I can do the final preview version before beta.
Have to set it up to (re)build all API pages on request
Have to have it accept posts and behave reasonably in response.
At that point it can be used to post on kissu with some features still in testing.
No.4114
I think there could be a problem with /all/, though it may be on my end.
No.4121
fixed some issues on the overboard
No.4125
verified the API server works as intended, next I have to clean up some concerns with the front-end and finally verify that posts can be made through the application with appropriate responses
Then final finally is testing it on a copy of kissu on my local machine. If all works as intended then it can be beta stage and act as an experimental new UI where people can give feedback and make adjustments to existing features.
No.4130
>>4081My thoughts are that developers are the main people who use the context menu and that the majority of users won't mind. It's an experiment that we'll have to see about
No.4135
After verifying that the API server behaves properly to scores and submissions it's to be tested against a copy of kissu. Forgot to handle reports and deletes so will have to add that in quick, but it's nothing complicated having handled posts and passwording has already been set up. The remaining aspects of polls and notifications will likely be checked over in this stage.
After this it can be uploaded and evaluated by users and the server for vichan and a new subdomain will be updated+added
No.4146
Use cases involving the presentation of data have been readied for beta version leaving information submission(posts, scores, polls, notifications, summaries and home page) to be readied. Final check against copy of the site will verify upload works smoothly.
No.4151
Spoilering WebMs not working on /qa/ for some reason.
No.4152
>>4151seems like it's on your end?
No.4153
>>4152oh, hold on I missread
No.4154
I don't have the problem
>>>/qa/48587
No.4157
i see, quite wierd
No.4158
all initial release use cases covered, but still need to test it on a copy of kissu and make sure there are no obvious crashes. Some optimization and a read only SQL user needs to be made too.
hopefully will have v0.9 out by end of day.
Will be buggy and lacking stylesheets, but a good milestone nonetheless towards an eventual replacement to vichan's front-end
No.4173
>>4159probably because youre using norm terminology while phoneposting
No.4175
While looking for ways to do perceptual hashing fast, I found this:
http://blockhash.io/
The C version of this is easy to compile and takes about 3ms per file in --quick mode on my machine to create a hash from recent thumbnails on Kissu. Could be useful for dealing with spammers.
No.4176
>>4175Was thinking that I would need to implement something for perceptual hashing. That looks helpful.
I would need to address the false positive issue and animated filetype issue
No.4177
there doesn't realistically need to be that much spam in /trans/ so I'll be doing a purge of it in a few hours.
No.4183
I dunno if anyone encountered it but put a thread per hour limit up while sleeping. That's off for now.
Today I'm going to put a config renaming crontab job on that activates from likely 06:00->12:00
This an alternative until there's a better system.
No.4220
We've moved to a new IP in regards to various tips offs about increased DDoS action.
Previous IP was exposed due to our previous history without cloudflare
No.4221
>>4220In other news, in spite of these amusements my beta needs a few more fixes and optimizations then I'm going to upload.
Beta can be criticized as needed in the next dev thread, but these will be handled in the future as I want to implement perceputal hashing and a combination of User-Agent and GPU canvas bans along with the 4chan standard ban lock out mechanisms.
No.4222
>>4221Canvas fingerprinting might be something you'd want to announce more visibly so that people don't first learn about it from NoScript's warning message. Speaking of which, how would GPU canvas bans work for users who don't run Javascript?
User-agent string bans would be pretty easy to evade, but it might help with the kind of people who spam from their phone and toggle airplane mode to change IPs. I'd recommend only applying these to the problem IP ranges, though. So you'd be banning "person in X region using Y type of phone" rather than one particular type of phone everywhere.
No.4223
>>4222I'm looking for the ability to not have to rely on wide subnet rangebans in order to reduce malicious activity. The current spammer hitting boards is a skiddie assisted by another guy who knows a bit about code. In that respect I believe it would require an adaptation by spammers to specifically target kissu as it's infrastructure is evolving to be divergent from the standard lynx, vichan dominance.
Various other ideas come to mind such as downloadable apps being able to punch through subnet locks. Canvas fingerprinting is just another tool that I'm examining, I don't know it's performance cost, development time or existing implementations as yet.
No.4224
>>4223Stricter cooldowns for certain IP ranges might be something to consider. How much legit traffic is coming from the ranges used by the spammer? If you log not only the user agent but the full HTTP headers of posters in that range, you'll probably find plenty of things to discriminate between the spam and legit traffic. But banning based on some aspect of the post the attacker controls is likely to turn into an endless game of cat and mouse. So it might make more sense to look into finding ways to whitelist the legit traffic from the range. Something like 4chan Passes, but given out for free and automatically to anyone in the range who isn't found to be spamming. I'm just brainstorming.
Maybe it could be as simple as a system that blocks a new thread if too many threads have been made recently by IPs in the same subnet.
No.4225
>>4224>So it might make more sense to look into finding ways to whitelist the legit traffic from the range. Something like 4chan Passes, but given out for free and automatically to anyone in the range who isn't found to be spamming.Maybe the post password could be stored in a cookie, and be whitelisted after a certain time and/or after the poster has made a minimum number of posts. Passwords could be removed from the whitelist if the poster is banned, or if no new posts have been made with that password in x months. That would be more transparent than tracking tracking user agents or canvas fingerprints, and would allow users to use their whitelisted password across different devices and IPs, while still slowing down spammers significantly.
No.4230
Looks like deleted posts aren't being sent to /trans/.
No.4234
>>4230it was disabled to deal with spam more efficiently, but it's back up now.
Megu banners will be removed in ~24 hours
No.4237
Since it looks like most of the issues around the spam have been resolved I'll fill some people in.
- Dox information posted about me is 80% false, but there was no reason to point that out at the time.
- He mistook me for being part of a pedophile ring jumping between jp boards.
- For some reason he believed that I had given /jp/ to someone(they must not be used to sites not following the 8chan model)
- /megu/ wasn't removed because of a request, but because I felt it was beginning to cause problems I had feared(although he tried to get cloudflare to).
This thread will be unstickied in a bit for a new one