No.2301[Last50 Posts]
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.2303
This dice roll thing could be improved by repeating what you rolled with the result.
>>>/qa/8377
For example, instead of "Rolled 3, 4 = 7" it could say "Rolled 2d6: 3, 4 = 7" so you wouldn't have to mouse over the email field. 4chan X used to do something like that before the email field on 4chan was removed, at which point 4chan started doing it that way itself.
No.2305
>>2304There was actually a pixiv issue as well. I don't think I corrected it. i haven't touched the ffmpeg aspects
No.2306
https://kissu.moe/qa/src/1583127321582.mp4maybe kissanime does something to their files that makes it incomprehensible to ffmpeg
No.2307
>>2306I downloaded it straight from YouTube using JDownloader...
No.2313
Not sure if it's just me, but the post form hangs on "Posting...(100%)" for what seems like a large amount of time
No.2314
>>2313Does it eventually post?
Are you using a file?
No.2315
If yes and then no, the server is taking a ton of time to rebuild pages I think. I've yet to benchmark performance
No.2316
I see, I believe the bans table has gotten too huge.
I want to back it up real quick and then you should start seeing gains again
No.2317
>>2314It does post, let me check
No.2318
there you go, seems fixed.
We need a better solution to the database. I'm not sure if we're caching it even.
No.2319
>>2318Maybe you should make it so that you have a proxy list stored in one area, and only when it detects possible spam does it check the ip for proxy?
No.2320
I think it's the case that there's a problem in the way the database is used
No.2321
i guess it could potentially be a mix of both an ai solution and database optimization. But I know for certain I haven't made any adjustments to the database and that there's tools put in place for optimization. It also will require less time to set up
No.2329
megu replies are NOT showing up on the homepage
No.2341
brought my ban logger up on a more SEO friendly domain name
https://anychan.infoman this thing is trash... but im going to use it as a way to get people onto this site if jlist doesn't give me the free 5$ to advertise them
No.2342
>>2329Hate the front-page
No.2357
front page could be a good rework
kissu is about 5x slower than 4/qa/. I want to get this up
No.2361
>>2357used to be 10x slower it's getting better
also you need to take into consideration the quality of each
4/qa/ is shit, and seems to be heading towards a /bant/ like future while kissu is going strong, with a few hiccups due to some things...
No.2362
>>2357Just remember not to put quantity over quality.
You want people constantly checking on the board for new replies, but you don't want the board to get so bad that people see the update notification and don't want to refresh
No.2363
Not necessarily an issue, but I wanna be able to upload and embed SWFs, but SWFs are considered an "unknown file type."
No.2364
imageboards are really dry. The most interesting ones are foreign language, but most of the smart euros are bilingual anyways. It might be a better idea to find conventional forums.
>>2363if i make a mistake someone could run a malicious swf on the site. I'd advise using
https://4taba2.net/board/f and linking it back here. I own that site too but it's much slower and I don't touch it as much so less risk.
No.2365
The most active things to talk about in the english sphere is current events, typically repeating the standard /pol/ talking points.
No.2366
>>2364Doesn't really fit anywhere near the same niche from a usability perspective. At any rate, I was hoping you'd be more trusting of your users, but I understand...
No.2367
>>2366From a position of responsibility, I don't trust my ability to handle it so that there won't be potential issues. I'll think about some ways to handle sharing of executable files.
No.2369
>>2366yeah so. I thought about it an I'll make a fileboard.
It will work with every filetype except images, videos and .exe
No.2374
>>2373Maybe I'm blind, but there's no way to add any tags.
Probably because you haven't added any yet, I'm guessing? No.2375
i knocked the board down to reset the numbers and fix a bug.
added the tags
No.2377
>>2369You should put the files on a different subdomain from the main site so it isn't a CSRF vector.
No.2379
the subdomain settings are pretty nice
No.2380
Decided to rangeban the frog guy through NGINX on the banners since he outlived his usefulness as a tester.
I believe the banners project is in a point where I can turn away from it and use it as a tool. There are some other features that can be added like banner voting and perceptual hashing.
Most of the software related things to do now are dry concepts like making the software installable, size issues on polling boards, fixing the file-board reply counter bug and removing some poor python-php integrations i did.
On the side of considering how to best rework vichan, it's trying to get some monetary value out of things.
not sure what to do with 4taba, but I think i'll let it idle until there's another Artanis patch out.
Also need to make a blog so I can write these things ramblings down somewhere more easily ignorable for people who don't care. Maybe put a few view/click based ads on it.
However, I'm trending more towards a front-end rework that fixes visually unsettling aspects in both the HTML and yotsuba, dark and kissu themes.
I'm thinking that even there all the frontend could be done using a multipage React application and would look cleaner, run faster(so much bloat JS, and require the server to do less keeping growth costs down
now that I think about it really, that is the biggest issue vichan has right now....
since everyone has used 4chanx i doubt anyone's opposed to using javascript to render websites.
I think that's for the best and will make the php code much more focused in it's objective.
PHP server will prioritize in API delivery of information and processing requests while the scripts focus on the display.
This idea also gives the software the ability to expand towards socket driven updates and listeners.
No.2383
>>>/poll/ functions a bit better now
No.2384
put up spam block for illegal spam. wanted it to be captcha link but seems that's not set up yet.
No.2385
This is a release of what's running on the site.
I could install it and set up the features. I didn't try an upgrade, but if anyone is going to upgrade it then they probably know what the installer does anyways
https://github.com/ECHibiki/Kissu/releases No.2395
I would recommend asking Github support to remove the "forked from vichan-devel/vichan" status. The way Github operates, that should only be used if you are making pull requests rather than starting a true fork. First issue is that if an upstream author does something Github disapproves of, they will not only remove the original repository, but all the forks of it, without notifying anyone but the owner of the original repository. This happened when Github got offended by the name of "WebM for Retards." Another issue is that the code of forks isn't searchable:
https://github.com/ECHibiki/Kissu/search?type=Code No.2396
>>2395I see. It is Microsoft now so it hardly seems to be a shocker.
The searching I found wierd because vichan is a fork as well but I used search extensively.
I'll look into what can be done. It's not like I've actually gotten anything special off of the forked status.
No.2398
It seems I can manually do this to issues
https://help.github.com/en/github/managing-your-work-on-github/transferring-an-issue-to-another-repositoryI'm not really sure about tags/releases though
https://github.com/ECHibiki/test/releasesit's only storing tinyboard's tags. Not even my original tags from banners displays
Though any links to the project would go dead if it were to be nuked so probably would be better to find where to ask for the connection to be severed.
No.2400
>>2398Here it is:
https://help.github.com/en/github/setting-up-and-managing-your-github-profile/why-are-my-contributions-not-showing-up-on-my-profile#commit-was-made-in-a-fork>To detach the fork and turn it into a standalone repository on GitHub, contact GitHub Support or GitHub Premium Support. If the fork has forks of its own, let support know if the forks should move with your repository into a new network or remain in the current network. No.2426
Settings change suggestion: Make it possible for non-mods to see bumplocked threads so that bumplocking can be used as a moderation tool without loss of transparency.
From inc/config.php:
> // View whether a thread has been bumplocked ("-1" to allow non-mods to see too)
> $config['mod']['view_bumplock'] = MOD;
No.2448
>>2400Done. They did it before I had the time to send this message.
>>2426I don't even see this symbol in the mod display. All of the twig usage for users is going to be gone anyways.
No.2449
Decided to make some paper documentation for the post.php flow just for posts So I know everything it does
looks like I'll need to download a UML documentation program because I don't have enough paper
No.2450
It's likely 20-40 tasks to get the posting routine working under a new system. This isn't counting front end or theme integration into a full API. Also not counting polls or deleting, though I assume if it's documented out well it should take less time.
Tomorrow I'll start cutting things away from the existing methods and ensure it still adds to the DB(About time the code gets sone tests), then later see about how to make the JSON API conform to modern standards.
https://en.m.wikipedia.org/wiki/Representational_state_transfer No.2451
>>2450>how to make the JSON API conform to modern standards.What's the problem with it?
No.2452
What I'd like to do is load the entire board in one shot and have internal board navigation be done through a single page application and improving the API will help a lot in that sense. This is basically what I mean by modernization.
When using an API such as Google's there's much more flexibility in the type of data that can be sent out. If I just wanted the post numbers of every thread I'd be able to specify it. I'm wondering if under this current system vichan wastes both client and server time to give useless data? Having a Get.php for example, would it be a huge timesave or just a memory hog.
Current system might not be bad, but having a get.php which loads all information from a prebuilt board.json gives much more flexibility in expanding the front end. For example, having the home page be created through API would require a complex request, but the php could just generate a json file specifically for it.
This is basically the main thing on my mind. At this point I just want to have to program switch to delivering API only.
No.2453
each thread is this much information:
http://json.parser.online.fr/
{"no":24101,"com":"Koisuru Asteroid, new Railgun and plenty other decent shows. Another good season of anime to start off the year.","name":"Anonymous","time":1578760653,"omitted_posts":138,"omitted_images":59,"replies":143,"images":5,"sticky":0,"locked":0,"cyclical":"0","last_modified":1584647861,"tn_h":143,"tn_w":255,"h":1080,"w":1920,"fsize":1036470,"filename":"[HorribleSubs] Ishuzoku Reviewers - 01 [1080p].mkv_snapshot_16.07_[2020.01.11_16.26.47]","ext":".jpg","tim":"1578760653081","md5":"iIMtZtkg85xSB2lXvOL+mw==","bumplimit":0,"imagelimit":0,"resto":0,"last_replies":[{"no":31046,"resto":24101,"com":"I've decided I'm going to marathon Ishuzoku to catch up to it. Is Judas still the best choice? AB blocks them so I'm kind of curious","name":"Anonymous","time":1584302331,"sticky":0,"locked":0,"cyclical":"0","last_modified":1584302331,"tn_h":98,"tn_w":175,"h":1080,"w":1920,"fsize":133164,"filename":"[HorribleSubs] Enen no Shouboutai - 12 [1080p].mkv_snapshot_17.07_[2019.10.11_14.30.43]","ext":".jpg","tim":"1584302331586","md5":"iLJ0HzqcY12p4A6gmJLvPg=="},{"no":31054,"resto":24101,"com":"<a onclick=\"return highlightReply('31046', event);\" href=\"\/qa\/res\/24101#31046\">>>31046<\/a><br\/>AB blocks Judas since the majority of his releases are just reencodes. For Ishuzoku it's a real release, even Nyaa acknowledges it.","name":"Anonymous","time":1584304037,"sticky":0,"locked":0,"cyclical":"0","last_modified":1584304037,"tn_h":79,"tn_w":175,"h":652,"w":1437,"fsize":173294,"filename":"9e7028fb1c","ext":".png","tim":"1584304037246","md5":"z\/9BQUhzQ2KMYJXcXyr1+A=="},{"no":31056,"resto":24101,"com":"<a onclick=\"return highlightReply('31054', event);\" href=\"\/qa\/res\/24101#31054\">>>31054<\/a><br\/>Judas it is then. Thanks.","name":"Anonymous","time":1584304341,"sticky":0,"locked":0,"cyclical":"0","last_modified":1584304341,"tn_h":98,"tn_w":175,"h":1080,"w":1920,"fsize":185741,"filename":"[Okay-Subs] Ishuzoku Reviewers - 02 [677A7A69].mkv_snapshot_21.12_[2020.01.18_17.31.40]","ext":".jpg","tim":"1584304341288","md5":"qohQGffq93\/aIQMRKWPqHw=="},{"no":31805,"resto":24101,"com":"<a onclick=\"return highlightReply('31056', event);\" href=\"\/qa\/res\/24101#31056\">>>31056<\/a><br\/>Really love Meidri, and Crim. The two of them have got to be my favorite characters to come out of the show, for which most of the characters are already pretty good.<br\/><br\/>Really in all so far this series has pushed what's allowed to air to the limit and been pretty creative\/entertaining in the process. I really hope it inspires others to explore spicing things up in their stories.","name":"Anonymous","time":1584608526,"sticky":0,"locked":0,"cyclical":"0","last_modified":1584608526,"tn_h":98,"tn_w":175,"h":1080,"w":1920,"fsize":742059,"filename":"[Judas] Ishuzoku Reviewers (Interspecies Reviewers) - 09 [UNCENSORED 1080p][HEVC x265 10bit][Eng-Subs].mkv_snapshot_20.22_[2020.03.19_03.51.25]","ext":".jpg","tim":"1584608526157","md5":"UdER3hFd3iFfWbonAiaMVg=="},{"no":31838,"resto":24101,"com":"<a onclick=\"return highlightReply('24683', event);\" href=\"\/qa\/res\/24101#24683\">>>24683<\/a><br\/>Holy hell, this turned out to be such an awful flaming turd. I never really felt much for the weak mc and throughout he acted like a pushover that was just being dragged along with the plot. Hatena herself was such an annoying bitch the whole time, I could barely stand her. The others were mostly OK with Yumemi being the most tolerable of the cast, but that's the best that can be said of any of them. <br\/><br\/>For what started out promising as somewhat of an older type of ecchi comedy it quickly lost any and all charm it opened with. Favoring to scrap the comedy (at least, any attempts after episode 1-2 fell flat) and focus on a more serious plot, for which the stakes never really are made too clear or feel engaging. It's as though someone wrote out a crappy harem plot turned it into a series, but forgot to add any of the redeeming aspects other harems have to make up for it. That aside, the horrendous production didn't do it any favors, as the studio seems to have blown their budget on the first episode leaving only scraps for the rest. <br\/><br\/>I'm extremely disappointed with how it turned out and wish I'd never wasted my time on it.","name":"Anonymous","time":1584647861,"sticky":0,"locked":0,"cyclical":"0","last_modified":1584647861,"tn_h":98,"tn_w":175,"h":720,"w":1280,"fsize":418625,"filename":"hurrrrr","ext":".jpg","tim":"1584647861028","md5":"cMctsZy1lnbJ8IDjy7oSXQ=="}]}
Theres a lot of waste.
Each thread:
has multiple definitions of time
uses an md5 hash when hash filtering could be done entirely on client side(kissu does not check for duplicates even)
uses a last modified field that is irrelevant when you're explicitly given all information about the file already
locked, sticky and cyclical could be compressed into a single field representing a binary number
bumplimit and imagelimit could be compressed into a single binary number
the resto attribute is pointless since the parent is an unnamed container
Each reply:
is getting a locked, sticky, cyclical property wasting space.
The Resto is pointless considering it's the parent element
multiple definitions of time
md5's lack of usefulness
if someone wanted those fields a get.php would allow them to access it, but the standard use of the catalog.json should not have so much wasted space when it's going to be regularly used.
No.2454
These changes cut the size
{"no":24101,"com":"Koisuru Asteroid, new Railgun and plenty other decent shows. Another good season of anime to start off the year.","name":"Anonymous","time":1578760653,"omitted_posts":138,"omitted_images":59,"replies":143,"images":5,"modprops":111,"last_modified":1584647861,"tn_h":143,"tn_w":255,"h":1080,"w":1920,"fsize":1036470,"filename":"[HorribleSubs] Ishuzoku Reviewers - 01 [1080p].mkv_snapshot_16.07_[2020.01.11_16.26.47]","ext":".jpg","limits":11,"last_replies":[{"no":31046,"com":"I've decided I'm going to marathon Ishuzoku to catch up to it. Is Judas still the best choice? AB blocks them so I'm kind of curious","name":"Anonymous","time":1584302331,"last_modified":1584302331,"tn_h":98,"tn_w":175,"h":1080,"w":1920,"fsize":133164,"filename":"[HorribleSubs] Enen no Shouboutai - 12 [1080p].mkv_snapshot_17.07_[2019.10.11_14.30.43]","ext":".jpg"},{"no":31054,"com":"<a onclick=\"return highlightReply('31046', event);\" href=\"\/qa\/res\/24101#31046\">>>31046<\/a><br\/>AB blocks Judas since the majority of his releases are just reencodes. For Ishuzoku it's a real release, even Nyaa acknowledges it.","name":"Anonymous","time":1584304037,"last_modified":1584304037,"tn_h":79,"tn_w":175,"h":652,"w":1437,"fsize":173294,"filename":"9e7028fb1c","ext":".png"},{"no":31056,"com":"<a onclick=\"return highlightReply('31054', event);\" href=\"\/qa\/res\/24101#31054\">>>31054<\/a><br\/>Judas it is then. Thanks.","name":"Anonymous","time":1584304341,"last_modified":1584304341,"tn_h":98,"tn_w":175,"h":1080,"w":1920,"fsize":185741,"filename":"[Okay-Subs] Ishuzoku Reviewers - 02 [677A7A69].mkv_snapshot_21.12_[2020.01.18_17.31.40]","ext":".jpg"},{"no":31805,"resto":24101,"com":"<a onclick=\"return highlightReply('31056', event);\" href=\"\/qa\/res\/24101#31056\">>>31056<\/a><br\/>Really love Meidri, and Crim. The two of them have got to be my favorite characters to come out of the show, for which most of the characters are already pretty good.<br\/><br\/>Really in all so far this series has pushed what's allowed to air to the limit and been pretty creative\/entertaining in the process. I really hope it inspires others to explore spicing things up in their stories.","name":"Anonymous","time":1584608526,"last_modified":1584608526,"tn_h":98,"tn_w":175,"h":1080,"w":1920,"fsize":742059,"filename":"[Judas] Ishuzoku Reviewers (Interspecies Reviewers) - 09 [UNCENSORED 1080p][HEVC x265 10bit][Eng-Subs].mkv_snapshot_20.22_[2020.03.19_03.51.25]","ext":".jpg"},{"no":31838,"resto":24101,"com":"<a onclick=\"return highlightReply('24683', event);\" href=\"\/qa\/res\/24101#24683\">>>24683<\/a><br\/>Holy hell, this turned out to be such an awful flaming turd. I never really felt much for the weak mc and throughout he acted like a pushover that was just being dragged along with the plot. Hatena herself was such an annoying bitch the whole time, I could barely stand her. The others were mostly OK with Yumemi being the most tolerable of the cast, but that's the best that can be said of any of them. <br\/><br\/>For what started out promising as somewhat of an older type of ecchi comedy it quickly lost any and all charm it opened with. Favoring to scrap the comedy (at least, any attempts after episode 1-2 fell flat) and focus on a more serious plot, for which the stakes never really are made too clear or feel engaging. It's as though someone wrote out a crappy harem plot turned it into a series, but forgot to add any of the redeeming aspects other harems have to make up for it. That aside, the horrendous production didn't do it any favors, as the studio seems to have blown their budget on the first episode leaving only scraps for the rest. <br\/><br\/>I'm extremely disappointed with how it turned out and wish I'd never wasted my time on it.","name":"Anonymous","time":1584647861,"last_modified":1584647861,"tn_h":98,"tn_w":175,"h":720,"w":1280,"fsize":418625,"filename":"hurrrrr","ext":".jpg"}]}
These changes cut 0.59 kb per thread.
In the existing catalog.json it's 314kb, meaning in 150 threads is a reduction of 88kb(28%)
The browser spends 96ms on server wait and 97ms on server download(196ms for all activities). My ping is 43ms to the server so it's spending 110ms on download and upload. so potentially I could see upload+download dropped to 79ms, or 165ms round trip on my internet. A 31ms savings.
As a comparison, banners.kissu is written in the same style as what I plan to do on the main site. this takes 31ms to compile and display the first component so the reduction gives me a free pass to compile a bunch of javascript.
These are later optimizations that might be done
No.2455
>>2453>uses an md5 hash when hash filtering could be done entirely on client side(kissu does not check for duplicates even)If you remove that hash, the only way to do hash filtering client side would be to download every image and compute its hash. Rather than remove it, I would suggest putting it into the HTML as well (like 4chan does) so that userscripts can filter on MD5 and without downloading the JSON.
>locked, sticky and cyclical could be compressed into a single field representing a binary numberInstead of doing that, you could omit the fields when they're not set to 1. (This is the way it works on 4chan; I don't know why vichan includes the fields on every thread.) That way, you don't break compatibility.
>bumplimit and imagelimit could be compressed into a single binary numberThis you could handle the same way. For whatever reason, 4chan does include these on every thread (at least in the catalog.json file I checked), but the spec says they can be omitted:
https://github.com/4chan/4chan-API/blob/master/pages/Threads.md>has multiple definitions of timeThe "tim" attribute really shouldn't be thought of as time but as part of the URL of the image, which happens to be a timestamp. It's kind of redundant, but removing it will definitely break compatibility with multi-site clients, and will limit future flexibility because you won't be able to use image URLs that aren't timestamps.
>uses a last modified field that is irrelevant when you're explicitly given all information about the file already>the resto attribute is pointless since the parent is an unnamed containerThese ones may actually be useless, at least in the thread JSON. In threads.json and catalog.json, last_modified is still useful, and it may have been left in the thread JSON because nobody bothered to remove it. You should be careful of removing them due to compatibility concerns, though. 4chan X seems to use resto, although it could be fixed to not depend on it. I haven't checked what Kuroba (somebody patched it to work on kissu >>2011) or Overchan use.
I would be cautious about removing things from the API just to save a few bytes. This is not just something 4chan and Kissu use; it's become a de facto standard.
No.2456
>>2452>What I'd like to do is load the entire board in one shot and have internal board navigation be done through a single page applicationThis used to be in 4chan X and I removed it because it was a pain to maintain. Remember that you're not just removing the old posts and adding the new ones when you navigate. You also have to update the post form so it posts to the right place. If there are any other differences between the post forms between the boards, you have to update / replace them. You have to stop and start thread updaters. And probably lots of other little things I'm not thinking of.
It will make it harder on userscripts, too. Some userscripts are written to just parse the page once and don't consider updates. They should, but many don't. Even userscripts that can deal with updates will have to have extra logic added to handle the mode changes between index and thread, and changes between boards.
No.2457
One thing I did notice about the JSON API is that it's not gzip compressed. There's room to save bandwidth there.
No.2458
>>2456The API changes are a bit of an afterthought that is just speculation. Optimizing before anything's been written isn't good planning.
A get.php being used for themes and new .json files for existing improvements might be a better way to do it. Maintain functionality, but also get the desired outcome.
I don't know why it's not getting picked up as a gzip because it's being updated.
https://puu.sh/FmBSz/0807f42807.pnghttps://puu.sh/FmBT7/1424a46173.pnghow do you check for this?
Filenames could be changed to a different standard than time. Potentially be an md5 value since an OS will easily tell you the time modified if needed. The standard of using time as base filename in image doesn't seem useful, I don't think it's used anywhere. "tim":"iIMtZtkg85xSB2l
XvOL+mw==", it doesn't make sense, but it doesn't change the properties. Making the change seems kind of pointless in this case though.
React is built to handle lots of small changes. It's just a matter of getting the data to clients. Based on what you say it's probably a better idea to gradually convert Twig templates into React components only phasing out Twig when it's confirmed to be unnecessary.
UserScripts should be modified to suit the shifts in paradigms of industry, though I'll see about what comes up when changes get made to resolve issues with popular features. But it's that the front end is a script inspired by 4chanX so it will likely have to give off events much like yours for something to communicate with it... But I guess this barrier isn't a bad thing since it should kill off low effort spam by design, because just as low effort userscripts can't work, neither can low effort bots.
Archive.org is broken, but Archive.is works with the framework so as long as there is a competent alternative around to the things people use then I won't worry.
No.2459
>>2458oh ya, I turned it off from nginx to test why the caching isn't behaving right.
No.2460
works very well with .is from the looks of it
https://archive.is/IJulm No.2461
>>2459That must have been it. The gzipping of JSON is working when I test it now. And the testing was just curl with -H 'Accept-Encoding: gzip'
Are you considering having the site not load at all unless the user has Javascript enabled? I expect some users would not appreciate that.
No.2462
>>2461banners.kissu.moe is full JavaScript React and it's been successful.
No.2463
I think it's the best way to run a large website on a cheap hosting plan. The offloading of html generation onto the users is their way of paying the admin without doing anything because your computer is lessening the load on the servers, and you don't need to pay as much to upgrade. So long as it isn't impacting them in performance.
I guess the theme of this fork and my idea here is `how to make a highly active website on just one cpu core and 20gb of space`.
Also that 4taba exists for those people.
No.2464
The welcome message seems to be popping up on every page in kissu mobile
No.2465
dammit...
No.2466
This JavaScript only approach also helps people with limited internet as settings can turn off images and do direct modifications. I wouldn't want to bow to zealots if the advantages outweigh negatives.
No.2467
That being said, the user advantage the approach has is in dynamic generation of threads and replies so if I can't get this to be at an acceptable standard and full featured then the idea is a bust. But yes, essentially 4chanX is a better way to view imageboards than what vichan or lynx has come up with. It should be default, in React with TypeScript.
So I'll set up the reply bodies to be dynamically generated for now. If I can get the loading to be unnoticeable I'll go to the next stage of expanding it to page generation. After that point advantages are mainly my own.
No.2469
>feedback thread
I love banners I love the banners these banners are great I love them thank you whoever makes them I love you and them.
No.2470
Thoughts about the two political banners?
ps: did jacno remove his textboard banner or was that deleted?
No.2471
>>2470Knowing political philosophy isn't a bad thing and the two banners in question neither have Stalin, Mao, Hitler, Musolini and other criminals who fly said banners so it's non offensive use of offensive. I suppose personal filtering could be a thing, but it will come after I've gotten dynamic replies/op set up.
I've only removed the GNFOS banner(s) since the site's dead now.
No.2472
I haven't looked at how the threadwatcher maintains cross site storage, but can a website script add to it?
No.2473
and is it possible to get settings from 4chanX?
No.2474
>>>/poll/138
uncertain of best choice in an issue so polling it
No.2481
>>2472>>2473It may be possible in some circumstances but there isn't any intentional API for that. What's the use case?
No.2483
well, maybe it's possible to have 4chanx run when the website says it's ok?
I need to get the threadwatcher functionality onto a dynamically generated reactjs page. I can modify the script to work with the redesign, but I need to tell it to wait.
No.2484
I just noticed that we have an /f/ board now. One thing that nearly every file board should support is when downloading a file, the default filename should be the one it was submitted with instead of the unix timestamp. This is mostly because it's nearly impossible to provide thumbnails for swf or txt files within a filepicker, so having human readable file names is a must. Please do enable it at some point when you have the time, thanks!
No.2485
>>2484another very minor thing: tags aren't displayed at all when you open a thread.
thirdly there doesn't seem to be a limit to the subject line's newlines (and possibly the name field) when shown on the board page. This could become annoying if someone decides to 'WWWWW' post, where they just put the maximum allowed number of Ws in name and subject field. This happened briefly on 4/f/ where people were getting ~6 lines of Ws before bans were eventually handed out and dev fixed that problem. Commemoration flash here: http://swfchan.com/31/150217/?we_built_this.swf
(speaking of amusing bugs on 4/f/, it was in fact possible to post files within threads until partway into 2016 because all the software did was remove the html button for attaching a file and not actually refusing one for reply messages)
No.2486
vichan's fileboard stuff is pretty primitive. It's just a reskinned imageboard. It didn't even have a way to count replies other than a hacky workaround. I think I can add this in pretty easily. How does 4chan handle duplicates for consistency sake?
Other things though... I'm pretty sure at this point in time that changes and new additions to the software are going to be predated by a rewrite in Symfony that guts many vichan features. And this gutting is going to be predated by the rewrite of front end with the first part released at start of April.
I need to do a few projects in symfony first so if you've got any ideas of that then have at it. The banners were done in Laravel as a component of learning ReactJS for example. Maybe a booru software I can integrate into the site, idk
No.2487
Ah, nvm on the duplicate part. kissu doesn't have duplicate checking enabled by default so I have to set some flags and limit it to 1 page
No.2492
>>2486>vichan's fileboard stuff is pretty primitive. It's just a reskinned imageboard. It didn't even have a way to count replies other than a hacky workaround.Yeah it shows on most fileboards that they usually aren't given the same amount of love that the IBs are. IIRC 4chan's /f/ was on a separate server for the longest time and most of the April fools jokes never affect the board. It still to this day uses the prune the oldest thread first.
>How does 4chan handle duplicates for consistency sake?You can't post a file that matches the same md5 of a file that is currently up nor could you upload one that has the same filename while one already exists in the current 30 threads. IIRC there also used to be a restriction until fairly recently of not being able to post a file whose md5 matches a file posted within the past week.
>I need to do a few projects in symfony first so if you've got any ideas of that then have at it. The banners were done in Laravel as a component of learning ReactJS for example. Maybe a booru software I can integrate into the site, idkhmm I'm unfamiliar with most of that terminology, good luck! I will note that I didn't really enjoy seeing that one political banner about marxism but ... as long as there aren't too many jarring banners i think it's fine since you can just scroll past them.
>Ah, nvm on the duplicate part. kissu doesn't have duplicate checking enabled by default so I have to set some flags and limit it to 1 pageDon't feel that you _have_ to imitate everything that 4/f/ does; it's just that board has been around so long that there's some fairly practical measure that are implemented which nearly every fileboard should emulate: preserving filenames being one of them. It would be quite a different board if say you couldn't reply to threads with a file or you forced it all to one page (i guess you already did that change though).
No.2493
>>2492ha,, well the two have been up long enough that I can see about them again since the nazi one is pretty jarring
No.2496
>>2483I'm not very familiar with ReactJS. What happens if it doesn't wait?
But putting in a wait would probably be possible if there's some detectable signal in the HTML loaded so far indicating a wait will be necessary.
No.2497
>>2496It's the same concept as 4chanX.
React constructs a virtual DOM in memory and then places it onto the page asynchronously through the rendering of React components. After placed in the true DOM react makes as little changes as possible to existing elements. Since it's generated after the true DOM has done a first load and runs the <script> to start the process userscripts will fail to keep track of what's happening unless they wait for rendering to complete or have a TreeWalker watching for updates.
No.2498
>>2497Yeah, there will need to be a delay before it tries to process posts, that I understand. What I'll probably do is attach a MutationObserver to the body to detect when the needed element is added and then remove the observer. There's a $.onExists function to do this already, used for lots of other cases. Not sure what that has to do with the thread watcher specifically, though. Do you have a page I can test on?
No.2499
>>2498Thread watcher is the thing that's most valuable and can't be replicated.
It's on localhost right now, I'll see what I can move. I should have a sample site anyways. If not It'll be live in 5 days
No.2502
https://demo.verniy.ca/b/I don't think much should change except I'll eventually remove the first div in the postform
No.2504
>>2502Are the two <div>s wrapped around the list of threads in the index intentional? They're not there in vichan.
No.2505
>>2504Or is this what you meant by
>>2502 ? When I read that I interpreted "post form" to mean the form for posting rather than form[name="postcontrol
s"]. The way 4chan X is currently written, it expects the threads to be direct descendants of form[name="postcontrol
s"]. Without the <div>s, it might work fairly well without any further changes. If you did intend the <div>s to be there, it would probably be a good idea to give them a class name. As for the thread watcher, it shows up when I click the button in the header, although since the posts aren't being parsed, the watch thread buttons aren't inserted.
No.2506
>>2505React has it so that every main component needs to be wrapped in a container element, but yes I can give them properties. I wasn't ready yet to fully replace the post form and thought I'd hold off until I was ready to replace the thread creation form, but I guess if that's required I'll do it and update the demo.
I should name it to keep track of which divs are which. The image shows how it's being displayed at the moment
in paged mode there will be one extra div to contain the internals of the post form.
No.2507
>>2506my comments are outdated
No.2508
>>2506I don't think the post form (as in the form for posting) is very relevant to getting 4chan X working. form[name="postcontrol
s"] is the form for deleting and other stuff, not for posting. Adding a class or ID to the <div> that's the direct parent of the threads would help, though. Is it guaranteed to have all the threads and posts in it when it is inserted?
No.2509
>>2508yeah, I can give the thread container div an ID. It will have only the current page's threads in it. But later iterations perhaps will allow for custom number of threads/posts per page and other strange features like that. But displayed content shouldn't be altered unless expansion or links are pressed.
In the case of a catalog I'll be using react-router and I'm not really sure how the userscript behave with that. I know for certain it activates on every time the url changes.
No.2510
>>2508I meant to say threadform. I wonder why I named the component class PostForm...
No.2511
>>2509>It will have only the current page's threads in it. But later iterations perhaps will allow for custom number of threads/posts per page and other strange features like that. But displayed content shouldn't be altered unless expansion or links are pressed.It should be able to handle at least some of that. The reason I asked was primary to do with the thread view. I haven't been able to test it yet, but one concern was that 4chan X might see the blank page and reset things like the last read post to zero. So there needs to be a clear signal that all existing posts have been loaded, and the <div> with that ID not being present until all posts have been loaded would work.
Another check: Will the <div> have the ID before it's inserted into the DOM? If not, there could be a race condition where sometimes it would notice the <div> added and ignore it because it didn't have the correct ID.
>>2510Threadform sounds confusing as well; without context I would take that as the "form to create threads."
No.2512
>>>/qa/13643
By the way, does Kissu have a convenient way of restoring threads from the archive if someone manages to get past the captcha and spam wipe the board?
No.2513
>>2512And on this same topic, some other nice contingency plans to have would be restoring from /trans/ if a moderator goes rogue (or someone guesses his password), and restoring from an external backup in case someone with administrative privileges (or who obtains those privileges by security breach) goes rogue or the host decides to shut down Kissu without notice.
And on the topic of contingency plans, I really like what smuglo.li has done. They have an announcement saying
>The current fallback points for this site can now be found here. Please save the file locally in case the site becomes inaccessible.where "here" is a link to
https://smuglo.li/fallback.txt which says:
>Fallback map v1.1>>Primary Board: https://smuglo.li/a/>Darknet: http://bhm5koavobq353j54qichcvzr6uhtri6x4bjjy4xkybgvxkzuslzcqid.onion/a/ The Hidden Service will come up again under the same address even if we lose the server.>In case access to the primary board is turned off because of journalists: https://notso.smuglo.li/a/ (Thanks to Kohlchan for the idea.)>In case of domain loss: https://smug.nepu.moe/a/ >In case of server loss: Wait a few hours, we have daily full disk backups! Then start this list from the top.>Information during downtime can be found on #8/a/ on Rizon IRC. This should be joined as soon as a problem starts.>If all else fails: https://shitposter.club/nepfag will post the new URL.>>If things go so pear-shaped that none of the above is effective, don't forget that /a/ is a community, not a website. Continue looking for places where /a/nons seem to be congregating, and try to work out via discussion what the best place to set up permanently is. Don't give up on finding each other, and trust that other anons are also working to the same goal.Granted having been 8chan refugees they have more reason to worry about their site going down than us, but we shouldn't assume it can't happen here. I doubt a darknet version would be much use given our policy on proxy blocking, but the daily backups and the alternate domain (presumably using a different registrar) seem like good ideas, as is posting the contingency plan somewhere visible.
No.2514
>>2511It all happens asynchronously, but the intention was that major view changes are accompanied by a URL change. componentDidMount gets called after render. I'm currently putting the calls to json inside that because reasons(link bellow) but it could be done by an upwards signal from each of the threads and keeping track of how many are supposed to be rendered.
Doesn't the second line contradict the first? How can I set the ID on condition of all posts loaded but have ID already prepared?
Delete form I guess, but it's more importantly the thread container. I guess the internal divs which helps the naming here.
Not yet, it wasn't included in NPFChan cherypicks afaik but I never installed it to check. I could see if it had it for quickfix.
The first part of this already exists. External backup exists from the server host "Backup Date Action
2020-03-22 05:05:06 Restore"
that shouldn't go away under any condition and is free.
>In case access to the primary board is turned off because of journalists: Sounds like a pointless plan. This site isn't for picking fights with governments.
No.2516
It looks like working with the react engine has certain difficulties with timing against external events. I imagine there's a feature for this though.. it's been in the works for almost a decade
https://blog.jakoblind.no/ajax-componentdidmount-vs-componentwillmount/ No.2518
>>2514>Doesn't the second line contradict the first? How can I set the ID on condition of all posts loaded but have ID already prepared?Well, I was hoping that the <div> would be first populated and then inserted into the DOM. That would be the most efficient way to do it anyway; otherwise you trigger needless reflows. In that case, the signal that it is okay to parse posts would be simply the insertion of that <div> into the document, triggering a MutationObserver.
So far, I'm only thinking of the initial page load and not how it will work for JSON-based navigation.
>>2517Good to hear.
No.2519
>>2518I'm not certain of React's Virtual DOM rendering, it's a blackbox. However I don't think it will cause that problem.
I think based on quantity of information loaded it's going to vary between gradually placing things into the true DOM over the span of some browser frames or instantaneous if quantities are light. It's instantaneous on my local version. This isn't something that I would have control over. The best I can do is detect when every post has executed it's
componentDidRender()https://github.com/acdlite/react-fiber-architecture, is their way to make pages for heavy content still not slow down user experience.
Yeah, I'm talking about the same thing as you. Catalog will be on a seperate URL in any case and removes them from the true DOM.
No.2520
I'm not going to put the altered version on the main boards as yet, I'll probably confine it to everything not /qa/ until it's working as intended. There will be a chance to see how it's behaving under a more heavy load.
No.2521
>>2519Could you have
componentDidRender() fire a
CustomEvent to tell userscripts the rendering is finished?
No.2523
what prevents doing it through componentDid__ is that XHR has to be(or is at least suggested in official docs) done through componentDidMount
No.2524
So you would get multiple false firing(until the final thread is loaded) if I were to put it in componentdidmount and because each component is async they don't have a way to communicate between each other without some sort of shared logic.
Placing a component into
render(){
<div><Thread /></div>
}
means that Thread isn't associated with the caller anymore. It's sent out the signal to make the thread therefore it's mounted.
I'm not an expert with this framework yet. I'm kind of guessing.
No.2526
>>2524render(){
<div><Thread /></div>;
}
doesn't wait for the thread to be done
No.2527
I'll get the events tomorrow then
https://demo.verniy.ca/b/ No.2528
I was looking at the demo site some more. I noticed an incompatibility with vichan: The thread container element IDs on the demo site are of the form "thread2" whereas vichan uses "thread_2".
Another thing: On the index view you have a
<div id="page-1-container" class="page-container">containing all the threads which contains an
<input name="board" value="b" type="hidden">element followed by all the threads, whereas on the thread view, the thread is a direct descendant of the form and the hidden board input element is inside the thread. It seems to me that this makes the index and thread views more inconsistent than they need to be. If you changed the thread view to match the way you've done things in the index, with a somewhat superfluous <div id=something> wrapped around the one thread, it might make it easier to use the same Javascript and CSS (including users' custom CSS) between the index and thread views.
The only reason I mentioned that hidden input element is because of a bit of a hack in 4chan X. Vichan has the practice of caching cross-thread quote previews as hidden partial threads which are prepended to the form. The only way I managed to get 4chan X to distinguish the hidden partial threads from real threads without doing something inefficient like checking whether they had non-zero height was to use the fact that real threads come after that input field and the hidden ones come before it. I could just write some code to turn this hack off on Kissu, but if you do decide to change the thread view to have the same structure as the index view, it would make things easier on me if you could move that input element out of the thread.
No.2529
>>2528i see, moved it over in my local and fixed the id.
No.2530
was reading this thread a few weeks ago
https://balkanchan.ga/lynx/res/98.htmlmentions file storage vs DB storage. I don't think an imageboard should go in the direction of pure file storage(it's more logical to see each aspect as a data object) though it goes along with the general architecture and theme I'm running for here so I'm considering it anyways. hypothetically the server could put all of the json information into memory and serve it out through a /get and be added to by a /post. This way our API begins to resemble a system like Twitter which allow for developers to create applications from Kissu however they need and have all data easily accessible.
I may go this way, but this is a much lower level solution to an imageboard. It opens the door to some of the issues I have with 4taba of memory management, text manipulation, vulnerabilities and lack of libraries/frameworks. I also worry because vichan's moderation system is dense in features and porting that into another language is going to be a major pain.
Honestly, we're kind of stuck with using twig for the mod interface since it relies so heavily on templates and constant DB lookups for information. I don't know if it's even feasable to do 100% API on vichan so anyone who enters into the codebase will need to know the API side really well to make user side modification and the Twig side really well to make mod tool modification.
I believe this is the kind of flaw that we'll run with for French Kissu 7.x until I'm able to write networked C # ++ code taking into account issues of memory management, GC and security.
No.2531
>>2522Just remembered, there's one more thing to wait for. Some userscripts aren't executed until the document finishes loading. So if this all somehow completes before the document finishes loading (document.readyState === "loading"), it should wait for a DOMContentLoaded event.
Another neat feature you could add would be to pass the JSON in the detail of the CustomEvent. This would make userscripts more efficient because they wouldn't have to parse all of that data out of the HTML or reload the JSON to get the same stuff. And for 4chan X, it would solve the MD5 issue I mentioned in
>>2455.
No.2532
>>2530Bear in mind that they're talking about whether to store images in the database or in the file system. Lynxchan stores images in the database by default which was an often questioned design decision from the beginning. The developer only recently added the option to write them to disk instead. So the RAM improvements he talks about apply to going from Lynxchan's strange situation to where we are now, rather than from where we are now to storing the posts on the file system.
There are some imageboard scripts that don't use a database at all. Kareha, though mainly for textboards, can be used for imageboards. In TinyIB a database is optional, but it's significantly more efficient if you use one, which is to be expected given that it's written in PHP.
One place you don't want to be is having people spam your site with child pornography and not having an efficient way to delete it all. 8chan used to be in that position due to the poor design decision in Tinyboard to store each board in a separate database, and it was not pretty. You need to be able to rapidly look up all the files posted by a particular IP, and a database will do that for you.
No.2533
>>2532Yeah. It would require creating your own database solution so you'd be reinventing the wheel for the purpose of better ram usage.
It's kind of dubious for reasons like this and being able to remove things or fix mistakes, but there's redundancy in having both an API and DB, and the redundancy probably doesn't outweigh the benefits. Still, it's just a thought. A NoSQL might be more intuitive.
I know that sync and my other nodejs apps have a high ram overhead, but is it just that?
No.2534
>What happens if Redis runs out of memory?
>Redis will either be killed by the Linux kernel OOM killer, crash with an error, or will start to slow down. With modern operating systems malloc() returning NULL is not common, usually the server will start swapping (if some swap space is configured), and Redis performance will start to degrade, so you'll probably notice there is something wrong.
>Redis has built-in protections allowing the user to set a max limit to memory usage, using the maxmemory option in the configuration file to put a limit to the memory Redis can use. If this limit is reached Redis will start to reply with an error to write commands (but will continue to accept read-only commands), or you can configure it to evict keys when the max memory limit is reached in the case where you are using Redis for caching. use the nosql db redis i still run into the same issues as raw file storage
Man, even a good NoSQL databases still has the issues of memory management
No.2535
>>2531If I were to send out more info through the event it's probably not going to be by default, but will have to enable an option. perhaps send an event to get it.
No.2536
>>2535Yeah, it might be a good idea to leave the finished event with no detail and make the JSON thing a separate event that you have to send an event to get.
No.2537
>>2533https://developer.mongodb.com/how-to/storing-large-objects-and-fileshttps://docs.mongodb.com/manual/core/gridfs/http://nginx.org/en/docs/http/ngx_http_core_module.h
tml#client_body_buffer
_size
I'm no expert on MongoDB, but it says that files are split into 255 kB chunks by default if you use GridFS and can be up to 4 MB otherwise. For comparison, Nginx's default buffer size is 8 or 16 kB depending on platform. That could be part of the difference. And if any of those chunks are cached in memory or have to wait to be garbage collected, that would also contribute. In any case, I wouldn't expect the tradeoffs of storing image contents in a database to be similar to the tradeoffs of storing post text and metadata.
No.2541
- Fires custom event mounted {detail:"mounted"}
I could do a getElementById on the last post when calling this from localhost.
- Fires custom event likely-rendered {detail:"likely-render
ed"} which is just a 60ms timeout after the first signal. I did this just as a failsafe.
https://demo.verniy.ca/b/I'm left with:
* A 4cX style Updater
* Settings to do things through react hooks, refs and local storage
* Put the delete/report by selected into an expandable menu
* Fix deletes which aren't storing password on fresh installs for some reason.
* Preventing vichan from generating posts html
then just making changes before catalog. Should have the first stage done tomorrow
No.2542
>>2541>{detail:"mounted"}It would be safer to omit the detail if you're not going to pass any additional information with it. Some events with details are blocked from being detected by extensions and userscripts, and although a string detail shouldn't cause this, it might if there's a browser bug. The event name is already part of the event object.
>just a 60ms timeout after the first signal. >I did this just as a failsafe.What is this a failsafe for? A 60ms timeout sounds like a hack that would be unsafe for a userscript to depend on.
On another topic, I don't like the idea of having to click on a button to see the filename.
No.2543
>>2542Enabling by default will be doable tomorrow. Weather it's the default configuration or not will depend on if knowing the name of a file is generally useful or not. I tend to think it's just overloading people with information that encorages pointless arguments over file sources.
No.2545
https://demo.verniy.ca/b/Think this will be the final format. The biggest change over the original is toggling on content and options that change your page dynamically. I also added in a 4chanX style updater.
No.2546
accidentally added two ajax.js into the main js file causing double posting.
No.2549
Feel free to complain about anything
No.2550
Check options if you want to customize the page.
Some boards aren't working as intended because I made a last minute optimization to vichan.
No.2552
catalog link from threads is broken ✔
No.2553
my threads still have few replies...
No.2556
>>2301I never used 4chanX, nontheless I can comment on the new features
>the arrowsGreat function, there might be a readability issue from afar, but it has an interesting look. I wish there would be a saucenao option as well. Not a deal breaker since iqdb directs to saucenao.
>reply boxThe white on the quick reply menu is a bit bright, but it stands out, which is good.
>counterA pretty cool idea. could help to have more metrics about the board. It would be interesting if there was an auto refresh for the whole page as well.
>indexbetter than return
That's all I got so far
No.2557
if i make the quick reply box bigger i cant make it smaller after
No.2558
>>2551That flicker is a long running issue on the site. The slow thread load is poor optimization on my part. I need to go over my code again and make it faster.
>>2552I'll look into that.
>>2553+1
>>2555I'll see what else works
↰ ↱ ↲ ↳ ⬐ ⬎ ⬑ ⬏ ↴ ↵
those all box for you I guess?
>>2556reply box was actually an oversight, but it works better.
I agree about more metrics. We can put more features into it.
>>2557can't replicate this on modern firefox
Also seems like counter is given me negative number
No.2560
4chanX's link hover seems to be broken, and there is no highlighting of a post who's link you hovered over
No.2562
>>2559test
>>2558I'm on modern firefox and
>>2557 works fine, also not sure if this is a bug or not but quick reply looks like this
No.2564
>>2560Doesn't work without 4chanX as well.
>>2555Have the exact same problem.
No.2565
>>25604chanX compatibility isn't yet complete. Hover actions don't exist by default so I didn't think of adding them in yet.
No.2567
Oh yeah, clicking on a post link doesn't take me to that post
No.2570
>>2564I'll remove those symbols for
>>2566 if you see the same
>>2558.
>>2563The quick reply box was hacked on top of it without much thought.
>>2567That's an aspect of vichan js and takes some time to work around with how posts are sent into the API.
>>2569>>2568Is not, that shouldn't be a hard add
No.2571
>>2301Jumping between posts is broken on my end. If I click on the reply link it changes the URL but does not jump to the post.
✖,
No.2572
>>2552Yeah, cuz it directs to board/res/catalog instead of board/catalog
No.2573
my eyes are vomiting and the dates are wrong, there arent 31 months in a year verm...
No.2576
sage is not blue!?
No.2577
I don't care for a button hiding filename, image info, etc. Could I fix that myself with user CSS?
No.2578
Oh, only proper sage is blue. The other ones only get underlined.
No.2579
>>2577Enable it in the options on the right hand side
No.2581
>>2579Could you put that all on one line like it used to be? If people have it on by default it may look a bit bad
No.2582
is there a difference between parenthesis updates and brackets updates? the latter doesn't go away from the tab's name
>>2576>https://kissu.moe/qa/res/sageinteresting options
>>2573death to american time formats, although the month is wrong
No.2583
also noko in qr outside of thread test
No.2585
forgot completely about noko, i was up until 0830
No.2587
noko in thread test
No.2588
you broke it vermin...
No.2589
>>2586no u have enough
think of unfree african children
No.2590
>>2589they need liberation
No.2591
also read replies in the tab not updating
No.2592
>>>/poll/337
testing crosslinks
No.2593
>>2590except those from liberia
No.2594
>>2592thread needs to be posted in for them to appear
No.2595
>>2570> I'll remove those symbols if you see the sameYeah, it's the same for me.
No.2598
>>2596CSS oversight.
>>2595Decided I'll just go with solid triangles. It's more visually descriptive.
I'll move some of the minor changes over
No.2601
>>2599that's on the bottom of the page, the moderation button
No.2602
>>2599That's not happening on my end
can you be more specific of what your system is
No.2606
>>2604yeah, it'll be a bit different. Still will have the /catalog name, but will function the same way
No.2607
Essentially this is the same kind of way that I made banners.kissu. if you go from / to /all it's not actually loading a new page
No.2610
>>2605it's sometiems present sometiems not dunno why
No.2611
>>2610because sticking the old JS ontop of the new one was done with a hack. I can actually make it work for legit. Just give me some time
No.2612
>>2610Because your browser has a lot of inconsistencies with mine apparently.
No.2613
Not sure if you should keep this a whole day, there's some real damning bugs in this right now that you may want to iron out so you can have a nice april fools whatever
No.2614
Hm, wonder if you should make it show on the counter when the last reply by sage was too
No.2615
Why aren't images below the "post line" that has the name, date, and post number?
No.2617
>>2615uncertain what you mean
No.2619
The "collapse" feature is kinda broken. Not really sure how it "should" look, but it certainly doesn't feel right.
>>2617Rather than images being underneath "Anonymous XX/XX/XX No. XXXXX," they're now offsetting that line.
No.2620
>>2619I think that's a concious choice on his part, but I think it looks bad
No.2621
it's how the OP is, do you think the OP is bad?
No.2622
>>2621OP is different from the rest of the posts by default so it's an exception, it just looks wrong in regular posts
No.2623
>>2620Eh. It just doesn't feel right, especially since pic related can now happen where the image is placed on the same line as the "post line," meanwhile the text is underneath both. It just feels
wrong.
No.2624
I am ambivalent about hiding filenames by default
No.2626
not sure if i prefer the old youtube thumbnails or not, they only required a single click, but at the same time the play button was covering part of the thumbnail
No.2627
>>2626Problem with doing it default way by default is that youtube makes page loads hella slow.
>>2619i see what you mean now. It's adjusts on screen sizes so I don't think it's catastrophic, but doesn't seem like good design.
>>2624>>2625I'm not completely happy how the hidding is being done, but I want some of the info hidden. File sizes are pointless info for example. I don't know if filenames are something liked or not. Most of the time it was complaining about where you got an image from as a missaligned gatekeeping strategy.
No.2628
>>2627I think that there is some appreciation of a subtle joke hidden in a filename, even if it is not voiced
No.2629
on the bright side the mod UI is basically impossible to browse the site with now. So you don't have to worry about that...
No.2631
>>2629you should delete that post right now
No.2632
I will not
No.2633
Let me collect the issues I couldn't address right away.
I think noko is the only lost functionality from how it stands right now. Other things like deletes are reduced and stylistic decisions need to be revised.
I believe the problem with noko is it's trying to insert things into the DOM which breaks connection with React's Virtual DOM. In which case I just need to get it not to do that hopefully.
No.2634
oh, and QR form. That was another
No.2638
>>2301I modified a setting for bumplock visibility a while ago and now there's a bug that reappears every time I change a setting
No.2639
>>2637I guess it's fine now?
No.2641
Just fixed it
No.2643
I can't hide threads so I'll have to look at kuso posts in the kuso face for a while.
No.2647
everything is broken
No.2648
another problem is that expanding/closing images no longer adjusts scroll bar
No.2649
>>2647That is not true
Most things are broken
No.2650
>>2648you mean moves scroll bar to center image? I forget how it acted normally
No.2651
>>2650yeah i think, it hangs on the post when you close the image
No.2652
jpg vs jpeg
No.2653
Verm, I just realized you foobared the dates. It's supposed to be April now, not March. I could be wrong, but are you using UTC months? I'm pretty sure those technically start at "month 0."
Also there's no "X units of time ago" upon hovering on the time.
And, pic related.
>>2627>File sizes are pointless infoEh. I'm not so sure about that. For files less than 4MiB, which is the standard, I could care less, but people do tend to upload larger images thanks to the fact that the filesize limit is 100MiB (unless you've changed it). Where it can come in handy is particularly when people upload videos e.g. >>33325 or >>33860. I'd imagine most people wouldn't have their internet be bogged down by downloading a 10 or 20MiB file, but for some, that information can be quite handy. Be it because your internet is terrible, or because you're on mobile and don't want to "waste" your precious data cap.
>>2628I very much agree with this. Although I don't do it very often, I like to rename files to bully people via the filename or otherwise to add emphasis or subtly explain the attached image.
No.2656
File:k.png (235.01 KB,2560x1298)
It's completely broken, nothing is showing.
No.2657
>>2655Hmm. Maybe it's because everything is getting spoilerized by vermin, but the video settings are missing too. Case in point, unspoilering the video I attached in the post above is missing the "loop" button, and is likewise not set to loop by default.
No.2658
>>2656Did you disable JavaScript? I know vermin probably doesn't want to after working so hard, but he really should make a barebones board for those that block it religiously
No.2659
>>2658As in, something that checks if JavaScript os disabled, and if true gives you a different site. If that is even a problem for anyone.
No.2660
>>2656Verm mentioned that's default 4chanX behavior (which it is), but it's definitely pretty distracting. I'm making an educated guess here, but I think this happens because although the page template can load (which is a standard HTML page served via PHP unless Verm has changed the backend significantly), all of the posts themselves still need to be retrieved afterwards. Looking at the network doohickey, it would appear that the thread content is sent as a JSON file, and I'd assume that then gets rendered by one of the other JS files I see.
>>2659I wonder if Anonymous will think to turn on JS to see if that's what's preventing them from seeing posts.
No.2661
that might be a javascript error.
>>2658You can see in the bottom right that there's the style selector. That's done by the native javascript. So something's not compatible or he's gotten a bug no one's encountered.
I may want to add some warnings and try/catch assuming they don't hurt performance too much
No.2662
>>2661Also interesting that the navigation items are showing up as well so it might be an issue in the joke form, but I've refreshed more than anyone else here so...
No.2663
>>2658>>2660>>2661>>2662Well it turned out that the extension I use (dollchan) was conflicting with this. Disabled it and posts showed up.
No.2665
>>2664I see, I'll check what happens with uMatrix enabled and make a fix.
No.2666
>>2665Perhaps I should've put one of those big red circles like on clickbait YouTube thumbnails. The scripts from unpkg.com are getting blocked by default, which causes everything but the threads and replies to load. Allowing them, causes the page to load like normal.
No.2667
it was working perfectly fine though
No.2668
>>2666yeah. Not sure if there's another way other than hosting them locally. want to see if there's a fix
No.2669
>>2668alright, I'm reverting
No.2670
The file info should be widthxheight not heightxwidth.
No.2671
It should at least not be undefinedxundefined
>>2301It'll be active on the other boards for the rest of the day with the joke theme and then only on /b/ until it works fast and has the features required/requested.
As for thing after, I've had requests to make it easier to do imagedumps through a more sophisticated QR form.
I've also had requests to make the catalog more interactive and informative.
There's still a lot of work to do on the page/thread form before I can release it as anything other than as a joke.
No.2672
Image expansion, thread expansion, and quotelink hover are currently not working after the apparent revert.
No.2673
>>2672hold on, i disabled those options let me put them back
No.2674
thanks, seems to be up to date.
No.2675
Putting the button to show file details between the date and time makes it difficult to change the time format without breaking things. Could you move it somewhere else please? Or at least wrap the date and time in elements so they can be easily hidden?
No.2676
What's up with all the critters?
No.2677
hhwahg
No.2678
archive is dead....
No.2679
>>2678as is qr outside of threads
No.2680
^ what's the play button for
No.2681
think it's a remnant of the experimental ui, guess not everything reverted when he switched back
No.2682
>>2679this seems fixed now
No.2683
can't see anything on /poll/ without javascript (don't know if I'll see something with js)
No.2685
Because Twig is busted and full of code using syntax like curly bracket array indexing which PHP is rightfully admitting was a mistake. Twig is Tinyboard's method of building html pages.
It could become broken with any update to PHP. I'd rather the site have a more contemporary solution. JS only allows for me to spend less on server because rendering is offloaded to the client.
As a tradeoff it allows for smooth page transitions and easier development of features and more dynamic pages. So long as I make it not bloated and expensive it's not a problem to most. The framework is something made by FB, it's a very effective solution. If I were to replicate 4chanX in jquery it would take too much time.
I don't want to spend time picking up after mistakes of predecessors. Vichan has always been heavily on the side of scripts. 4taba is an alternative which can be accepted. How are you even using /poll/ without JavaScript? It's rendered with chartJS??
No.2686
Not being able to see anything is probably bug though that someone's already reported
No.2687
>>2685I couldn't vote but I could post without js (haven't tried opening a new poll).
It figures vichan is script heavy being made by Czaks the "ruda kurwa", begging the question why use it in the first place but idk maybe you like fixing his horrible code.
No.2688
>>2687because vichan and tinyboard are the defacto choices for jp spin-offs so consistency between designs was preferred. I think czacks code is probably the best of what's been written for it. Vichan just has so much time poured into it that even if it has fault you can still find something you like in it
it'll be off /poll/ in a few hours after which it will be /b/, expanding to other boards until it's in a 100% complete state to be released on /qa/.
No.2689
But basically the people I talk with the most want the site to go in a direction resembling 4chanX and I believe that kissu needs a unique UI to distinguish itself. It seems like so many people are trying to force the ideal of "an imageboard where you don't need JavaScript" that I'm going to go the complete opposite direction because I feel that most people see the benefits of JS
No.2690
what is ruda kurwa?
No.2691
>>2690Czaks ruda kurwa is the administrator/creator of vichan. On top of that, he is a well known serpent, thief, manipulator, and all around a shit person, much, much worse than Jim, Littlecar and Josh all combined.
In case you don't know, vichan is a polish imageboard with the levels of cancer exceeding reddit, 4ch and tumblr and whatever you can think of. It's basically facebook with "anonymity" at present point. For one, Czaks is advertising a chan/imageboard derivative called Uczuciopedia on his website, which is a facebook page running on stolen polish chan culture original content and memes and run by highschool normalfag chads. He was invited to a party organised by Lanceq, the creator of Uczuciopedia, on which he (czaks) was insulted and made fun of (he wanted to feel like a highschooler chad one more time </3, rip in peace)
Czaks has a history of undermining privacy of the users of his chan, he has also declared vichan "the polish 4chan", he has fucked up karachan a few times (another polish chan, this one is less cancerous and more of a mix of modern day 8ch and old 4ch /b/) and generally assisted in spreading Polish chan OC on mainstream sites like facebook, for cancerous normalfag youth to use and appropriate.
Pic rel is czaks, as you can notice, he is a ginger and has no soul.
I don't think I'll be able to find you anything in english. And not much in polish, unless I find an archived imageboard page, because the good anons don't blog about chans and don't talk about chans outside of chans (Karachan, for example, tries to keep outsiders out so bad that you need special cookies and adblock lines to get in and browse properly). One fact I recall was that he blew all the server money on drugs, (I think it was cocaine?) the money included ad revenue and donations.
Typing in "czaks ruda kurwa" gets you this:
http://leekyforums.com/thread/5249121/miscellaneous/marcin-czaks-abanowski
ul.html
>Man that destroyed polish chan community. After reviving Vichan in 2012 (before it existed in 2009-2010, but he got doxxed and had lots of pay-on-delivery shit to him so he closed the shop, it also came out he was underage then), he invited all kinds of normal and moralfags to polish chans, causing a major downgrade in quality. He became friends with Jakub "lanceq" Nies?uchowski, founder of Uczuciopedia, facebook group that's the main enemy of polish chans right now, they are whiteknighting all raids and actions, stealing all content that can be stolen (because of them most of our memes are now in all polish middle schools which is fucking annoying) and just being shit. Result of his actions? Since middle 2014 nothing interesting was made or happened on polish chans, every raid or action was whiteknighted or moralfagged into oblivion before it even began and no one is even making OC anymore because he knows it will be on kwejk (polish 9gag) next day. Before, polish chans were places for social outcasts and losers to spend time and do shit with people like them, but currently they are SWARMED by underages and no fun allowed moralfags which are turning the community into what 4chan became after sociology.And regarding github and any kind of coding - czaks is a horrible, horrible programmer. The barely functioning vichan on which (I believe) 8ch is running is a testament to his coding "skill".
No.2692
>>2689Haha, you got me, april fools's right?
No.2693
>>2692......
I suppose it could be that this runs as a script on top of vichan. But I'm not fixing Twig.
(in the case that it breaks again)
>>2691They all look like the same teen
No.2694
>>2693I might do it like this such that there's a way to tell who opts in and who doesn't, but continuing down the line of failed thinking isn't a good choice to me. This might also negate the economic benefits in the approach I prefer
No.2695
>>2691OK, that green text helps me understand the concerns people had in the /poll/ thread. I'm not as versed in the problems that have previously existed. I am a
newfag No.2696
If Twig is the main issue, there are ways to render React components server-side. That would resolve the complaints about mandatory Javascript, and it would speed up load time because users wouldn't have to wait on two network requests, one for the page and one for the JSON.
No.2697
I ran a quick script
curl -s 'https://kissu.moe/qa/threads.json' | jq '.[].threads[].no' | while read -r n; do (echo "$n"; curl -s https://kissu.moe/qa/res/"$n".html > /tmp/t.html; gzip -9 < /tmp/t.html | wc -c; pup '.thread' < /tmp/t.html | gzip -9 | wc -c) | tr '\n' ' '; curl -s https://kissu.moe/qa/res/"$n".json | gzip -9 | wc -c; done | tee /tmp/sizes.txt
to measure the sizes of thread HTML pages, the part of the thread HTML page containing the posts, and thread JSON, assuming maximum gzip compression. These were the results (columns are thread number, total HTML size, posts part of HTML, JSON):
https://pastebin.com/7FuesVuDThe totals are:
1045805 total HTML size
447882 posts HTML size
306512 JSON size
For purposes of saving bandwidth, there could be a lot of savings by having parts of the page other than the posts rendered client-side. A lot of these probably don't change a lot and the scripts to generate them could be shared between pages and cached for long periods. And if you wanted to support non-JS users, perhaps you could give them a link to a posting form on a separate page or load the form in an iframe. (For web.archive.org, posting wouldn't matter.)
No.2698
>>2696yeah, this actually makes more sense because in order to drop twig I also would have to find out a solution to generating the head data. I imagine it's mostly Node and the PHP stuff is experimental, but I'll give that a look up
No.2699
This is pretty good
https://alligator.io/react/server-side-rendering/makes me wonder if the site could switch to Lynxchan and redo the entire front end that I detest, but I think what I'll do is some more research on how it works and consider the current rework a prototype. See if
https://www.phpied.com/server-side-react-with-php/ is any good for Vichan and use Redux which I should have been using anyways. If things are going the way they are anyhow kissu will probably end up custom made...
>>2551As another thing the basic stylesheets should be merged into a big SASS fragment project so this problem stops happening.
No.2700
It would be interesting to know how much Kissu costs to run financially and figure out what limits it will run into first if it grows (e.g. bandwidth, CPU, RAM, disk space, disk I/O, etc.).
No.2701
>>2700site's RAM is always full and disk space is growing short. Realistically I need to cut filesizes more, but improving the ui will make more people satisfied/happy with the site
No.2702
i think server has a lot of junk on it that could be removed for that, but it's not at the point of worry. In post time, by comparison it's still faster than sites that are bigger. Kissu runs on cheap and the expectation is everyone has a faster computer.
Netflix uses SSR React, but they spend a lot on high performance servers I imagine and can balance RAM issues.
I read an article where they suggest it be SSR for web crawlers since the mainstream usage of SSR is for SEO so there might be a way to focus it for userscripts and nojs clients
No.2703
sigh, but I still think that userscript style UI flicker is a problem. I'm stuck. I guess the only way to tell will be to try it out.
I guess we need some before and after benchmarks like you suggested
No.2704
>>2701Is the disk space mostly user-uploaded files? Going by API data and not attempting to count thumbnails, I see:
1 563 153 645 /qa/ (archived)
1 287 852 690 /megu/
1 147 621 791 /qa/ (active)
231 931 017 /b/
128 547 395 /trans/
76 689 650 /xmas/
46 108 842 /poll/
27 004 528 /test/ (archived)
15 464 988 /spg/
6 383 560 /win/
5 314 020 /test/ (active)
4 536 072 126 total
Looks like the archive is a pretty big chunk of it. Is the archive set up to prune its oldest threads when the disk is close to full? If not, that might be a useful measure to prevent a full disk from bringing the entire site down.
Do you know what's using all of the RAM? Is it an intentional feature (if the RAM is available, might as well cache things in it to increase performance) or a potential problem down the road?
No.2705
>>2704You can get a true number on the front page(unless it was altered somehow which might be so). Front-page should say all content even though it says active.
I think MySQL is auto caching. This isn't something I've looked at yet. I'm just reading the hostinger dashboard which summarizes at 15 min intervals
No.2707
so I deleted a bunch of files older than 2 weeks. I'm not sure if it was from a bad upload i did from desktop or a bug because it cleaned thumbnails properly and files use the same logic
No.2709
The site isn't in any danger as yet from these two issues and I can cut back filesize restrictions to 8mb or change thumbnailing to compressed .jpg. Even issues of performance are solvable(
https://medium.com/walmartlabs/reactjs-ssr-profiling-and-caching-5d8e9e49240c) and I can shuffle more applications onto the taba server if need be.
Thinking about it a bit harder the real question is where am I going to be limited by this SSR React approach if I keep using PHP Vichan? ASP.net has an entire site dedicated to the topic
https://reactjs.net/features/server-side-rendering.html, NodeJS has obviously complete compatibility, PHP though… well you have to resort to researching articles for niche libraries or solutions. All of the big ones look fucked
https://github.com/phpv8/v8js/issues/409.
I would also need to have the NPFChan archive solution be reworked to handle archiving of SSR pages and the mod pages need to be reworked as well. Vichan is hugely dependent on Twig 1.x. For all the work they put into customization they didn't have any in mind for the internal View engine.
I'm in a bind. To tear out Twig and adopt anything else(ReactJS, Twig 3.x, Dusk, etc…) is to rewrite 25-50% of Vichan with the uncertainty of the current or future compatibility on PHP upgrades.
I guess this is the issue that asks the existential question of the site's software and why even try to breath some life into it.
tl;dr, vichan is fucked.
I think what I'll do is see if I can get a hacky SSR working with the prototype in vichan, hack on the existing legacy JS, write a new catalog, home-page and QR form and then we're going to drop vichan in favor of something else.
I'll summarize this all in a blog post
No.2710
man, it never ends.
https://julay.world/meta/res/1372.htmlI'm going to have to write an entire imageboard in .net or Node (without any of that one size fit all bs) to be satisfied aren't I...
No.2711
>>2709Maybe you could do a gradual rewrite by using PHP and Node in parallel, both using the same database with nginx directing requests to PHP or Node based on the URL. Although I don't really know vichan well enough to know how helpful that would be.
No.2712
>>2710https://julay.world/meta/res/1372.html#1601>Penumbra is limited by LynxChan's shitty templating limitations and putting lipstick on it won't change much. So far the most advanced frontend is Kohlnumbra and it still looks like shit.Wait, does this mean LynxChan's separation of frontend and backend amounts to changing the templates like you can already do on Tinyboard/vichan?
No.2717
Deleted a bunch of posts to refocus my thoughts
>>2712I thought the idea behind lynx was to take away vichan's thunder, copying whatever would make it easy to move to. They certainly advertised on a bunch of sites running it. I'm not sure if Lynx is the right pick if I would change though. I described to someone in Steam that if Vichan is McDonalds then Lynx would be BurgerKing.
I'm leaning towards a lightweight framework written by someone who just wanted to make an imageboard.
>>2711I think it could be done. It will end up being a lot of nginx rules for each PHP page that is an exception. It corssed my mind. It feels really hacky but that's the objective here. Never know. The posts.php page and mod.php pages are the two big things needed.
Just will take another API for post form info to retrieve: ```<input type="hidden" name="hash" value="35c4710c8f598a2
b5e8c468270f909af7cceb
030">```
I wanted to use 4taba's kotatsu as a potential kissu2.0 but he chose the wrong tools for the job.
Ilia's Hikkaba could be of promise
https://github.com/magicxorthe problem is if it's Microsoft Server focus - Linux as afterthought.
There are a few interesting C# imageboard software:
https://github.com/magicxor/Hikkabahttps://github.com/DCTewi/Tewi-BoardBut on the otherhand it seems like I'm building the website around the idea of a responsive front-end so it might be a better idea to find a basic NodeJS software that would allow me to add what I need without the extra unfocused extras.
Applying the techniques of experienced developers
https://www.youtube.com/watch?feature=player_embedded&v=sn-C_DKLKPE is easier in the language they wrote the lectures in
So I need to find a not-lynx NodeJS lightweight imageboard software.
No.2718
For now I'm going to look into
https://github.com/phikal/4jhan-serverIt seems like a skeleton of a concept I might use here.
This is pretty up in the air though, not a high priority. Just a general idea of where things would go next.
No.2719
>>2717Reading over this again, I think I'm getting too caught up in the flaws with vichan and not appreciating what's good about it.
I think
>>2711 is a more professional point of view on how to take it. I know that most big websites are written with multiple languages to suit multiple goals. It means I have to do less wheel reinventing as well.
So I'm caught between:
A) Working with a small NodeJS imageboard and expanding it into something more serious.
B) Expanding the PHP, NodeJS and NGINX solution that will be put into place as a short term fix into something more serious. Despite me sounding more favorable to A before it's probably more practical to do B.
B will be done for the next period of time anyways.
Though I think this JSON focused imageboard idea is interesting, it means that I have to throw away a lot of vichan's pretty not terrible code. I'm more familiar with PHP than NodeJS at this point anyways.
>>2718It's a pretty interesting service anyways. I added simple instructions on how to get it running in 2020
https://github.com/ECHibiki/How-To-Run-4jhan-server- No.2720
>>2711yeah. So good advice. Using NGINX Vichan ends up becoming the POST, DB and API engine and a new software is written for the front end GET to handle the rendering of API information into an SSR semi-SPA isometric application. In the long distant future when Kissu gets to the point where I have to start shuffling things around for performance and bandwidth there could be more components removed from vichan until it eventually is phased out, or what is the best parts of it remain.
I think my mind's settled for now on the topic so I can move forward on the front-end redesign knowing where things will finally lie.
No.2721
Is it me or are auto-updates borked?
I have it enabled here, but the page options panel isn't present in /qa/ and threads are no longer updating automatically.
No.2722
>>2721The new UI is only on /b/ right now.
fixing the problem though
No.2725
>// If it were possible to XSS this then it should also be possible on vichan.>// Still a saftey check would be niceObviously XSSing this depends on vichan improperly generating the HTML for the embed, but it's happened in the past:
https://github.com/ctrlcctrlv/infinity/issues/378It would indeed be nice to rewrite this to make the site less fragile against accidentally introducing XSS through these sort of code changes. But at least the fact that the rewrite in React caused this section to be correctly marked as dangerous is progress.
No.2726
>>2725It's not just that it would be safe, it's that it's required because I can't handle on click events through React unless I do the manual conversion of string into JSX element.
No.2727
parsing it I mean
No.2728
If you go with the SSR design, do you have ideas how the client side code will get necessary post properties such as the URL of the full file (which it would need to expand images on click)? Would it be parsing them out of the HTML, would there be some JSON delivered within the page somewhere, or would it require a fetch from the JSON API? I don't imagine it would be a show stopper, but it's something to think about.
No.2729
>>2728It wouldn't be 100% SSR, but SSR+SPA Isometric with possibility for repeatably requesting pages from server, or disabling the SPA behavior on option select(using noscript tags within the SSR of React as required). So it still requires the same system of JSON API fetches either on front-end or back. Hopefully since the page is generated server side the info will be cached ahead of time.
I suppose it could be a mix on initial page load but that could make design a bit more complicated. Could possibly minimize the work that the client has to do by putting the true formats(time as a string rather than unix number) into a page render specific json file. The XSS on the comment, well, I'll probably do that all server side. Instead of embedding raw HTML it would be a BB like syntax so only permitted information gets through and have the client parse that into JSX Elements.
Also worth noting that the version that's running here is probably just prototype. My architecture doesn't exist and I was running into problems requiring ref(typically considered an escape hatch for bad design) so I need some guiding framework or ideal. Redux supposedly helps. My plan is to have this version running on /b/ with all the things I will want in a real version(SSR, Redux, some degree of SPA), and then do a rewrite. A bit more time intensive, but instead of predicting all pitfalls they will be encountered and hacked out initially.
No.2730
Also will be put on another repo. I believe this is the natural way to do it since the isometric front end will be a seperate service.
No.2731
The user options can't be set through localStorage and will have to be done through cookie... no way for server to read localStorage. If need be a userscript could alter the cookies so that they don't go into SPA mode.
No.2732
Also the typescript question
https://medium.com/atticus-engineering/server-side-rendering-with-react-and-typescript-8cebb4400b3cguess I'll read on this
So over the next period of time:
(1)- I'm going to get an SSR server running
(2)- Verify that userscripts and the legacy JavaScript can run on it
(3)- Make the bugfixes in this thread from the community
(4)- Add prototype to main pages to verify it's effectiveness
(5)- Modify the application to make use of Redux or Flux
(6)- React Router to shift between threads and page
(7/8)- Implement the Catalog.
(7/8)- Implement the QR form.
(???)- Convert the big 3 themes into a big SASS or LESS project
And when that's running, for the sake of making it easy to use, do a rewrite using proper design patterns and clear architecture. This will allow for easy upgrades into caching solutions should the site require it in the future. Most work should be reusable, it might just be more of a serious refactoring than a major rewrite.
I'd rather make it easy to solve problems as they come up than predicting them off the bat. Keep it a simple and well written front end.
No.2733
>>2731Wouldn't providing everyone with a custom dynamically generated page put a lot of extra stress on the server? Ideally once one user requests a page, you want to be able to cache it for everyone else. You might want to consider generating it server-side with default options and then changing the options to what the user has selected on the client side. Although I guess it's something you could change when the problem came up. Another disadvantage of cookies is that they increase the size of the HTTP request if you have a lot of them.
>If need be a userscript could alter the cookies so that they don't go into SPA mode.This would work only if changing the cookies after they were sent to the server was not too late to change whether the page was in SPA mode; that is, if SPA mode only differed from non-SPA mode by what happens when you click links, and it checked for changes in the cookie when you clicked a link. Otherwise a userscript setting the cookie would be unreliable, since a userscript can't set cookies before they're sent to the server on the first page load, and people clear their cookies a lot. They often disable them, too, so setting the cookie if it was wrong and reloading the page would be a bad idea that could potentially create infinite reloading loops.
No.2734
By the way, I do intend to get 4chan X working with the SPA version of Kissu, but an option to turn it off could make things easier because I wouldn't have to make all the necessary changes right away.
No.2735
>>2734Uncertain if it will run into the same issue or different ones. Can't find any documentation, but I don't think having it be timed like a typical HTTP request would be in their use cases. Still I can run a quick test on banners.
No.2736
>>2733This would be a better idea. My concern was if an option modifies a page after being received causes legacy JS or userscripts to break. Might be a concern to certain hover links
>>If need be a userscript>This would work Might not go with cookie then. For the current set of features in mind they could all be cached and combined as needed, but it's not thinking of the future. Also thinking about how cookies get disabled by more people than those who disable JavaScript.
Doing options dynamically would be better choice. Probably will resort to event listeners again
No.2737
Probably the most important thing is to avoid being unnecessarily locked in to any one design choice that you might discover later to cause problems. To use the settings example, it would be bad to have direct references to document.cookie (or the server-side equivalent) or localStorage scattered all over the codebase. That's probably just common sense good coding practice, though.
No.2738
>>2737keeping dependancies seperate and accessing through bridge interfaces basically.
Yeah, the code has that problem. The settings are in a datastore but the design of how to get X to Y in React seemed tiresome so I cheated and used localStore as a cop out global.
When the initial SSR is running and I've made fixes I'm going to do a part 1 refactor to make it follow an architecture designed for large apps. Flux comes to mind.
No.2739
In the meantime I'll see about a bridge class to abstract out the details through getters setters
No.2740
>>2738Like, the only way that the docs suggest getting data from point A to point B is through a long string of callbacks up and down the tree. There's got to be a better way than that but deadline was cracking down so made shortcut.
No.2741
also the intermingling of data and components in react is troublesome.
This may be where my problems in the design are coming from. Hoping that using a design pattern will fix this
No.2742
>>2740React's context API might help.
No.2743
>>2742kinda helps but I think it's designed as a tool that you're supposed to use to aid good design, not hack your way out of a problem. Application needs the pseudo-MVC of Flux design.
anyways, what I'll be working on is here. I'll merge the changes from the kissu-vi branch into distro and shift my work over to there.
https://github.com/ECHibiki/Kissu-React No.2744
>>2743Yeah, I was only thinking of using the Context API as a way to propagate user settings to the components. It's not going to solve all the problems.
I took a closer look at the code, and the first thing I would do to refactor it is pull the AJAX requests to fetch the JSON API data completely out of the React components. I would use React strictly as a view; it doesn't need to know where its data is coming from. The update button would trigger a callback defined outside of React which would have the JSON fetched (it might be a good idea to have a separate module for API requests that is responsible for knowing what URLs to fetch from and in which the actual AJAX request would be performed; this way if the API changed slightly, you could just change that module). The callback, having received the JSON data, would update the properties of the React component with the data. It's moot if you switch to SSR, but waiting for componentDidMount() to start the AJAX request is slowing down the page load. And this would eliminate the need for thread_rebuild_ref and paged_rebuild_ref. Granted, I know nothing of React other than the research I've done while thinking about this redesign, so there might be some problem with this I haven't thought of.
No.2745
>>2744Also it would make testing easier because you could feed the React components made-up data in an offline script and not worry about errors due to XMLHttpRequest not existing.
No.2746
Unsure if this is a bug or just a problem on my end, but in firefox the tab updater has stopped working. It's just firefox, and I know this because I tested in chrome and saw the notifications for new replies.
Not sure if this problem is affecting only me, or if others are troubled by this too.
No.2747
give me the version number
No.2750
>>2749your browser settings must be custom tuned/caching too much and isn't staying up to date with changes. I minified the JavaScript to try and force your browser into redownloading.
No.2751
>>2750Maybe at some point you could implement the version number mechanism 4chan uses to force reloads.
No.2752
>>2751I think this is doable with the setup. Just need to move the webpack config to a lower level and can apply some build variables to the project. Guess using webpack on nodejs was good decision after all.
(
https://medium.com/curofy-engineering/a-guide-to-inject-variable-into-your-code-using-webpack-36c49fcc1dcd) No.2754
>>2740>but deadline was cracking down so made shortcutI hope that this will just apply to the beta test of the software. Would be best to see you take as long as you need on development and bug fixing before you release the final version
No.2755
it's fine. April 1st is a day free of consequence. Do well and it's great, do bad and it doesn't matter. As long as it's not real release with flaws
No.2756
>>2755not so sure, this may not be correlation and have to do with some other factor but daily post count hasn't exceeded or reached 200 since April 1st
No.2757
yeah, I stopped promoting board for the past 2 week to focus on software
No.2758
>>2757Ah if that's why that's fine then. Better to wait until you've got all your neat updates rolled out to srart advertising again anyways.
No.2759
>>2758Either that or I annoyed everyone into submission with rants. Even then I don't know where they'd go.
Probably 4chan if I think about it which is all the more reason to have something unique about the site. Front end Software isn't at a state yet where I can spend my dev hours advertising anyways. Back-end doesn't matter too much until bottleknecks are hit. When kissu has a responsive user experience and good visual aesthetic the user cap should be raised.
http://s11.flagcounter.com/more30/CexS/
from the flag counter on the site I feel like we hit a plateau of advertising effort to result. Part of it is visual feel, other parts is what I'd complain to be a too much of a documentation heavy culture on the site and not discussion focused. Much of /qa/ is paranoid and not 'tistic.
No.2760
anyways, I think that it's healthy to have occasional drops in users because it gives people the chance to reset the culture to suit things better for the core audience. In 4chan you're always chasing after the flow even if you dedicate yourself to it, but a smaller board allows them to shape things if they stick around. As long as the site shows promise it'll be fine. A combination of the two is ideal, but whatever. The combination is what 4/qa/ has but the site needs work done to it to attract that kind of attention.
Redesigning vichan's front should do a lot for growing the site. The new UI which will (hopefully) give users better navigation between pages and more responsive/user-defined control will encourage people to navigate the site more and post. Reworking the CSS and HTML layout should give more attention to the details that matter/are-interesting.
No.2761
currently the SSR server shows no compile errors with TypeScript, but probably lots of logical errors. I plan to do fix ups, compatibility and upload tomorrow. Will be doing some benchmarks against /spg/ on default vichan, /test/ which I'll put on the client side React and demo.verniy.ca which will have the SSR. Assuming I don't need to change anything, the SSR will run the same as the client side react with the XHR.
System is very heavy on abstractions folowing a strongly decoupled MVC pattern where every V=>M or C=>V reference must go through a bridge. This should allow for easy changes and debugging. At least it won't be as slow as the SSR.
I haven't done any optimizations or fixes to what exists, just for the sake of a base comparison to see how much needs to be done.
No.2762
So:
Tomorrow:
- Debug
- Deploy
- Benchmarks
For it to be placed on kissu/b/ it needs:
- Script Refactoring
- Issue fixes
- Expand to cover all page contents(new thread)
- Client side optimizations
for it to be optimized it needs to be at maximum 2x as slow as a normal page load, meaning it can not exceed a 1500ms load ever. This can be further optimized later.
To go on /qa/:
- SPA behavior from thread to page
- Quick Reply
- No bugs
- Clean code
Extra:
- Catalog replacement
- CSS replicate
- Index replacement
- Fileboard replacement
- Archive replacement
- Overboard replacement
- Test cases for future expansions.
These are optional work that will be done at a slower pace in favor of a return to promoting site. In an order of priority
Misc:
- Github cleanup
- Prevent vichan from generating page and thread .html files
To save time kissu will probably use the vichan mod system and any existing .php pages such as bans.php. These aren't vital to the experience and would get removed as a component to replacing another Vichan part.
No.2764
Just threw a server side ssr hacky mess together so that I can get a prototype view. I've got to do a major refactor of the code. Looks like SSR on localhost is a bit better than .html loads on kissu though. Big improvement over client side rendering on ubuntu FF. Need to do some more equal tests and see the memory and CPU benchmarks on the server.
.html /test/ regularly 294ms
SSR localhost fluctuates on average of 200ms
Client demo.verniy.ca (kissu servers) around 500ms
The real killer here is how am I going to maintain two versions of the front end and keep them in sync. I believe it will do a rebuild of contents to match with user settings when reaching the client(might be able to disable images and leave that for the client to find out), but React hydration needs the server version to be interpretable from client. I may need to resort to internal templatization right off the bat to maintain consistency.
The NGINX config will be another difficulty... I don't know anything about how it effects performance or optimization.
Need to have a really well planned out architecture for the React client side or it's going to be mega pain...SSR doesn't seem to be well thought out by the React team.
I'd consider not doing SSR at all and just dealing with a slight loss in users, but I'd also have to abandon archive.org in favor of archive.is which is inferior and small sites can't compromise. Also it appears to be faster. Probably will do token benchmarks and proceed. Hopefully can get a rough idea of what quantity of users would become a problem.
No.2765
I think the biggest gain is no more XHR lookups other than after hydration.
I wonder how we can transfer data faster between client and server? An advanced timesaver for SPA could end up being a socket connection to the node SSR server to stream information... No more HTTP overhead so client should have faster experience... anyway I'm getting ahead of myself
No.2766
>>2764Some alternative ways of optionally disabling thumbnails:
- change the thumbnails to background images and remove the background images with CSS that's set before they load
- set the loading=lazy attribute (newer browsers only, experimental) and hide them with CSS that's set before they load
- put all the posts in a <noscript> element and have the script use a DOMParser to parse everything, and do any updates to the DOM before inserting it into the document
No.2767
Benchmarks are a bit strange.
https://gist.github.com/ECHibiki/46c235e91f89b0b6aa34730948c62ba9--Server--
Generating a mod page in PHP is 940kb Heap pretty consistently.
Generating the same page in Node 1242kb for the Heap Used metric but it droped on the third subsequent request to 737kb and later 615kb, but eventually returning to a similar 1242kb.
PHP's CPU counter didn't show any changes. Might need a different tool..
NodeJS showed 112ms to process the data to send, but on the ones where the Heap usage dropped were both in the range of 43.9ms.
This is on a 1core(2.4GHz) server at 1GB of ram.
Couldn't find a way to measure CPU usage, but from the timings it looks like CPU would run out first.
--Client--
On client a bit more easy to gauge.
standard vichan, scripts and all: 400-560ms to load, but 9.72 MB noscript to 12.65 MB withscript. Firefox's Peak Energy impact maxed at 11.95
client only react:260-450ms
SSR with hydration(not taking advantage of SSR due to bugs): 260-470+ms
SSR no script:250-415ms
react is generally 12.13 MB to 17.83 MB. Firefox's Peak Energy impact 21.3 typically
.html and SSR noscript pages are obviously lighter. The client side hydration of SSR pages isn't being done well because the code isn't written for it, but it still mananges to reach similar mins and maxes and client side even taking into account the added time to process the data. Vichan is losing out due to the weight of all of it's additional scripts. The React example was a bit lighter though.
No.2768
I guess the main takeaway here is that React (server side or client side) is CPU heavy. I don't know if it scales linearly or not with increased traffic, but the current server React version would probably start to experience slowdowns limited by how many threads the CPU can run... at ~100ms to generate a page it will probably get hit when many requests fall within that time frame. I'm not sure without percentages and specific CPU info. In Heap at least it looks like 400 requests per second would cause the site to have memory issues. The issue here is CPU cycles. Reddit is estimated at average of 157 requests per second(June 18th, 2017). Using SPA and putting greater emphasis on the ability to refresh without pressing F5 would help, but without scaling in one direction or the other then performance hits would start playing a problem.
I suppose two ideas come to my mind. Limit the requests per second through NGINX, or(probably more user friendly) prevent the SSR from sending completed HTML if server load is too high and have clients generate the page contents instead. Some solution between the two. The more hardcore one is probably going to be templating components and keeping them in a cache of sorts.
>>2766so that being said I think the only negative thing that would add to the CPU load is the third point:
- put all the posts in a <noscript> element and have the script use a DOMParser to parse everything, and do any updates to the DOM before inserting it into the document
The advantage here is for page load times and not slowing down the browser HTML right?
No.2770
>>2768Regarding
>>2766 those are three different ways I could think to implement an option to suppress thumbnail images from downloading other than turning off images for people without Javascript. Another option would be to deliver the non-JS people thumbnails in <noscript> tags. If such a user setting were implemented, I personally would lean towards the first option; that third option would indeed slow down page loading.
No.2771
>>2769>Meaning I'm certain the SSR solution can't support /bant/ without me caching or going horizontal.Is there any reason not to put a cache in front of the front-end? I would think that would be common sense with this sort of design.
No.2772
>>2770And the reason the third option uses DOMParser is because it's a way to construct a DOM tree with an <img src="something"> in it without the image being downloaded.
No.2773
>>2768>I suppose two ideas come to my mind. Limit the requests per second through NGINX, or(probably more user friendly) prevent the SSR from sending completed HTML if server load is too high and have clients generate the page contents instead.If server-side React becomes too expensive, an alternative which solves some of the same problems would be to put the JSON somewhere in the HTML. Then you could use the JSON to generate the posts without making an AJAX request. I would expect it to load faster than the version that has to wait for an AJAX request, but slower than SSR to display the first replies of large threads because it wouldn't display any posts until most of the page was downloaded. It might or might not work with web.archive.org; from what I understand, they can handle some Javascript, and they might just be getting messed up by not waiting for the AJAX requests. I'd have to do some testing to find out. It wouldn't cater to users who disable Javascript, though.
No.2774
>>2767Regarding the time measurements, how close are you to the server? Bear in mind some people are going to be further away and/or have worse Internet, adding time to any network request. Or are you just measuring time to render after you receive the response?
No.2775
>>2771I'm not sure I see what problem it solves. I believe that my current implementation could do it without much work. But, my problems are going to be with server CPU bottle necking page builds if it's SSR. That's what my tests say anyways. The browser will be caching JSON as well.
>>2773archive.org is handling it inconsistently. Now it seems to be treating react loading properly on the demo site and therefor causes the scripts to fail fetching the JSON. Putting JSON inside of the page for initial load might be inevitable.
>>2774Some people didn't like the idea but the preloaded content could be put onto a CloudFlare CDN or equivalent kind of service. Putting the JSON in page would help with this. I don't know much about how CDNs effect operation, but I might need to fix some bad nginx code I wrote a year ago.
No.2776
>>2774Total time from server to computer.
No.2777
>>2775>I'm not sure I see what problem it solves. I believe that my current implementation could do it without much work. But, my problems are going to be with server CPU bottle necking page builds if it's SSR.If multiple people request
>>>/qa/ for example without there being any posts made in between, the server would only have to build the page once.
No.2779
>>2777That's not front-end caching though? It's back-end where you'd store strings in a redis cache or in memory however you want. This is what I mean. I would do this first if things start getting heavy so that server isn't building pointlessly.
Do you mean retrieval of data and using retrieved component strings to set through inline HTML? Because that's an interesting idea. I'd need a way to set the event handlers though.
No.2780
I may have misread you. I thought you said front-end cache, but you wrote 'in front of the front-end'.
My glasses are starting to get scratched
No.2781
>>2775Hmm, looks like in at least some circumstances it just archives the Javascript and lets clients run it:
http://web.archive.org/web/20200409061120/http://containerchan.org/test/archive.html
That's a bit surprising to me.
In contrast, archive.is executes the Javascript and turns it into page content:
http://archive.is/gpold
No.2782
Know any good documentation tools..
I have 4 pages of features needed that I'm going to put into a UML doc to outline how they fit into the flux architecture and SPA
No.2789
why do the legacy scripts on this site not even use the API... not even portable
No.2790
>>2789They probably predate it plus the JSON was not enough information to build a post because it lacked details like the extension of thumbnails.
No.2791
wish they spent more time updating and refactoring. Half the scripts they include are edge cases to compete with things like Disqus
No.2793
>>2792I didn't notice properties.json was there before, even though you mentioned it previously while developing it, so it's already helped somewhat. Could use some written details on what each of the boxes are.
No.2794
I'll consider it, but it's partially for myself partially for anyone who wants to modify so the titles and arrow labels should hopefully be enough for someone to know where to make a change...
thinking about taking inspiration for media expansion from this software
https://allchan.su/d No.2796
>>2793Leaning towards good/up to date documentation being more valuable than test cases though so not denying it.
No.2797
>>2794>I'll consider it, but it's partially for myself partially for anyone who wants to modify so the titles and arrow labels should hopefully be enough for someone to know where to make a change…For the second case, I'm not sure I would be able to figure it out from just looking at the titles of the boxes. It's not obvious to me where all of these things live in the repository.
One thing Lynxchan did fairly well was documentation. This is a good example:
https://gitgud.io/LynxChan/LynxChan/-/blob/master/doc/Engine.txtHe tells where all the modules are located and gives a description of each.
No.2798
>>2794Not so sure about how I feel about that kind of image expansion for non-video things. It is pretty nice for webms and such, but seems like it'd get annoying for regular images/gifs. Although it'd especially be annoying for anything that's audio focused that I'd just want to expand and see in the background.
No.2799
>>2798>see in the background*hear in the background
No.2800
>>2798The audio would be a problem, but I feel like my experience is limited after being able to move image windows around the screen. Adds something to the board that makes it easier to collect images on the screen and organize them how you want.
I'd consider it an optional feature, but my past 2 hour impression has been towards windowed images. I'll see, probably need to do a prototype and see how it feels and others impressions.
The way that they get closed is maybe not the best. Like an OS opening up panels might be better. Like a filesystem in the browser. Draggables are really easy too
https://mzabriskie.github.io/react-draggable/example/>>2797I see. I prefer graphics because they show structure better and think someone can read the code to figure out what the module does(description comments on the top would be a good practice), but knowing where they are is quite important because otherwise they won't be able to read the code...
No.2802
Different use case than expanding media that shrinks the amount of possibilities a user. Using that aspect of the UI is to focus your attention on images and view as an image catalog. I don't feel like I gain from this unless I'm reading a book.
And regardless, I'm tired of dealing with people who discredit ideas on surface level details because they want the same broken normalcy without iterations and improvements on design.
No.2803
>>2802Most of my concern just stems from how this would effect pre-loading gifs/webms to play automatically in the thumbnail, or if it would mess with hover expansion. Rarely do I ever actually click on an image rather than hover over it quickly and move on. I'm not entirely convinced of how preferable it is to take a second or so for the image to load up in an exclusive mode of sorts, then having to click away or something else to close it. It certainly has its merits, but I can see it disrupting the flow of just going through a thread while not necessarily caring too much about what images were posted. If both work at the same time it's probably fine though
No.2804
>>2803I seem to have been mistaken, it doesn't open up an exclusive mode for the images, I just mistook it for being like that. It probably is superior to regularly clicking on images taking that into account. However, I still stand by what I said about how it needs to work with hover/thumbnail preloading.
No.2805
This is why I say I would make a test version first
No.2806
Oh yeah, not sure if you noticed, but your date is off by a month
No.2807
>>2806I'll fix it when I get to working on that part
No.2808
Component architecture is layed out. Think I've got a good system for starting the app without having to modify any code. Next to plot out all of the signals and notifications to and from the components.
I'll make documentation part of my design process here. Before I start working the the client/server react do a more thorough job on the docs for the SSR(text+blueprint).
No.2809
bleh, looking at my notes I forgot to put down: options✔️, reverse image search✔️, navform+page update✔️, capcodes✔️, QR form closing✔️, page list✔️, styleselector✔️, dice(droppable feature)❌, and need to think a bit harder on how to display captchas✔️. Also hide buttons✔️.
On server need to implement: json data html insertion11, cookies set css theme(but not react generation in foresight of caching complexity)12.
After this plot out the action each component can take and which functions will handle it causing rerendering9001.
Plan good, never miss things.
No.2810
I guess I ought to also start thinking about what JSON data I'm going to need to add to the vichan post engine.
It's anti-spam hashes need to go into a json file I guess. I think it puts a bunch of garbage in there that can be excluded(because I don't know why...)
No.2811
nevermind... you don't even need the garbage they put in the post form...
No.2812
This upgrade will take me a month and a bit of work (low estimate), but I think I want to seperate the moderation components from vichan next.
I have a better system to handle moderation issues from administrative and user point of view. I'll keep it in my head until relevant
No.2813
Pointless planning and idea pornography. this is probably years down the line(priority of site maintenance) and worked on the side while site continues with ViChan.
I think we'll be following the Twitch tech stack and have the moderator service layer be a Ruby.o.R. service with media alterations in CPP and post-DB/API interactions in golang or similar. Of course front in React. Captchouli already golang so makes sense to follow along and integrate it.
https://blog.twitch.tv/en/2015/12/18/twitch-engineering-an-introduction-and-overview-a23917b71a25/Use right language for right job and such. Make mod layer easy to build. Media alterations fast. IO be fail safe and fast.
No.2814
Captchouli is GPL3 so that component would follow licence, but that shouldn't be concern since projects for kissu are MPL2 which is non viral copyleft(Apache)
No.2817
plotting everything out ahead of time is taking longer than thought.
Planning for the handling the 8 page types on kissu is a very long process.
Come to think of it I haven't yet accounted for the display of ban messages, ban.php and appeals...
might be best to postpone any mod aspects into an /mod.php rework and have the SPA redirect to a dynamic PHP page on ban
No.2818
List of all properties on components should be done tomorrow hopefully after which I plan out every action a component can do. This might not be as long process as it's easier to notate, but I'm not yet sure if Redux would benefit the project so there's some dependencies and architecture there that needs to be thought out.
After all this blueprinting I can hopefully codemonkey my way through it assuming I haven't made any oversights.
If so probably will go back to reworking the schematic,
said schematic is a mess of arrows that is probably impossible for anyone to interpret.
No.2823
Finishing off basic template of component design and verifying everything. So tomorrow starting a template for component usage(as relevant to a Redux state management system). With a full template designed I should be able to just effortlessly design it and spend the extra effort on solidifying the documentation. Before that need to revise the SSR to handle cookies for stylesheets and a basic template implementation I want to try.
Since it's just going to be a basic rendering of the entire page stored in memory, rendering server side based on settings makes templatization impossible(exception to certain items) unless individual item templates becomes a thing. Some quick math shows that there are worst case 290,304,000(58GB/board) page variations when only 9 options are used. Limiting this to four common ones would be 38,400(3.84MB/board ) variants which is scalable to a large site. More advanced solutions would provide either more performance or more customizable generation. For now just a variant of images and no images should be fine. There are bigger concerns anyways.
No.2825
conflict with 4chanx i think
No.2826
realized that if I follow a methodical testing routine of programatically generating each component through SSR as I make it, then advanced templatization could be easy in future
No.2827
I believe I've accounted for every component in the design so now it's a matter of planning the startup events and component actions.
Also will need to make a modification to the banner program to allow for head banners as well since the old system is going to be broken and might as well do that while I'm at it. Need to add in another antispam feature anyways.
No.2849
Just noticed the political banners I asked about are now gone. Was there a change in direction?
No.2852
>>2849they didn't fit with the tone of the rest
No.2855
The nazi iconography is designed to be eye catching as well. It's obnoxious.
No.2857
>>2823Thinking about saying 'to hell with simplicity' and just using a DB for caching because why not. If I want to redo vichan's database I'd probably resort to a not relational DB anyways to distance kissu from vichan. Mongo or Cassandra probably. Redis has high memory consumption and likely can't support a large site. Mongo seems to handle reads better so likely this over write oriented Cassandra,
Putting site's current and possible future tech as
- Laravel, MySQL, and React banner service(possibly rewrite to Mongo)
- GoLang + Sqlite3 captcha service(possibly fork to Mongo)
- NodeJS, React, Mongo site display service
- PHP and MySQL Post/DB/Mod/API service (hopefully eventually broken into a GoLang+Mongo post/db/api service and Ruby mod service following Twitch Dev's examples)
At which point I'll have complete understanding over everything in kissu's software and future updates become easier to conceptualize
No.2858
What happened here?
>>>/qa/36446
">>36446 , it's" morphed into ">&>>36285 s".
I wasn't able to reproduce it in /test/.
No.2859
>>2858got that in this thread somewhere but thought it was a mistake in my UI(
>>2558)... interesting..
it
No.2860
It's the French accent somehow...
à la the Motif-Index of Folk-Literature or the Aarne–Thompson–Uther Index. I'd like to develop it myself, but without any study of anthropology it just MIGHT be beyond me.
And that's NOT ACTUALLY A TANGENT, because with this I can say that my current definition of internet memes is a bit of a bandaid and there is a lot more to explore. Although I would argue creepypastas are normal memes in the internet, seeing as urban legends exist, what I refer to as internet memes do kind of exist IRL. See: knock knock, X walks into a bar, etc. Regularized jokes centuries older than the internet.
PS: do read
>>2301 , it's superb.
la the Motif-Index of Folk-Literature or the Aarne–Thompson–Uther Index. I'd like to develop it myself, but without any study of anthropology it just MIGHT be beyond me.
And that's NOT ACTUALLY A TANGENT, because with this I can say that my current definition of internet memes is a bit of a bandaid and there is a lot more to explore. Although I would argue creepypastas are normal memes in the internet, seeing as urban legends exist, what I refer to as internet memes do kind of exist IRL. See: knock knock, X walks into a bar, etc. Regularized jokes centuries older than the internet.
PS: do read
>>2301 , it's superb.
No.2862
In any case, your message is preserved in correct format but it's being rendered wrong into the HTML/comment object.
No.2863
>>2862The flow of arcane magics is fickle.
No.2867
doesn't matter much now though since it's essentially gone, meaning it's as noticeable as 4chans and not persisting for a full second
No.2868
>>2867It is indeed shorter now.
No.2870
it seems like firefox is really sensitive to bad syntax, so fixing a few console warnings helped I guess
No.2872
>>2823>>2818Redux has design limitations that will be a pain to get over and require more dependencies and code abstraction(the authors themselves comment on it's poor readability). So back to custom Flux architecture which will be easy enough to make.
Context API by comparison
>Context is primarily used when some data needs to be accessible by many components at different nesting levels. Apply it sparingly because it makes component reuse more difficult.Seems like it has it's own set of restrictions and is more tightly coupled to React for better or worse.
The issue of state management is something that looks as if it has to be specific for the job. Redux fixes some issues, Context API others. Better to stick with one than many. I think Kissu's case is exception for reliance on APIs that Redux does not support out of box and our use case does not require all the tools it has. The single store approach of Redux does not seem appealing as well and damages readability.
No.2875
I think /poll/ is broken. I can't add options when trying to make a poll, only subtract.
No.2878
>>2875Thought I fixed that but must have reverted to a broken version.
Putting comments into inline JS isn't good idea. Vichan's HTML minifier isn't smart enough to remove inline javascript comments so it condenses it removing large chunks of code. My fault for not knowing it would happen.
No.2879
That's all in the plans to be getting remade anyways.
The poll board's function will probably change a lot in the coming 2-3 months.
No.2880
fixed anyway
No.2881
Thank you, I noticed.
But I still can't make the poll, now it when I try to post it I get the error "Data too long for column 'colors' at row 1".
No.2882
I never intended for it to be used with 26 different options... let me see about changing the max characters for colors
No.2883
Exploratory testing, I had to assure /poll/'s quality.
No.2884
it's pretty much prototype of a concept. It requires more logic to set the size of the form based on number of inputs.
>>>/poll/361
as you can see it's pretty squished, which is part of the reason why I added the plaintext version on the side.
No.2885
I was about to note, it looks pretty silly. But it works, and that's what matters.
No.2886
It might just be a limitation of chart.js that other competitors resolve easier. I used it because it's user friendly and easy to set up but highcharts, plot.ly and apexcharts are all more serious versions of the same.
In the new design I can account for switching to a better service.
No.2887
Is .html5 on /f/ the same as 4taba's ZIP format or just a single HTML file?
No.2888
>>2887no, it's just upload of files, put into plaintext. Only thing that's served as content is flash which is on a separate subdomain. 4taba's the best place to handle runnable content.
No.2889
Meaning that I don't intend for Kissu to compete with 4taba. Adding new features to vichan feels like progress, but it's actually just bogging the site down with barely maintainable crap. kotatsu is more specialized in focus than general purpose vichan so have to do more work in refining kissu to the minimum needed feature set.
No.2890
That said the idea of having kissu and 4taba share content between /f/ boards is an interesting idea.
Kissu would mirror uploaded content to 4taba and allow users to update to it from here.
This way kissu gets better system and 4taba gets more use from here
No.2892
I could probably do this through a bot service without concern over weather or not a GoLang+Mongo rewrite of the Tinyboard/vichan core ever happens.
No.2893
>>2863Was trying to fix something in the citation system once and commented out something for unicode characters. I'm not sure I remember why or what I was fixing. I made a bunch of strange mistakes in the first few months.
Uncommented it and things seemed to be working fine but I haven't added it to the server yet.
No.2894
Anyways. I'm full capacity on things people want me to do and my productivity is at the floor right now.
- Update banners to track clicks
- Give 4taba system of thread downloading(good practice for NGINX routing and Ruby)
- Finish blueprint for Vichan's frontend redesign
- Fix citation bug
- Fix issue on 4taba where html5 doesn't work in replies
So cosmetics, edgecases and new features are going to be getting the shaft until this list is full.
No.2895
The reason I'm focusing so much on the software right now is because two things need to be done for kissu to expand. Better front end behavior and a second main board to focus /qa/'s content.
No matter what I try there's no system that lets /qa/ get above 1.8k views/day(give or take adblocker numbers) before things start becoming problematic with staff or other users. I'm tired of Idealists who think that everything can work on /qa/ and there doesn't need to be a separation of content.
Endlessly working on the software because you can is egotistical, but vichan is a bad compromise between dynamic behavior and linear behavior. This needs to be taken as far as is permitted to dynamic.
No.2898
>>2895I'm not sure how many people really disagree with you about potential future growth being limited by trying to work with only one main board, but on the other hand there's the question of what a good time to split the board would be. I'd probably wait until around summer to test your split idea since it seems there may be a lot of people working in universities. I determined this by how the most active period on the spinoffs happened around when spring break was supposed to be going on and quarantine had just begun. Probably not the best idea to implement a split immediately when the board's only getting ~100 posts a day on average.
Also I remembered how you wanted to make the quick reply more compact in the past, and I though that maybe you'd want to try it in a way more like how 4chanX implements it, and maybe make it a bit wider in the process. Tried making a possible design, but I'm not sure where the new reply button would go, and it seems a bit too wide.
No.2899
I'm throwing all of the old systems into the trash and using it as reference. Stylesheets may change a bunch too. Likely will be something like that, but more expandable and modular. The old design promotes a rigid view of what's allowed and not. Needs to focus on users rather than admins.
And you don't seem to get it. No one seems to get it. Heightened board activity is related to only myself and whoever talks about kissu outside of kissu. Nothing you say about 'the prime time activity slots' matters. It's just you pretending that results will fall into your lap if you procrastinate long enough.
No.2900
The idea of focusing more on users rather than admins also suggests that many new features of the site will come through the UI rather than the server. So it needs to be built in a really modular way. Each segment needs to be a removable chunk of information
No.2901
This is passed the stage that I've planned out. The thing that's good about 4chanX QR is you can remove anything or add anything and it will still feel complete.
The middle and right versions.. If I were to add a poll form to it what would I do?
All that comes to mind is dumping them into the container, but the 4cx approach suggests using pop outs, new windows or messages to indicate new things.
Good design has to come from not just how it looks but how it will look in future
No.2902
>>2901I'm a bit confused, but it seems like you have a good idea of how you want to approach a more 4cx-like QR.
>>2899I guess you're right that your advertising did help board activity, but I was just noting that it wasn't just kissu that increased in activity over that week or so period, but most spinoffs did. Also I'm just skeptical about trying to advertise more before you have kissu updated since I worry it may have people thinking kissu isn't stable or something and you losing posters. Not to say that it will happen for certain, but it seemed like activity sort of plunged after the first time you changed how things worked and that's still the only lead I have to go on for why it happened.
No.2903
>>2902like, In 4chanX you click something and things happen. In the default vichan you click things and type things out. If you want to design something interactive it's better to think about how to hide information in good ways rather than lay it out on the page. I don't have an idea, butI know what works
No.2905
The majority of people here, and on imageboards, want to die. They are more interested in murder suicide than they are over life. If someone comes up to me with a strong sense of will to live and calls me a dumbass I'll accept it, but all I see are cowards.
No.2906
>>2905I'm not trying to speak to you in riddles, but from what I've observed if you pull in non-permanent users and make major changes to how the site works it may make them worry for the stability of the site itself. So I have no worries for you inviting more people here and trying to make kissu more prosperous, but I fear that you may be shooting yourself in the foot and lose all the momentum you build up if you do it too soon and scare off the posters you hope to attract.
No.2907
>>2906By this I mean advertise your heart out, after you make your update to make kissu stand out.
No.2908
>>2906yeah, that's correct. I don't plan on doing it too soon. Using new software is also a good selling point to get people who left to check out things again too. However, people who leave because something doesn't work the same are cancer and were never there for any reason other than meta.
No.2909
>>2908>people who leave because something doesn't work the same are cancer and were never there for any reason other than metaI disagree with this point, when you advertise people to come here over other sites you are essentially promising them a better experience compared to the other site. While you may have the best of intentions while updating the site and don't see it at all like a bad thing (and neither will any of the permanent posters here), people that are coming just to see who may not be all too familiar with the site may take away from it that the site is unstable or may not be around in the future, and therefore go back to where they are comfortable and believe things to be fine.
No.2910
Like, take for example the "no javascript and no phones" people.
Have these people considered that integraring a native screen reader could be beneficial to the blind and this would only be possible with JavaScript?
Or those with limited control over fingers are probably very happy with how a phones voice to text system works?
Who cares about ideologues when there are more users to be found by doing things right.
No.2911
>>2909If it increases usability then whatever.
At the same time if the concern is hardware can't keep up then it's a real concern of usability.
People who leave because of change can go back to their IRC.
No.2912
>>2911I can agree with you that people who already decided to stay here and leave just because of change can go to their ircs. However, I think that with people who are in the consideration process of what boards they want to post on it's a bit different. They're looking for a place that they can feel comfortable on and maybe massive changes to how the site works direct them more to the other boards they're considering.
No.2913
Although considering what you've already said none of this discussion really matters if you don't plan on advertising until you've finished your updates to kissu
No.2921
I am unable to post images on any board.
I am puzzled by this situation.
https://files.catbox.moe/yjz0c3.png No.2931
Would there any objection if I were to merge 4taba and kissu's /f/ into the same storage location yet still be retrieved on separate sites? 4taba would get additional post rates on /f/, kissu gets a better software for handling html5 and flash
>>2921made a change right as I went to bed and broke image-posting
No.2932
For the eventual and probable mod UI I'm going to think about completely dropping the idea of a mod mode browsing UI and focus more on the selection of items from lists and searches.
This isn't foolproof but it makes actions more deliberate. In an ideal system that is high risk I think there should be multiple levels of barriers in place to reduce the damage of password leaks and prevent accidents. I browse a lot when I'm tired and occasionally press on D+ when trying to hit something else. This brings up the confirmation page. This system of moderation is error prone. There are other things such as changing the number of pages on a board causing a mass wipe of posts. Vichan has a lot of accidents waiting to happen.
A system where a mod has to type in the post number, select the area of text that lead to the decision and finally go through a confirmation is safer. A D++ or D+ operation could possibly have to be reviewed. Reports are on a queue that you can view.
The downside is not being able to see as much IP information which makes it harder to get information on who prime users are. Could be compensated by an alternate page, but I want to stay far away from the mod browsing experience of vichan.
---
This actually reminds me that I haven't considered how banned users will be treated on the UI redesign at all so I'll have to draft up these components again and see where it fits into the design of existing vichan bans.
No.2935
Hey V, could you edit pic's link to an earlier date? The current one is from after it was hacked, I can't remove it because I forgot the credentials.
This:
https://web.archive.org/web/20110807135304/http://shirky.com/writings/ would work.
No.2936
>>2935yeah sure. I'm going to be making an update so i'll do it then.
>>2934guess I'll stick the style select at the bottom then
No.2942
done with banners, so back to this task.
No.2944
the current vichan ban's page is post.php so will delay designing this use-case until mod tools are being worked on.
No.2955
clicking on the kissu board link now refers to the "kissu software overboard"
https://github.com/ECHibiki/Kissu No.2957
that only happens when captcha gets double submitted
No.2959
that only happens when captcha gets double submitted
No.2960
Can't replicate, but found out the captcha doesn't work with noscript so that's interesting.
I'll try some tests
No.2961
I'm going to call it user error. In ideal design the captcha would be moved from the frame into your text box.
I'll take this into account with the new design. I'm drafting up actions right now.
No.2966
non descript errors are a vichan specialty... I guess it ought to check for thread existence first.
No.2967
Crazy, the blueprinting never ends. I get into sequence diagrams only to realize that I had missed some things in the class component diagram which causes me to think about how the implementation should be and so on.
There's just so much in vichan along with my various modifications that the schematics get more and deep. It's required or Things will be missing in the release version, but it's so tedious. Hoping that I'll get to coding on May1, but 60-80 use cases is a lot of diagram and something of this scale can't be winged at without foresight.
No.2968
motivational drive is also still sitting bellow average. Hopefully move out kicks that up.
No.2970
>>2969Fixed it, but the font I chose for this theme causes some embeds to break. That was a fix.
https://kissu.moe/qa/res/35621#37763The CSS ought to be using CSS Grid and Flexbox since it's not 2010 anymore. When the three main themes are put into SASS guess i'll do this.
No.2971
Draft architecture documents for QR, Options and some of Posts done.
Remainder of Posts activity, Threads, generic items, SSR serving, User generation, double check for missing use cases to do.
After this have to go over these draft architectural documentation and make them into a final version I can autopilot my way through.
Text level descriptions only will be done if they'll make it easy to design otherwise documentation will be solely through the UML architecture designs.
No.2984
In regards to /jp/, I assume vtubers count as 2D, given it's not been deleted. But is there a point where it stops being 2D? Such as doxxes, IRL pics, etc. Those are fairly common in the /jp/sphere.
No.2985
>>2984If it's about the actor and not the character then it's 3D. Some leeway given though.
No.3012
>>2557It was a css issue. I'm looking at how to get the QR form to show up in mobile but it's seeming to be a wierd javascript issue.
No.3089
I've been curious, what's up with all the automatic proxy bans?
They're surprisingly frequent, but I don't see it impacting any board.
No.3098
State diagrams for 42 use cases done. Covered most of the scenarios for the QR for, posts and threads and options.
Will be planning generic items(banners, board lists) and the revised home page items next.
Leaving me with planning/expanding on component generation, how the threads get made in the SSR server and client side.
No.3112
blotter may completely vanish in favor of news feeds.
If you think about it, news items can handle all global blotter messages and actually give a use for that idea that other boards haven't.
Board specific messages can be done with stickies and capcodes.
Blog linked news items can be commented on anonymously allowing easier user feedback
No.3114
currently am discussing this on Steam channel
No.3118
>>3117That looks pretty alright.
No.3119
https://pastebin.com/kndnVVXgSteam has some annoying bugs where it deletes logs seemingly randomly
This is most of the discussion
>>3118it's a bit of a departure from tradition.
No.3120
>>3119Yeah, a lot of items typically from the top get moved to the collapsible right.
This would mean they're accessible from anywhere in the page, right? Or would the panel stick to the top-right of the page?
No.3121
>>3120I'm not sure if the top bar will be fixed or not as yet.
collapsable in a similar way as it's done on sankaku
[some nsfw content on page]
https://chan.sankakucomplex.com/post/show/17876435The idea is for these items is to behave like they would in frame mode so when you change pages they'll still be around and won't de-load. Except it'll be javascript based so I can still modify the contents. For the homepage [new thread] will vanish and things like that.
No.3122
>>3120wtf I meant left
>>3121I wouldn't have it fixed, it'd be more comfortable for it to move around
and what's collapsible in sankaku, the tabs? the left-side panel seems static
No.3123
>>3122i was confused, you said right so I assumed the top
like
https://4taba.net/all I was thinking. It's fixed there
No.3125
I think this is terminology confusion.
When you say fixed in web design it means that it's fixed to a position in your browser, not the page
No.3126
>>3124yeeeah, exactly like that
>>3125ahh, my bad then
No.3128
I don't know how many sequence diagrams I've done, but there's probably only 5-7 ones left. I need to check over my list again.
When this is done there's just the SSR and page generation to plan out and finalizing the Sequence and UML diagrams.
From the looks of it, to have SSR work with some more advanced catalog use cases(seperate lists for filtered and not, ordering by parameters, generating pages based on options) will require Kissu to write it's own general purpose SSR package that builds the Components from cached sets of strings. I'm not exactly sure of what it would do yet.
The API also needs to be greatly expanded. I'm probably going to do these changes to vichan and not get started on more rewrites at this point in time. Maintain focus on the front-end+SSR until it's in a good place.
No.3129
So programming will likely be in these steps:
- Expand Vichan API as the specifications require
- Design SSR server to generate individual and composite components as strings
- in tandem with options pt1
- Browser must transition through pages as a featurless SPA application
- Options modify behavior pt2
- Behavior actions
- Options pt3
- Stylesheets 1,2,3
Hopefully the programming will be a cakewalk with all the planning that's gone into it
No.3130
>>3128>From the looks of it, to have SSR work with some more advanced catalog use cases(seperate lists for filtered and not, ordering by parameters, generating pages based on options) will require Kissu to write it's own general purpose SSR package that builds the Components from cached sets of strings. I'm not exactly sure of what it would do yet.This sounds like it might be overkill. If you can do it, and you know it won't cause undue stress on the server (or have a way to switch to client-side rendering if it becomes a problem), it would be neat. But if you want to support people without Javascript, it would be sufficient to build the page once with default options. On a user's first visit, you could serve them the default, then set a cookie to indicate Javascript support. If you see the cookie, you could send them a version of the page without the HTML and have them generate it from JSON data sent with the page (to prevent a second request from being necessary). That has the problem that rendering can't start until all the data has arrived, but you could fix that by sending the data not as one big JSON chunks but as one JSON string for each post/thread, separated by newlines, which the client could render in batches as it sees them. Another possibility would be to set the cookie only for people who set options requiring a non-default page build, which might decrease load times for people who leave the options as default. And if someone turned Javascript off without clearing the cookie, you could have a meta redirect in a <noscript> element to a ?js=no page which would turn the cookie off when loaded.
On the other hand,
>builds the Components from cached sets of stringssounds like it might be useful anyway so that you can rebuild threads when posts are added without having to rebuild every previous post.
No.3133
>>3130It might be overkill and I can get away with the server dumping cached posts into the delete form. In a revamped version, the cache will contain posts and the frame to the webpage will be dynamically generated. Or perhaps variations on the frame and posts are in memory and the server does the combination rebuilding items as required.
My ideal is for all items to pop up at once on the page and not do any hybrid dynamic-static loading, but caching an entire rendered page means that certain things are going to take up way too much memory. The cache will have to hold smaller components, but if we're to stay with the all or nothing idea of SSR(your entire page is rendered solely through the logic of React components) then we need a React SSR package to fill in the gaps.
That's release v2.0's major concerns or something anyhow
No.3134
My idea is that noscript support will be a side effect of an interest to make the site still feel like a static page with the benefits of dynamic script driven behavior. This meaning that prerendering pages are going to be the default way of doing things and if need be we'll make some new tech or forks to accommodate caching in greater levels of detail, performance and complexity.
I'm expecting that the React modification to vichan might end up being the largest consumer of my dev time and the vichan core remain untouched since this will probably be kissu's bottleneck. It might be possible to swap out vichan for something else though.
Since the front end service is completely detached and is planned to be entirely through localhost communication performance issues might be fixable through cash. Kissu gets more storage space and it's own private SSR server. But using money to escape problems isn't the best idea.
No.3165
>>3164if it's higher than usual where are the new posts...
No.3166
I don't like looking at posts as a metric because
1) It encourages low quality posting for the sake of numbers.
2) Every n views will statistically convert into a post.
3) A view is a much more honest metric because no one games this on an imageboard.
The days above the line are fast days. The days bellow the line are slow days. Typically. Today was a really fast day and there was an exceptionally high number of views. The large cluster below the line was the early half of April which was noticeably slow
No.3167
4)Lots of lurkers means the user pool responding to threads is getting switched around a lot and responses to threads have a better chance of being fresh and having unique aspects to them
No.3169
>>3168day 0 to day 61
non-ublocker views involving full page rendering
No.3171
>>3170Currently I have 74 sequence diagrams in my documentations folder implying that I've probably gotten everything I pointed out here
>>2962 No.3174
>>3166The evidence for success under these rules should be unique IPs
No.3176
>>3170>In memory thread hiding(4chanx will have to be alternative in meantime)this I find to be the most non-delayable delayed feature. people really like to be able to hide threads
No.3178
>>3176probably so eh. Guess I'll put in a throwaway version.
No.3200
test2
No.3205
Would it be possible to add a new posts counter to /all/ like the one in the title on individual boards?
No.3206
>>3205yeah, I can look at increments and decrements to this
<=
The only issue is that sages will increment and sages don't bump in /all/ so I might have to enhance this counter to also track some more arbitrary information such as number of sages, noko and regular posts on kissu.
No.3209
I'll complete this tomorrow since it's a requirement for later.
No.3217
>>2965fixed this along with a few other issues yesterday
https://github.com/ECHibiki/Kissu-Vi/releases/tag/Original-Kissu-v6.1.1Going to make a post on overboard changes
No.3227
starting on /all after i eat
No.3232
Seeing >>>/qa/38475 reminded me that it would be nice for Kissu to have similar quality of life posting features. Having interactive buttons for markup is a considerable reduction in the barrier to entry for new posters (Yes, there is already the message, "Markup tags exist for bold, itallics, header, spoiler etc. as listed in ' [options] > View Formatting,'" but it's obviously far less intrusive for them to be simply included in the post form rather than needing to memorize the markup tags). Likewise, features such as previewing the what the final post would like upon posting would be especially nice -- there have been a handful of occasions where I've forgotten the "/" to close out a tag, that would have otherwise been caught if I could see my post beforehand. I would also imagine that it'd be very helpful for ensuring that SJIS art will render correctly. Similarly, it would be nice if Kissu could adopt the "edit" feature that Tohno-chan has. Again, I've made misspellings and phrased things wrong or awkwardly more times than I can count.
This is neither here nor there, but it would also be nice if each board could include a brief summary of allowed filetypes, max filesize, and max dimensions as is typically customary on imageboards. To my knowledge, only /f/ has a list of allowed filetypes and other such information otherwise needs to be learned through either personal experience or mention from other users or V, in particular.
No.3233
>>3232I made options listed in a drop down. You can see options in the [view hidden opts].
It's better here because I've translated it and don't expect people to know what sage means.
Previewing is planned in the final design as a replacement to 4chanX's image dump box which shows the image
BB tag dictionary is useful, but there should be a better way of doing it than stacking items.
It's also a bit of a rare situation and devoting a block of the post form to something rare is possibly poor. It has to be evaluated.
But on the other hand... if the bottom message telling people where to find the BB codes is intrusive then the text you circled at the bottom is intrusive as well and something easily ignorable.
-Ideally kissu would handle every filetype, it just takes time to get them working and make sure they keep working.
-I don't think people are incapable of determining what works and what doesn't
-This issue can be resolved by error checks before post submit such as what 4chanX does meaning no need for clutter.
Ideally kissu would have an edit feature and I suggested it last year, this is a hard add though. I believe someone has pointed out that this feature has risks(4chan's problem with monitoring CP resulting in the need to limit the delete function) as well and with risks comes more implementation and need to improve mod tools. Adding in some features that would improve user experience are classic cases of expanding too fast and without any foresight into problems.
No.3234
I think that an FAQ page would resolve the information related issues and the idea is for an FAQ and rules page to always be available in the eventual frame-style-side-bar.
I would need to see some proof that something is incapable of being understood by either the FAQ or error notifications. If something isn't inherently clear without a text wall then it's probably poor design on my part.
No.3235
>>3233>Ideally kissu would handle every filetype, it just takes time to get them working and make sure they keep working. handle every image file type.
No.3236
>>3233Personally I think that sage works better than hold back. One because it's more common knowledge among people that post on imageboards, and secondly the translation doesn't exactly explain what the option does. In fact it may cause more confusion for those that don't know japanese since they'll be more familiar with "sage" meaning to not bump a thread, not "hold back"
No.3237
>>3236then the point is moot and it's better handled by an FAQ page or trial and error than toggles.
I was planning to remove that feature anyways
No.3238
Also is there any point to repo anymore, seems kinda reduntant
No.3240
Redundant is not a synonym for pointless. The word is superfluous
No.3241
>>3240Sure, whatever word works.
No.3242
It's a joke feature, and besides, it makes your text orange on dark-kissu theme. That's worthwhile in of itself. It's an Easter Egg.
>>3241It's not whatever word works. You either speak English or we speak made up languages and have confusions over what is trying to be said.
No.3243
>>3242Oh, I guess you're right the orange is neat.
Wait....
>re·dun·dant>adjective: redundant> not or no longer needed or useful; superfluous.I was using it right...
No.3244
>>3243Nice cherry picking
Redundant has a few common uses of the word that conflict with the meaning of superfluous
c : characterized by similarity or repetition a group of particularly redundant brick buildings
2 : profuse, lavish
3 : serving as a duplicate for preventing failure of an entire system (such as a spacecraft) upon failure of a single component
Vs superflous which was more accurate to your intended meaning
1a : exceeding what is sufficient or necessary : extra
b : not needed : unnecessary
2 obsolete : marked by wastefulness : extravagant
No.3245
conflict is maybe not the right word.
Redundant is a superset of superflous. Redundant means repetitious use of something causing pointlessness, but superflous just means pointless
No.3246
>>3244My point wasn't really that superflous was in it's definition (although that was the first definition to pop up when I verified it through google), but rather that the first part fit what I meant. It was initially intended to be used to indicate that someone wanted a thread reposted on 4/qa/, and somewhere in the dev plans it used to be that it was going to work automatically. However, now that 4/qa/ has been abandoned the option no longer has any use, hence redundant.
No.3247
this is dumb. Believe what you want, but if I don't understand your meaning then it's going to waste time like hat's happening now
No.3248
>>3247You understood what I meant, but it was a more stretched definition of reduntant, which I guess if you are very strict in what constitutes meaning then it's not the technically correct use. However you're right this conversation is meaningless delete it and edit my post to have it say superflous instead
No.3249
>>3125 Is a case where using web developer terminology and English language conflict. There are others. No point in editing it and making this exchange even more confusing to others.
In any case, it seems like a really nitpick concern that you'd have to go out of your way to find a problem with. Hidden behind two layers of interface wouldn't the bigger problem be that you never knew it existed in the first place?
No.3250
>>3233>intrusiveI hardly think it's intrusive. Rather, I think that it's just often overlooked since it's not part of the quick reply window.
>I don't think people are incapable of determining what works and what doesn'tSure, it just helps to know in advance rather than learning by trial and error. For instance, a new user might be unaware that they could MP4's and opt to only post WEBM's.
>This issue can be resolved by error checks before post submit such as what 4chanX does meaning no need for clutter.That's fine, but I really don't see it as being clutter any more than seeing an image's filename or size are.
>I believe someone has pointed out that this feature has risksPerhaps. I suppose you could add a time window to allow editing the same as 4chan has a time window for deletions. As for CP, the edit feature should really only be extended to the text of a given post, so unless they're adding links to unscrupulous websites and such, that shouldn't be too much of a concern.
>Adding in some features that would improve user experience are classic cases of expanding too fast and without any foresight into problems.Indeed. Ideally, these are just long-term suggestions since there isn't any immediate need to address them.
No.3258
>>3257It's working. Thanks!
No.3272
So i guess I'm back to planning out more use cases tonight. /all/ things and some suggestions on explaining functionality.
I'll have to take a look at some mobile functionality too. I was thinking if I get serious about this I'd make a Recat Native mobile and desktop App, but some issues of usablity will have to be cosidered with the top and side bar
No.3273
Since I'm begginging to get requests for things that are planned to be implemented, or related, I think the system should be im good shape.
I should just architect the 2.0 features as well to make sure it all works together
No.3274
The other main thing is that I'm aiming to make the archive no longer resemble 4chan. Instead it will be a hybrid themed like desuarchive, but will only show the OP per thread so still similar to 4chan. the goal of this is readability and familiarity to other websites. This is also a place I can put ads without ruining user experience
I may throw in a search feature and see about long term storage.
No.3275
>>3274I'd be cautious about throwing up advertising even if it's just on the archive. You throw up the wrong kind of ads and it may get people to throw a fit
No.3277
>>3250>BB tag dictionary is useful, but there should be a better way of doing it than stacking items.>It's also a bit of a rare situation and devoting a block of the post form to something rare is possibly poor. It has to be evaluatedIn regards to my previous statement I think that I'll treat it a similar way to how I plan on doing file validation.
1] When you enter markup or > into the comment box it will alter your message.(this probably means no more text areas and I have to find my own implementation using <div contenteditable>
</div>). I'm already using custom checkboxes so could take that further...
2] Markup will be handled by an expandable menu, or perhaps a seperate window, using nice tooltips(
https://puu.sh/FG25v/6ce3d99620.png). The design could in general make more use of tooltips to explain the iconography
So, I still have to plan out 13 or 15 more use cases since I also should plan for future things as well
sigh..
No.3280
>>3278Anonymous 05/04/20(Mon)04:49:14 No.3278
this really is a wall of text isn't it
No.3281
>>3278>>3279The text in these aren't necessarily accurate since it's hard to write to scale, but objects I believe will be roughly that size.
No.3282
Of paticular note for files will be a hybridization of 4chanx's quick reply features with the plus4chan styling of no-buttons.
Of patticular note with comments will be that text gets colored depending on the information you put into it.
Also: since it is an editable div and not a text area pressing M will open up a roll of markup options which can be clicked to add in.
This is another bunch of work, but since we're dreaming here and I'll end up completing it either way might as well go all in...
No.3283
>>3277>>3278>>3279>>3280>>3281>>3282This is the list of posts in the thought chain for reference. I will probably do all the work onto demo.verniy.ca for live reference to how things look. That way there can be fast critique on design.
I might need to delegate some board management while I work on this...
However, I still have to plan out the design and sequence diagrams for the unplanned 15-18 use cases.
No.3289
this thread is very hard to load on mobile... I'm going to add infinite scroll to threads, 100 or 200 posts per load maybe.
this is also a concern with "Click to expand" but I suppose the expansion can be staged such that it doesn't dump 500 posts into the browser per click but 100 or 200 per
No.3290
For /all/ instead of having a catalog it will have an alternate summary mode which will behave like the overboard on the vichan homepage
No.3292
>>3291I'd say it may be a welcome feature for the future in case people want to use the overboard but may not care for certain boards.
No.3293
>>3292then why not just let people pick what they want to be on the overboard
No.3294
>>3293Isn't that what the feature would allow?
No.3309
>>3294It's a variation in mindset and how you want the user to react.
Mostly the issue is that the way it's currently implemented is bad and makes someone feel shameful for hiding content.
No.3320
>>3128this might be easier than I made it sound. I think it would also make things faster once the cache fills.
Potentially this solution would allow for a complete noscript browsing experience where the server quickly and efficiently generates your page through cookies. Though this isn't what I'm going for. I don't have interest in tor clients.
No.3321
switched to cloudflare and site is faster.
No.3324
Today I'll try to get a decent CSS for a score counter on normal, hover and click.
Get as many as the 23 additional use cases done as possible, including score counter functionality.
No.3335
We're going to be using some techniques in
https://codesandbox.io/s/l91xvkox9l?file=/src/index.js:1274-1278 to handle an markup QR box idea. Hotkeys should be added in as well.
No.3336
50% of the new usecases have been drafted, implementation ideas and how to do them with sequence diagrams. These were markup, caching, mobile theme, and file verification things.
Next is things are the tooltip system, sorting, new ideas for weaker devices and ideas for how some of the new features such as overboard and score system will be treated.
Going to spend the next 3 hours working on a CSS for the score counter
No.3337
Working on the +1 counter's made me realize that if posts are stored in the cache then they're going to need to be triggered for update somehow when a score gets submitted.
I had removed from my draft a notification system which would trigger rebuilds. This needs to be readded because of how I was doing noscript visibility for polls and the new feature.
No.3338
By my math, a 200mb cache can fit every post on the site without any compression.
Each post is ~1.073KB(589kb/549 posts), so 200MB is 186,417posts. If they're stored with 256 bytes of accesor data 150,489 posts. The site's all time post count is 43,827 so amazingly the server could hold in it's max cache size all posts, hide stubs and catalog threads in kissu history and still have some room left over for a few archive posts. With gzip compression this thread is 328kb so I guess something like 0.59KB per post in which case we're probably getting in the range of an entire site being cacheable with a 200MB cache holding 334,756 posts.
This idea of caching posts is amazing and with my implementation it's not going to be too hard. If there were some way to initialize the cache on startup that would be even better, but you could do a full fledged noscript site while still accommodating dynamic page generation.
No.3369
DNS records.
Refresh dns soon if doesn't work now
No.3389
>>3388funny, react-dismiss doesn't even work on my phone.
No.3390
Forgot about my NSFW warning use case.
Some governments and by extension providers don't like if you don't have one of those.
No.3391
I think that's every use case possible that anyone would ever want.
Assuming 4chanX can stay compatible this plan offers a level of features on the same level as 4chan, if not a bit better in some ways. The only issue then will be CSS.
The next hurdle is doing the same thing again but with the generation of every item from server, startup and page changes.
This should go by quickly when the basic ideas are in place. It's a matter of making sure everything will be compatible. This will verify that everything is as it should be.
By that point in time it's a matter of just double checking there were no mistakes and I can get onto coding knowing exactly how it should behave.
No.3409
>>3274>>3275patreon advertising might be nice there
No.3410
>>3409This sort of in house advertising is probably the better way to handle things.
The 10% fee on patreon is better than the markup cost on games, but I wonder if I could get better fees and contribution by setting up my own payment processor to handle donations or maybe some product(sales tax though). It's another complication I'll deal with when the site has it's own unique appearance and am begining to rework other parts.
No.3411
>/jp/ = anything (2D) allowed, 5 image threads
>5 image threads
what does this mean
No.3412
>>3411I think up to five images can be posted. I was wondering where all those images came from.
No.3413
"5 images max threads" may be better
No.3414
>>3412>>3413why the heck would you limit the number of images in a thread?
No.3415
>>3411>A noun used to describe another noun is called an attributive noun or a noun adjunct.>>3414I can't phrase it in a convincing way. Like, when you only make a limited number of toys people are more encouraged to hoard them for their rarity. Putting limitations on certain things produces a psychological effect that requires you to fight around the limit.
Each image becomes more precious and it encourages people to make new threads often. It prevents things from regressing into image dumps and blogs, it forces people to be creative or leave to /qa/, /spg/, /megu/ or /f/
No.3416
>>3415oh wait a second nevermind i just realized it was /jp/ only
I forgot this site is a "/qa/ spinoff" and not a "/jp/ spinoff" and i just typed in /jp/ out of habit, i remember getting the "you're in the wrong town, stranger" message or whatever it was.
No.3417
>>3416jp is a legit board, but the pop is kind of small so there has to be some variation. Otherwise it's redundant board
No.3433
Working on drafts for generating the custom error page first. SSR and client side hybrid. This means the basic 404 header, sidebar, topbar and banners.
Getting The SSR working with the topbar is a headache.
In any case opening this phase of planning is just dependent on me focusing on how to get the right information to locations and not trying to figure out the best way to do ideas. If I sit down and focus I might be able to do it in a day but no promises, anime to watch
No.3435
I have a sure solution to any registrar issues should they ever come up(I doubt they ever will because kissu is a different flavor and they're giving even the racist sites benefit of the doubt), but they're going to stay in my head until I'm developing them. Even then, you probably won't even realize it's a countermeasure and I won't point it out. They might even just stay in a folder on my computer until 8ch spinoffs are dead or it becomes a high demand feature for the site. Bigot chans don't deserve any saving grace and the maintenance cost of these features might not be worth it, especially not when the backend of the site could change a lot this year.
I'm simply saying this because I still get a few concerns over the drama effecting Kissu.
No.3437
>>3415Looking at how few replies the average /jp/ thread gets, I think five images are far too many, even if every user attached an image too many threads wouldn't reach that cap. I don't see any sort of conflict over image usage. Maybe just leave image replies for other boards altogether, unless this is part of a long term plan.
No.3438
>>3437well the point is for the replies to be lesser in number but number of threads high in quantity.
It makes sense to lower it though because of the currently low population.
No.3440
>>3439do you turn off scripts on phone?
I thought I had it set up to work in this scenario, but it seems I over wrote it.
does it show now?
No.3441
>>3440javascript is on currently
No.3442
I tried some changes. If it doesn't work I might just use iframes even though they're annoying
No.3443
>>3442happened recently, upon clicking [Reply] to a thread from index view or clicking from catalogue it leads me to a blank page
No.3445
>>3443got the same problem on /poll/ from /all/
No.3463
>>3439Threads and board pages should work for you now otherwise it's something more annoying.
Error page generation planned out, going to do the home page.
Think I'm close to the point where I need to make some pages see the things I've misunderstood.
So after I think through the homepage with diagrams and make another diagram for home and errors. I'll produce the working versions of these two parts.
If they're really kickass, I'll put it on the main site.
No.3469
- To go along with the Tsukuyomi theme of this imageboard the front end is going to be labeled Kissu. It's the front page of the website, therefore deserves to get the namesake. I'm considering naming future aspects such as the post-api server Hazuki and the mod server Luna if or when I get to these parts.
- I think that these software additions aren't me designing for fun, but are important to the site having a distinct identity from other imageboards. I think that there would be no point pushing for kissu to be something special if it looks like a "build-your-own-imageb
urger" site made on lynx or vichan-forks.
- SSR has a lot of info on more fixes to generation issues should it be required in the future. The guy in this example made a mistake in his code somwhere resulting in huge numbers so it looks like this will work out when used in combination with the caching solution.
https://stackoverflow.com/questions/34728962/react-rendertostring-performance-and-caching-react-components- Visual draft to the HomePage looks really nice to me and takes concepts such as active threads and manually set featured threads to create something reminiscent of 4chan and early YouTube when I was still in highschool.
- Next message in this thread should hopefully be the one where I say I'm starting to code the first two pages. More work to the score feature will be done when the blueprints for the main server are done.
No.3470
Is the disclaimer on /megu/ supposed to pop up every thread?
No.3471
>>3470mobile bug i never got around to fixing
should be good now
No.3472
>>3471oh nice. thought it was my umatrix settings that were breaking something.
No.3477
alright, I'm not getting any more clarity from the design by planning this far ahead(feature creep if anything).
Going to start coding now in a 3 step process.
- Proof read the design documents for inconsistencies.
- Write code for the selected items(SSR Basics1, Homepage2, ErrorPage3, PagePage4, ThreadPage5, ArchivePage6, ArchiveThreadPage7, FileboardPage8, OverboardPage9, CatalogPage10).
- Upload it to demo.verniy.ca for it to get community feedback.
No.3478
I'll give myself 10 hours for each item as a rough ballpark so 100 hours or ten 10 hour days.
This might be too ambitious. But if the planning really paid off then this should be doable only thinking about implementation and no design.
I plan to release the error page and homepage before doing a bit more sketching in between and get feedback.
I'm hoping that the initial two pages will be done by Wednesday and will probably not look at the site for a bit.
No.3483
1 use case down, 117 to go
No.3484
Noticed a bug with the title post notification thingy. When posts are removed, the counter goes negative -- that much is known and accepted. New posts however don't properly reset the counter, but seemingly "absolute value" and then add X number of new posts since the removed posts. Would've taken a screenshot but I didn't anticipate that sequence of events happening.
In particular, a poster seemingly accidentally made a thread. That thread also had one reply. The OP then deleted the thread, causing the counter to go negative (-2). I then clicked the tab and refreshed the page. After that, a new thread was created, instead of the counter going from 0 to 1, as it should have, it showed up as "(3)." Checking the homepage post log confirmed that only one post had been made, however.
Not sure what to make of that, but it's probably safe to put at the very bottom of your to-do list.
No.3485
It's buggy, but I might fix it in 3 or 4 days after I release a rework of the homepage and scoring on megu 1 or 2 days after.
It works through a vichan api addition I wrote and it's pretty primitive. I'm going to be ripping it all out and replacing it with something else(golang api service)
No.3502
it's a good precaution.
Almost finished my server, Tomorrow I have to finish the generation and fix logic errors. Then ensure that it's browser renderable and start building components and functionality
No.3507
SSR code for simple pages has been redone This being the cache update notifier, caching, retrieving and serving pages. Much more readable and maintainable system. Just need to fix it's bugs now and get it to generate a real page. Then begin working on components[Error404Page,Banners, Headbar, NewsItems, Sidebar, SummaryMode, HomePage, PopularThreads, BoardList, PartnerFrames, SPA, Stylesheets].
These are going to be tested with dummy .JSON files since there isn't yet a way to obtain that info on vichan. Instead of expanding vichan will being taking parts out into an API service which it can notify to pull info from the database and write new pages to it's folders.
More serious testing or perhaps automatic testing might be considered after the first releasable to the demo site since the caching behavior is hard for me to predict only with my logging system.
Thread specific SSR such as sorting and removing posts needs to be added, but this is an expansion on top of the existing functionality.
No.3508
Might end up being that I finish these parts on Thursday. I'm not sure how hard the components will be.
No.3514
remove hyperlinks
if someone wants to enter another website at their own risk from here they should copy&paste said link into their browsers >:[
https://www.examplevirus.onion/.html No.3515
Would it be possible to have the banners use a proper HTTP redirect instead of meta http-equiv="refresh"? The current implementation means I can only open the link in a browser, and not, for example, mpv or some other program to view the media it's linking to.
No.3516
>>3514It reduces usability for actors with limited motor control and is an annoyance for everyone else.
>>3515How do I replicate this? I'm using the Laravel redirect method. I can see about changing this to PHPs header or some unknown internal setting on Laravel when I need a break from React.
No.3517
>>3516Disregard
>>3515. I was only looking at the response body and thought it wasn't setting the HTTP header, but it was.
No.3518
>>3516>It reduces usability for actors with limited motor control and is an annoyance for everyone else.i dont care. i dont want to accidentally click on fbi pedo raid links
No.3519
>>3518lets say I hypothetically add a hover preview to links instead, with stored thumbnail, or uses some already existing service(google mobile friendly test) to capture a screenshot instead.
Wouldn't that be better than removing a feature people use?
No.3521
>>3520In a month I can make it so that you'd have to double click on links to open them
No.3522
>>3521wouldnt it just be easier to remove it all together?
No.3524
>>3517For reference, it turned out that mpv was trying to open the link as a .gif because the URL ended in .gif. I fixed it by adding
--script-opts=ytdl_hoo
k-try_ytdl_first=yes
to the command line arguments.
No.3525
>>3521I would rather open links normally, so if you do something like that, please make it optional.
No.3526
>>3524alright, I'll remove this issue
>>3525obviously
No.3527
it'll mean each post needs to be given a data object for links, but it's a functionality I think some people might like
No.3528
>>3519To be fair, Anonymous does have a point if a link were to point to a site hosting CP. By extension, if Kissu were to save a thumbnail of such a website, it would technically become a child pornography distributor. At least, I'm fairly certain it would be under US law, since US law only protects hosts against [u]users[/u] posting CP so long as there's some level of moderation to remove it. Obviously, an automatic system falls outside of that definition.
No.3529
>>3528Anonymous' point was "no".
The idea was a third party service generates it. Storing them seems like a poor way to do the idea. Double click is probably the best way to solve the concern, but a preview would help too.
I might look into a preview solution since it seems like a useful feature too, but there are concerns. Likely what I'd do is have a post deletion also effect URL preview storage.
No.3530
>>3529Anonymous' point was
"i dont want to accidentally click on fbi pedo raid links" No.3531
>>3518You can put this in User CSS to disable all user-posted external links:
.body a[rel="nofollow"]:not(
[href^="https://kissu.moe/"]) {
pointer-events: none;
}
Verniy, it would probably be a good idea to add a CSS class to user-posted links so that people can disable or style them without potentially affecting other things on the page.
No.3532
>>3522It runs against my design decisions of increasing accessibility. Double click, even if it's harder to implement, is more in line with what I'm aiming for. The software shouldn't discourage people for who they are or what their platform is. Removing links would be working against my design.
>>3528Hover preview is an existing useful functionality working on only one type of link in the page(cite links). It can be expanded further and become a more uniform action that people think of when they see an underline. The (embed) system native to 4chanX is kind of not a good choice here because there's no plan as yet for inline comment nesting and I'd rather discourage huge threads to sway things away from the use of generals, at least until the site is too big.
In the topic of inline behaviour, I'm seeking to move away from this in general and the coming update focuses more on subwindow based expansion rather than inline. This is the design choice I'm trying to run with.
No.3533
That said, subwindows might be harder to work with on a mobile platform and I might do some of that[inline expansion] in preparation for a phone application.
No.3534
Looks like all the basic infastructure is in place.
SSR and SPA routes are unified
SSR caches single pages
SPA serves fast
SSR hydration passes with localstorage being used after constructors
Flux architecture for component communication
Notification system
Skeleton of the 25 components required for error and homepage functionality.
Only thing unaccounted for is stylesheets which will begin to be ported when done
No.3539
There is this white flash blasting at my face every time I click on a thread w/ dark theme on. I'm using Firefox btw.
No.3547
>>3539known issue that's been around forever..
I tried to fix it with the guy who had the issue and I think it was concluded that it's not 100% fixable.
There might be something to about:config
https://support.mozilla.org/en-US/questions/1269392I'm also redoing the Stylesheets so they compile into one file. that might help.
No.3548
In dev news, all of the stage's items are being generated in a layout.
No.3549
>>3547Will setting the stylesheet server-side based on cookies help?
Also, in Firefox there's a menu you can use to select stylesheets under View > Page Style. The alternate style sheets show up in that menu on 4chan but not here. I don't know if selecting a stylesheet that way reduces the flash in Firefox, but it might be worth looking into.
No.3550
>>3549i'm thinking it will. This is what GNFOS does by only having one stylesheet.
No.3551
Toggling tree view on then off in >>>/qa/40050 breaks it, presumably due to the link to another thread
No.3552
>>3551curious, do you use tree view?
No.3553
almost at a point in the major update where I can push it to the side and work on other issues in this thread and things I would do. Things like upgrading the API generation, refactors, stylesheets and thread mode planning can be done on the side.
So, fixing the poll issue from /all/, tree mode(might be discontinued until inline post expansion is considered), imageboard scoring, possiblly having trash board delisted from search engines
No.3554
>>3552No, I figured it might help in the longer thread mentioned, but it doesn't work how I'd like it to for posts which reply to multiple posts (I'd prefer these multi-replies appear as a child of every post they mention rather than only the first).
No.3555
>>3554A potential problem is that not only the post gets duplicated, but if there are replies to that post, they get duplicated, and a reply to two duplicate posts gets quadruplicated, and then you can have posts that show up 8x, 16x, 32x, and so on. Might not happen in a typical thread, though, so imposing a reasonable cutoff on the number of times a post is duplicated might be enough.
A simple improvement that could be made to putting a reply under the first post it quotes would be to put it under the last post is quotes (last ordered by post number, and excluding any futurequotes). That way, before reading a post, you would have read all the posts it referenced. And it would handle the common case of
post 1:
post 2: >>1 reply
post 3: >>1 >>2 reply
correctly.
No.3556
Also, backlink inlining can be a nice substitute for quote threading, especially if the backlinks are at the bottom of the post. One of the features I've thought about is a way to select a particular post and inline all the backlinks to it recursively. Sometimes you only want to see a particular part of the conversation in thread view.
No.3557
>>3555>>3556These all seem like fine options, I especially like the show-on-last-quote idea. Not sure how you could handle the case of chronological replies though (such as
>>3556 )
No.3558
looks like I'll have to implement a json history stack when navigating in order for back history requests to be handled in a pseudo static and SSR consistent way. The browser and react router doesn't store page state to history so unless I do it for it then the request is met with a white error screen.
The caching is nice though, takes 2ms to generate a home page page after cache. 20ms with an uncached home page.
No.3559
At the point of needing bugfixes+small implementations, an improved API, stylesheets and more JS item interactions for the basic components (bars, banners, posts-previews, navigation and homepage items). Posts are drafted for the homepage previews, so when done all that will be left is representing threads, QR and related options.
Posts are having their HTML semantics reworked so that they're easier to read after being parsed and I can legally alter vichan and tinyboard copyright out of the spotlight.
I believe that there will have to be a fair amount of modifications to vichan for 100% functionality anyways so the custom software will inevitably be a complete replacement of everything except perhaps the database and the way it stores/archives ban information.
I'll be making those adjustments on the side of other issues said in this thread and backlogged additions to the site.
Sodane, fixing polls in the overboard and various other concerns.
Live versions and notification of those changes are announced to donors
No.3560
undefined index: embeds
No.3561
imagine modifying 3000 line files of ifelse blocks or functions without a namespace, imagine this being the standard for imageboards for the past decade.
No.3562
dammit a few scripts have broken now.
No.3566
all seems fixed
No.3572
>>3551reading
>>3555 it makes me think that the style of treating posts as a tree(or list) of connected nodes is flawed to either requires the reader to be accustomed with the preexisting system(non intuitive UI) or approximate it with redundant data(exploitable behaviour).
Ideally the posts should be visually represented as a graph somehow. That way no information about the structure has to be assumed by the reader and the index doesn't become bloated by approximations.
I don't think this is possible to do clearly without thinking in 3D space Making use of Z indices and a completely dynamic container form that also manages to impart full information while scrolling. But I have no idea how to represent this.
>>3566Delisted those boards, added score counting, fixed poll viewing from the overboard. I probably won't add these changes to the repo as yet.
I have an idea on how I want to take kissu's software and really focus the experience, reduce my work load and do away with some of the problems that 4chan inspired imageboards have. I think that this unsaid solution is only possible with an SPA which enables rapid page changes.
I'd rather put it into practice/draw it than explain and I have to finish off the homepages first.
I list 12 issues that need to be covered for the the navigation bars, homepage, errors, basic styles and navigation to be completed/easily expandable. Going by my work rate for the past few days that's a 2 or 3 day job but giving myself 5 until Monday. After which I'm going to add some 4taba features and begin working on golang to write a better API service.
No.3574
4taba features being the prototype system for Kissu's moderator service in Rails and archive downloader for threads in golang service as a way to get accustomed with it's systems.
Rails
>Action Mailbox makes it easier and more reliable to work with various email clients;Very useful for mailing moderators when actions are needed
>Action Text — you can now easily use rich text content in your applications;Using React in authenticated environments is too much work, probably will use a different system. Likewise concerns raised in an earlier post about the flaws of browsing in moderator mode, especially for mobile platform mods.
>Multiple database support — new Rails come with the new simple API for multiple databases;Good if I want to prototype on SQLite, move to mysql and later adopt for mongo.
https://www.ideamotive.co/blog/state-of-ruby-on-rails-web-development-2020And golang is fast.
No.3576
looks like the counter can't do IPv6. aSet the length too low
No.3577
fixed from phone
No.3581
how does it do on the other pages?
No.3587
>>3586I'm hoping it will be fixed when the site pulls thumbnails from embeds instead of an iframe dump
No.3591
>>3583Safari browser acts like an idiot so if you're using that it might be the case that some method doesn't exist.
I'll try and find what it is a bit later
No.3593
I'm almost through with designing the generaton of posts in an XSS safe way. This is part of a system for the two(and a half) ways of post previews and citation tracking which are going to be on the homepage.
Post structure has diverged a lot from vichan for the purpose of html syntax improvements, I will probably need to lend a hand to get 4chanx to work again. Imagehover is something that is best handled by a thirdparty.
These home page use cases pull in concepts from the entire application so getting it working is basically like designing 90% of the app at once.
Believe it or not the only system that has no work to it other than drafts is the QR form, however, there needs to be a major API overhaul which will be another diversion, but I might be able to get away with designing the front-end on dummy JSON files and do that later so that people could try it out.
here's an old and broken version, it's nothing I should show since I'm only keeping it up because it has some bugs I need to remember to handle(this application crashing is catastrophic to user experience).
https://demo.verniy.ca/ No.3594
>>3593For 4chan X, it would be useful to get a working demo of the post HTML in the index and in threads. The more time between me knowing what the post HTML will look like and it getting rolled out, the better. Hopefully most of the changes other than dealing with the navigation will just involve writing new CSS selectors, but you never know what will break.
Also it would be good to have an indicator on the pages so that it can tell when the new software is in use. Perhaps something like specifying the software version in a <meta> tag. For Tinyboard, it checks for a <script> tag containing the regexp /\bvar configRoot=(".*?")/, but it would be nice to have something more reliable for Kissu.
No.3599
>>3597Relax, no one is going to prosecute you for clicking a link to an imageboard that happened to have some idiot spamming CP at the time.
But while we're on the topic, it's a good idea to add "noreferrer" and "noopener" to the "rel" attribute on links.
In other news, that site lost its original clearnet domain, surprise surprise.
No.3606
>>3599They have no follow, but it still looks bad to be linking to CP
No.3608
>>3594alright, I'll work with dummy json and do server modifications later
No.3609
wait so is /jp/ just another 2D random now? What is the point of having two 2D/Random boards
No.3610
>>3609The idea for /jp/ got rolling in >>>/poll/170 but that thread is more meta than actually discussing the idea at hand. Also, IIRC, the poll was originally phrased "Create an new board for "un-/qa/ things," or something like that. At any rate, the practical difference between /qa/ and /jp/ is that /qa/ is for "smart" threads and /jp/ is for "stupid" threads, but it's not exactly like there's any rule saying it has to be that way.
No.3611
>>3609Incorrect, /qa/ is mix of meta and Japanese culture. /jp/ is 2D random. /spg/ is vaguely Japanese culture from gravure to covid threads.
Please do not get them mixed up.
No.3618
>>3609/jp/ is the place where you can post not so amazing threads or threads of that nature can be moved to and bumped in without worry of pushing down more quality threads. It's a good way of addressing the issues a lot of people had with kissu at first about how it was a bit too fast for their liking or that some people were hesistant to just create threads to their hearts content because they didn't want to flood the board
No.3620
don't wanna fix my transpiler errors... just wanna watch shakugan no shana all day..
when I've got bugs and basic layout setup I'll make a test page where you input query fields into a URL and it'll output a rendered post.. This way myself and others have an easy way to test in isolation from the site and other people can create fake posts for fun.
No.3627
does anyone know why chrome doesn't have a contextmenu api like firefox?
No.3628
>>3539following up on this
dark reader extension fixes this so yeah I don't have to burn my retinas anymore.
No.3632
>>3631I don't follow, are you saying that vichan's user-time-zone thing isn't correcting properly? I never tested this.
I didn't accommodate for user post times in my perception of caching so if such a thing were to be improved on in the future then it will end up being the same split second adjusted to the users timezone
No.3634
>>3633original video didn't load on my FF browser.
That lag has to exist if something is generated on the server. It can't know what time zone you're in ahead of time so it's a binary decision of being accurate to the client session or being consistent.
Though, there's a way of pulling it off, it's too complex in implementation.
No.3635
though, if you're actually not in EST time then it's doing no one good except East Coasters
No.3654
>>3639Default themes are wierd
No.3659
Resolving navigation issues was actually really easy. React Router has built in history API to store states, just had to make a minor modification to use object redirects
https://reacttraining.com/react-router/web/api/Redirect/to-objectSo I'm going to fix up the layout and make it usable, then work on the post generator.
No.3670
I lied, there was actually an annoying bug(or missing functionality) that was tripping it up so had to work directly with it's history API.
Last things before I do another update are post generator, post/preview styling, some window positioning to cursor and a race condition on that can get the preview stuck open.
No.3671
Regarding navigation, please make sure holding shift, control, alt, or meta or pressing any mouse button other than the left one bypasses your event handler and performs the normal action. Otherwise people won't be able to open stuff in new tabs/windows/etc. when they want to.
Also, this may be the case already, but navigation links should have a sufficient URL such that if you open them in a new tab, you'd get the same result as if you clicked them.
No.3672
>>3671bad synchronization leads to wierdness.
that concern should be fine though, but I'll double check
No.3688
4chanx breaks inline image expansion on kissu
I commented it out so it's fine now but just wanted to let you know
No.3689
>>3688It works fine for me. Can you give more details? What did you comment out?
No.3691
>>3690Doesn't happen for me. What browser and userscript manager? Can you post your exported settings?
No.3692
>>3690Also are there any errors in the console when you click one of the thumbnails?
No.3693
>>3691firefox nightly and violentmonkey.
here's my exported settings
https://pastebin.com/cyDiHaui>>3692well the thing is the problem went away on it's own once I uncommented those two lines to check this. weird.
No.3694
Post scores don't show up properly when expanding threads on /megu/
No.3698
https://demo.verniy.ca/https://demo.verniy.ca/post-gen?com=sample%20commentsample0commentsample%20commentsample%20comment&ext=png&board=cBanners require ublock being disabled.
Some comments:
- Post generator still not finalized, but you can see that the html structure I'm going for uses definition lists, lists, flexbox and CSS grid. This causes the structure of posts to be altered somewhat. A download button and native reverse imagesearch will be placed at the bottom of images. It's the intention for the native script to handle refined actions such as hiding through the context menu. In firefox options are in the menu, for chrome it's a submenu.
- There are also some obscured fields that are moved off the page for crawler algorithms to identify segments better
- The page functionality missing are things that will be needed later anyways. Such as making the thread level previews focus on the linked post on hover, right click menus to allow people to pin previews to the window.
- Bugs that I haven't yet touched are mostly on mobile and it's associated theme/page variation shown in the picture.
- A not very well tested feature is the notification systems. I've tried to get the webworker notifications setup, but couldn't figure it out and I don't have a good testing environment for this yet without the API server. Desktop notifications for posts added to the site work though and redirect to the page, but you won't see them at this point in time.
>>3694I have some time again to touch on this and see if I can find out what's wrong with the banner loading
No.3701
>>3698Can you add a datetime attribute to the <time> element so it's easier for userscripts to parse?
No.3703
going to modify the delete-move function to filter links if comment matches regex for CP words
No.3704
Or maybe have it do a true delete on pattern match. I'll see about a system when I've made some of the request changes to demo.verniy
No.3706
init_stylechooser is throwing an exception on /all/ because document.getElementById('lowercontents') doesn't exist, and because of the way ready() is written, this causes everything else in onready_callbacks to fail to be executed.
Can you give this a quick fix? It's breaking quote hover-to-preview on /all/ which means I have to open every thread just to see what people are replying to.
No.3710
final functionality for /home. Right clicking, handling adblock for banners, minor formatting and additional friends.
https://demo.verniy.ca/I'll revisit it when I begin working on stylesheets, but no point in focusing on it too much. It's fulfilled it's role of working out core functionality.
For now the goal is to make /post-gen be able to output a fully functioning post. This means both contents and behavior. Server side and client.
When this is done I have to handle insertion of posts into threads, thread insertion into the frame and manipulations such as hiding and organization... I believe when this aspect is done that the major things to do will be modifications to vichan(archive adjustments such that it's possible to treat them as individual boards[though not a priority ghost posting could be done]) and an API server that will in the longterm take over vichan's tasks as needed.
No.3711
>>3580the top one is an image, bottom one an iframe... the main thing that comes to mind is maybe that it's being blocked because banner is often used with advertisements..
I had this problem with demo so I added another subdomain art.kissu.moe which is the same as banners
No.3712
changed mod deletes such that any possible URL will get removed.
No.3713
>>3710Regarding the archive, I would like it a lot better if the URLs of threads didn't change when they're archived.
No.3714
I think deleting the wishing-death-on-rioters thread was the right call, but was there a reason it wasn't moved to /trans/?
No.3715
>>3713like 4chan
>>3714because the OP deleted it after he told me to delete it.
No.3716
>>3714it's up on wayback if you really want it
No.3731
>>>/qa/42288
It's of my opinion that there are certain features that I want to work out before advancing.
I'm going to finish off the post generation to handle all scenarios and use vichan to prototype some ideas.
No.3739
getting back into the flow, there's a lot of details i wrote down
No.3752
ended comment parsing and inline readmore. Have to do polling, CSS and update demo(Up Monday?). After this is thread construction and manipulation.
No.3753
kissu will switch from using canvas chart.js for polls to something with svg that's easier to react to page size changes.
https://plotly.com/javascript/ with
https://github.com/plotly/react-plotly.js/#quick-start looks more capable and somewhat up to date
No.3760
Doesn't seem as if there's an answer to the question of plotting data for imageboard posts. They all have strange behavior when put into size-variable containers which actions which resize the box. Plotly just keeps growing and the react package doesn't have the resize feature that's vital for mobile.
Plotly package also doubles the js filesize and transpile time... seems like a bad package and I think I'll just stick to the text I was using for the noscript version. If important I'll make my own bar graphs.
The only thing left is CSS layouts and some samples of various behaviour before the next update
No.3762
>>3760Is the next update after this the API, or do you mean actually live testing it?
No.3763
>>3762no, currently is post things(polls(requires API for completion), file expansion, layouts, OP vs reply design, markup). Next is thread related things(construction, arrangement and behaviors). Also fileboard and layout variants.
everything that comes to mind without looking at any outline are
- Backend/Client thread generation
- Fileboards
- Catalog and other layouts
- Thread ordering
- Thread searching
- Post&Thread deletion&reporting
- Previewing
- Staged thread expansion
- Infinite scrolling for threads and pages
- Thread Hiding
- Hidden pool viewing
- Board selections
- Thread Updater(requires API for completion)
- Notifications(requires API for completion)
This leaves the QR and API which will probably end up hanging over to next month. Also the Mascots and Custom CSS to be done at some point.
No.3764
I'll likely keep vichan kissu running on a subdomain as well. The new software will probably be such that weaker computers have a tougher time. Until there's a reason why it can't be on a subdomain kissu we'll just have two software running off of the same database. Reasons might be too much traffic and a shift away from supporting no javascript to pure/limited server side rendering
No.3773
https://imgur.com/vdyebRl.pnggenerating a page of 650 posts is comparably fast as here. Post cache it's obviously just as good.
When it's generating individual posts we'll see if it keeps up.
No.3776
there are some bugs I need to fix, but just a look at functionality and performance.
As you can see, it has the same time swap delay
loads 650 posts.
https://shorturl.at/wMY23https://shorturl.at/lMQX6I'll make 4 samples,
- reply no image,
- OP poll with video
- YouTube video reply
- Audio reply
some issues seem to be happening with context menus on chrome, min width on reply boxes,
No.3785
without having implemented the threads yet, the display of posts/images/polls and etc. will likely be like this on release. The only good way to do polls at the current time is through text. Likely the future will see me write my own poll graphics...
Stylistic CSS will be definitely be altered, but this is general layout.
Standard long reply with sage
Link
OP poll with image
shorturl.at/fkT04
Youtube embeding
shorturl.at/mBSVW
Audio files
Link
So with this set into place I'll start generating threads for the overboard(the pages, then threads). After this do the functionality.
No.3786
>>3785Just for clarification that "Read more" is just for on the overboard right? When you're actually in a thread you won't see that will you.
No.3788
Also not sure if you noticed, but it seems that sometimes when you grab onto one of those youtube embedded windows it doesn't let go.
>>3787It'd be annoying to have them persist in threads.
No.3789
Alongside that there's no verticality to the dragging, but I'm guessing that part is a work in progres..
No.3790
>>3789the issue is the window is too small
No.3791
>>3790Ah, makes sense. Also I think you gave the wrong link for audio files.
No.3792
Looking good now, all I really have left to complain about is the style of the pop-out. Think there needs to be a bit of an emphasis on how it is overtop of the rest of the page
No.3793
updated it
There's still more stylistic work to do, but I'm going to put it off until there's a final application
No.3794
so first thing will be an overboard page.
Thinking about priorities and making everything function clearly, I probably will build the overboard and then go into the QR form so that the overboard can be used for replies and thread creation.
No.3795
>>3785>shorturl.at/fkT04Typo? This link is just redirecting me to a foreign-language Facebook page.
No.3796
>>3795hash collision maybe...
https://bit.ly/3d9BYMNIt's the most temporary demo example anyways
No.3799
its far past spring when are we getting a summer board?
No.3800
>>3799summer equinox is the 20th
No.3802
>>3799The Summer solstice. Duh.
No.3810
progress on overboard generation pretty fast with current groundwork in place. Hoping that I'll have the page working by the time I go to bed.
No.3813
on the topic of the overboard, why the /f/ header on top?
No.3814
i'm not entirely sure how the themes work... they share configuration with the boards but because of that when you set board specific configurations it bleeds over into themes.
for example there are some mod pages that always have the Christmas css up and the ban page too. It's just been something that hasn't annoyed me
No.3828
Something I've noticed about the overboard is that mascots are on top of post boxes instead of behind them so text gets obscured by cute girls. Arguable on whether that's a bad thing, I guess.
No.3833
>>3828considering their position on the screen it's probably for the best
No.3839
>>3828wasn't sure if it was problem or not. Different than what I intended, but not sure if good or bad.
>>3810https://www.youtube.com/watch?v=AnkEL4xpbuQAdvanced SSR use cases are a pain to debug and the global subconscious is currently in a depressive mood
No.3842
doing this in react has some real interesting performance advantages. It feels much smoother, partially because I don't have to deal with the CSS flicker and because it actually reuses the existing HTML objects whereever possible
No.3872
Did you accidentally update the homepage to include /megu/ when you added /sum/? Because /megu/ posts have been showing up in the homepage post feed if you haven't noticed...
No.3873
>>3872is this good or bad
No.3909
I run LynxChan. The RAM it uses is laughable. But then again it's not kolhchan.
No.3910
Have to finish off some CSS layouts and finally give it some more interesting post examples.
should be up by the end of my day, will post again later.
Next schedule will be something like: QR => API => stylesheets => finalize.
No.3911
demo.verniy.ca updated. Some issues on Chrome(inconsistencies with CSS tags and some strange React behaviour), you should use FireFox to view this.
I figure I'll get to these issues on the side of other tasks. The examples also aren't too interesting as yet and I was going to modify them to show youtube embedding, but running into some bugs that I'll have to get to first. The featureset doesn't seem to be 100% compatible with kissu yet either, it's missing the ability to handle the summary tags used on the happenings thread and I haven't yet added in greentext and the ability for people to set their own local text coloring.
Some things I want to tune are the way I'm handling catalog. Index style isn't yet behaving completely as I want to. Also the "inline" cite nesting has a bug I have to fix and I think that it might want to be optional depending on how intrusive it is. There are also a lot of inefficiencies slowing down the site and console.logs left in.
What's nice about it, the caching system works really well. 70ms to initially set up 10 threads(build running in development mode so a bit slower than production) drops down to 10ms after cache and each one being individually built means no issues with hiding requiring a recache. It's javascript, but still maintains the classic HTML feel. It has all the features of kissu with more. The overboard wasn't tacked onto it but built with it in mind.
No.3912
>>3911oh yeah, mascots and customCSS built in. It shouldn't lack anything kissu has that users are able to do.
So for the next and hopefully last month of this software, I'll do 3 things in conjunction
- Build up the QR form to be one of the most helpful on imageboards
- Expand the pages to handle the remaining compatibility features and resolve bugs. Eventually going into CSS themes when the QR is done.
- Build an API server to handle API changes, decaching when posts, polls, or scores get sent to the vichan post server.
No.3917
chrome bugs resolved
No.3921
>>3920may be hard, but it sure looks neat
No.3922
this fucking feature has me stumped for a simple solution. everything about it is getting more and more complicated to implement. I'm at the point where I'm not sure if it would be less hacky to do it in a canvas tag or find DOM workaround to the issues I'm having with making a contenteditable replicate a textarea
No.3923
think i've finally gotten it figured out
No.3924
qr comment box at point where really buggy but I can work on real time styles again and trust(hopefulky) that everything will work
https://imgur.com/V04oMbl.pnghttps://imgur.com/mRHewbq.pngthe only thing i've lost at the moment is holding down keys to repeat action
No.3928
It looks as if the switch to CloudFlare has gotten rid of the majority of spam(or maybe the site isn't targetted as much anymore) so I'll probably end up discontinuing our IP scraper for the time being. This will mean that theres less degregation in board post speed over time
No.3972
How much left do you need to do before you can start applying the update to smaller boards for final bug testing? Or are you going to throw it up everywhere all at once
No.3973
haven't gotten there yet but probably this board for a bit to work out leftover issues then apply to all
No.3974
the next content updtate should be Wednesday. I'm aiming to fix all the bugs today in user functionality. Tomorrow to finish off anything leftover and work on layouts.. add some more compatibility with vichan and some sidebar positioning options along the way...
No.3975
this leaves improved API, stylesheets, handling content submissions and final upload.
API server will probably be relatively quick if I forgoe any login pages and do all changes through the server so should get done by end of month
No.3976
come to think of it, I'll probably put the new version on a subdomain until it's fully compatible and ensure it doesn't have any catastrophic bugs
No.3977
>>3976you should probably put it on a few of the small boards main domains so that people can give some immediate feedback
No.3978
>>3977no, because there's a chance I overlooked some infinite loops which could crash someone's browser so until it's verified to work it shouldn't be forced
No.3989
hopefully by the end of the month this will go into public beta development after which all the site's content will be mirrored onto demo for people to use and evaluate the design choices.
To get to this state I should hopefully have an API server which communicates with the front-end server and a port of our 3 main stylesheets.
API server development components
- Login page and dashboard
- build API pages from vichan DB on request
- Decache select items
- Have posts/reports/delete/scores/pollvotes upload to post.php or others
- Track and give notifications on replies(possibly implement webworkers if time exists)
- Modify vichan to support a generic board global search.
- Thread updates and catalog new thread notices
These 7 items hopefully can be covered at an average of 1 per day leaving some time to work out the stylesheets.
No.3990
>>3980A bit of an issue. Opening the text preview with a quote or yen alongside regular text will erase the normal text.
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