[ home / bans / all ] [ win ] [ qa / jp / cry ] [ f / ec ] [ b / poll ] [ tv / bann ] [ fr / tab2 ]

/b/ - Boson Technology

Also known as Boson /g/

New Reply

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

[Return] [Bottom] [Catalog]

File:22aa648aac7dea988f7776d884….jpg (671.02 KB,2362x3496)

 No.4243[Last50 Posts]

Last issue established problems with Kissu's software and the need to expand into custom written user interfaces, moderation tools and customization of existing aspects.

As of this point kissu's experimental UI is in a beta state(all functionality planned out for the current revision, usable, but buggy and unstable).
The experimental UI's purpose is to bring a 4chanX like environment into kissu providing it with dynamic content that reacts to the user's needs and offers a more responsiveness to the board changes(notifications on site content and your own). A list of features will be set below in the next post.
What we have now is a server with read only permissions on the vichan database to create it's own API pages for the React front-end+server.
While it handles poorly on 800 post threads, this is likely due to poor optimization that I'll fix in the coming weeks. That being said, there is a huge improvement to viewing experience in music threads such as https://beta.kissu.moe/qa/thread/47339#qa-47339

Kissu was also targeted for the first time by script spammers with preexisting knowledge on the workings of Vichan, even going so far as to script spam my banner program with account generation. Though we managed not to cause any interruptions to people's activities on Kissu it required a lot of energy from the staff and required me to get a moderator in addition to Cool. This giving us 22 hour surveillance over the actions happening on the site.
I also felt that time was up for /megu/ which I was uncomfortable about. The new board /ec/ offers a more arguably cultured/artistic board devoted to cute and sexy image sharing.
In the future we will need more moderation tools and I think that the following 3 will put kissu into a state where it's in full control of it's own agenda.

The current three tools that I feel will help kissu and not be too hard to implement are:
- Perceptual hashing: http://blockhash.io/
This will target people's avatars and repetitive image spam. Cloudflare already provides this for child sexual abuse material(and even forwards offending IPs), but for our own purposes this is needed to put more stress on spammers obfuscating their images. In the very least, when combined with a captcha, their spam becomes less recognizable and more comedic when they have to put noise into it. Nonetheless, I think that it's worth pointing out that no captcha or spam gaurd is unsolvable and there needs to be other solutions.
- Archive Backups
The archive on kissu doesn't yet function as a backup because post information gets wiped when it gets knocked off of the pages. Though the archive isn't planned to be a feature of the experimental UI, it is still useful for moderation and restoration of the site after captcha breaking spam attacks.

Still, what if the spammer is completely automated, breaking the captcha, flooding every second, spamming every single thread on the site… then what?

A year ago I made the proxy scrapper program that searches pages for IPs and submits them into the ban table.
This is a solution that catches 1 or 2 ips every so often. But what if it needs to be expanded to eliminate large swaths of IPs and thuroughly deny access from any webserver proxy? Well, it might be worth considering how 4chan handles rangebans. A new function should be added to vichan whenever the system or mod bans an IP address that potentially eliminates subnets when a certain threshold of bans are hit. If the IP scrapper sees that a number of IPs are banned between it will make the decision that the subnet is unusable due to spam and automaticly issue a ban. Naturally this will cascade upwards to when a certain threshold is hit. This combined with filter rules for autobanning will create a system where script spammers are getting consistently shut out and maintain the speed of vichan which starts slowing down when the ban table hits 1000 entries.
In addition to this, it means that mods don't have to put in as much thought into combatting spam making it easier for these active users to contribute to the community and not police it.

-Real backups
Kissu needs an automated backup system. This is not complicated to do for the database, but images will take more effort. I could pay the server provider some money for this, but unless there is a crash, I'll find a manual system, or accept recommendations on this.

These will be done using Vichan since there will be way too much unnecessary wheel reinventing otherwise


File:24e1ccf1c8.png (858.28 KB,1920x969)

For https://beta.kissu.moe/ I've forgotten to add the API information necessary to trigger inline expansion. It's in a really unstable state right now as well and my priority may be kissu's security for a bit, but I will list the set of features.

- The experimental user interface allows for no javascript viewing of content such as polls, scores and posts. Posting is not currently in the plan, but could be in the future.
- A sidebar now contains most of the important navigational tools and page information
- Banners rotate when clicked, but banner ads work as normal.
- News, boards and partners are included into one object that is dragable
- Summary tab keeps track of all new posts on the site. It also can notify you whenever a post has been made on the site.
- Global and board search allows you to easily find what you're looking for
- Makes use of FireFox's right click menu and additional tabs in chrome
- It's a single page environment, meaning it looks like you're navigating the site but are always on the same page. This is theoretically faster and means that unless you are doing an application layer DDoS I don't have to worry about you clogging things up.
- XSS proof. There is only one instance where html may be inserted dangerously meaning user security is easier to handle.
- Some information is generated based on cookies meaning there is a possibility for a very effective no-javascript experience if demand exists.

- You can decide what boards you want to see
- You can create your own custom quote characters
- Mascots still exist
- Custom CSS still exists(and you can create your own shareable custom comment tags)

- Active threads shows you which threads have been last responded to
- Featured threads are admin curated best picks going on in kissu
- Hovering over will generate the full thread, and right clicking allows you to pin
- Partners are given their own dedicated space in recognition of their efforts.

- The overboard allows you to eliminate any board you want
- Allows for paged or catalog viewing
- Works fully with no javascript users.
- The overboard is sortable
- The index watcher will now behave like boards and ignore sage.

Threads in general:
- Threads and posts can be completely removed so you don't have to worry about even seeing the stub.
- Threads are also sortable(creation date, bump order, last reply, reply count)
- Threads (will) expand inline
- Index watcher still exists to notify you of new posts

- The fileboard continues to exist now with the new file expansion method

- This is the more disapointing aspect. Currently there's no way for me to effectively render graphs without making the script huge and slow. The text is just colored, which leads to some strange situations.
- However, it now works with no javascript, but you can't yet vote.

- Posts can be expanded inline meaning text walls do not dominate threads
- Custom insertion of style tags. Typing [s test]text[/s] will give your text a span with the class of test. This means you can use custom CSS to a greater degree. For security, no transparency is allowed and urls, if not already, will override.
- Yen text and custom quote
- Replies to your posts will notify you when you have a response

- Clicking a cite will now open up a new window that creates a reply chain. This should make it possible to reply to large threads and at a glance tell what the discussion is like.
- Citation hover brings up a preview like always

Files, Embeds, and Flashes:
- Images and gifs expand like always
- Videos(mp4 and webm), audio and flashes open up in a new window that allows you to browse the thread and close them at any time.
- Embeds are given their own window that allows for a larger view than previously.
- Embedded videos are also given thumbnails making it much easier to load pages such as the music thread.
- Hover over a filename to reveal it all

Submitting Posts:
- The reply or create box will follow you around unless you dismiss it(no longer have to worry about pressing back accidentally)
- The comment is under the WhatYouSeeIsWhatYouGet principle, or rich text. If you type in a quote the line of text will turn green. If you type [s custom]text[/s] then the text will be given your custom tag
- Post Previews allow for previewing how a post will look before it is submitted
- URL and Media submissions are combined into one element
- You can modify the filenames of your images by editing them in the given box
- Post submission on the overboard is multi-staged meaning you write up a post, then choose the board then if it's a poll you write up the poll.
- Replies to threads allow for a post queue to be created


List of bugs to resolve
- Fix API to create index expander
- Home Decache
- banned.php can be used to check bans
- /ec/ missing and options
- Circle for taba is wrong
- Handle situations with a moved file
- Hover preview for old style backlinks
- Rules and FAQ need proper files
- … sorting should be changed to bumps only
- Stickies not being handled properly
- Post Queue does not work(crash)
- Mobile should make use of text-areas
- Rich text has various bugs to resolve
- Rich text should handle legacy style formats
- Preview cancellation needs a better system
- Custom style security
- Home removes active threads on delete
- Reply count not being set
- golang sometimes does not write valid JSON(reason undetermined)
- Captcha not bypassing filter
- Capcodes not being set
- Mod icons not in a row
- Page list not in a row
- Spoilers, deletes, generic thumbnails not being used
- Reply notifications not being sent
- QR should handle quotes and thread numbers
- Handle HTML tags for summary and details
- Improve dragging of windowed files
- Article mode has width issues
- Tripcodes missing
- Cursor on ad hover
- Top bar tab not consistent with user choice sometimes
- Summary notifications don't lead to given post
- Summary notifications annoying when multiple tabs open, perhaps refine to board if not on home.
- 404 error not being created on 404 threads
- Whitelist token input
- Unexplained crashes
- Titles are inconsistent


>- Custom insertion of style tags. Typing [s test]text[/s] will give your text a span with the class of test. This means you can use custom CSS to a greater degree. For security, no transparency is allowed and urls, if not already, will override.

This sounds cool but you might want to add a prefix to the class names, or otherwise people could use class names for markup that clash with the class names used elsewhere, causing Kissu's scripts and/or userscripts to malfunction and maybe even causing malicious things to happen if they're clever enough.


Yeah, good point




Das a lotta features. Great job dealing with the spam, too.
>Clicking a cite will now open up a new window that creates a reply chain.
Like in 4chanX?


oh, heres one ive been wanting to mention but always forget. My laptop screen is small so if i ever have to solve a captchouli, the textbox to paste the code in as well as the submit button are hidden and i cant scroll down to it so i cant submit the code. ill take a picture of it next time it happens so i can show you

then, because that kept happening, i discovered that if the captchouli comes up i can just close the pop up window and hit the "New Reply" button and the post will submit anyway without me solving the captchouli


That's probably because the flood timer ran out, if it locked you into completing a captcha that would've been bad


I'd like to know what's going wrong. You can flick down to scroll the captcha, but it might not be very clear to do this.


let me see if i can recreate it real quick, im going to spam /trans/ until i get the flood message


/test/ will do as well


sure, let me see if i can recreate it. going to spam until i get the flood message, ill delete it all after


File:Untitled.png (1.3 MB,1913x887)

browser is acting weird. i did it here since /trans/ wouldnt let me post, i didnt even think of /test/ ill use that next time

basically this pops up and the bottom part is hidden, if i scroll down it moves with the window as the rest of the page scrolls. changing browser size doesnt fix it either

im not sure how i was able to post my last post either, i solved the captchouli and then mashed kind of near the one pixel you can see of the button near the bottom so maybe thats the fix


i see, it's not triggering the condensed version


I fixed a CSS rule so it should trigger a smaller version now when you don't have enough height.


File:a9c36a03fa.png (111.14 KB,2560x969)

>Like in 4chanX?
A bit different and more along the idea of trying to create microthreads. Instead of making the user manually open every link what I've been working on is the ability to create a chain that automatically does it for you.

This UI is an interpretation of 4chanX's customization and automation features.


First new anti-spam tool is last one I'd ever want to use.

Effectively blocks poster's IP ranges from posting until they submit a ban appeal.
This would probably be used if captcha got broken and someone was using a residential botnet,
or if I died and cool needed to keep the site running.

My preffered system will probably be an ISP check on post submit that locks someone using a webserver ISP, or whatever regex term is needed.


seems like you have to pay money to get this information in a timely manner(ie. not querying someone's website).

ISP detection would have to be done after the post. In this case it seems like a better thing to do after bans on top of an automatic subnet lockout to get better information about weather the IP is from a commercial service or residential area…


decided to make a filter using PHP's gethostbyaddr. It's a hit or miss solution to detecting if an IP is a proxy or not, but it seems to work in certain cases.

I believe it functions on a lookup table, so there might be ways to improve this


I also added a whitelist table which will allow given users to get through filters and rangebans on approval.

My final system of auto-bans is going to be the bans table condenser which will estimate if a range should be locked down or not.
This will be an extension on top of the GoLang API server(Hazuki) to handle scheduled tasks of automatically adding via proxy lists and optimizing the bans table.

algorithm as follows


Algorithm as follows

Need to program in the helper functions and figure out how to work with IP addresses in golang.(I did the factorial loop incorrect)


File:yesAbVW.png (326.15 KB,1913x928)

Die proxies, die


2 last topics of anti-spam are archive recovery and perceptual hashing


Hey, Vern, can you add in the ability to edit banners after you've posted them? There's been a few times where I've either wanted to update a banner or change the URL but been unable to do so without taking down the previous banner and uploading what's essentially a "new" one.


Archive restore is done, but it's half programmed on hazuki-golang and half on vichan(DB on api server, thread files on vichan) so I'll finish that off then move on to the perceptual hashing question.

After this, i'll leave mod tools until there's another need to improve them, but I think we have just about as much features as 4chan with the exception of better dashboards and management monitoring tools…

I'll see what it take when working on it comes up again, but it shouldn't be anything more than another option in the user dashboard


there's a function which checks if bans have expired and it seems to be doing that very inefficiently.

If I comment it out kissu can handle 160,000 bans easily, but with it on it struggles to post in under 10 seconds


oh man… it's Twig isn't it… the thing I'm trying to replace is attempting to build the entire bans table https://kissu.moe/bans-all.html
so it freezes posting because it tries to create a json representation of the data. I can't put it onto another thread because php is single threaded… that's messed up


Archive functionality is developed on hazuki-go to serve as a temporary backup. What's remaining on vichan is the index construction and the archive.json generation.
Archive pages are depreciated, but information about them will stay around(json files, html pages and archive as a temporary image storage). They're not worth the continued investment in for functions other than moderation.

The proxy-logger is still making rangeban guesses on the 160,000 bans, but I realized by formula for /17 subnets was too large meaning none will be done as yet… when it's finished and I've moved over the archive stuff I'll run it again to do further compression if any may exist.
The logger can do /9 subnets but this may be overkill, I've yet to see.
This experiment is mostly about seeing if there's a way to confirm posting from risky locations rather than locking out. Kissu's whitelist-anti-ban feature will help here.

When this is moved over all that's left for the anti-spam purposes will be a perceptual hashing solution. Likely this too will be done on Hazuki-Go which will communicate with http://blockhash.io/ or a similar functioning package within golang.
What will follow is more work on the revised UI, see about some banner program alterations(editting banners, perceptual hashing duplicate checks might be good), could even do it as a warmup, make Hazuki-Go less hardcoded and I need to start thinking about money so I'll probably be making a bigger deal of that again.


>Archive pages are depreciated
Does this mean you're thinking about getting rid of them? I hope not; I like to go back and read the threads I didn't have time to look at before archiving.


File:Screenshot_2020-09-02 404 ….png (257.99 KB,1907x798)

I've been wondering for a bit, but is beta supposed to be giving 404 errors on every page?


zzz there's a problem where if it sometimes writes the json files incorrectly and it means I need to manually fix them. So naturally the property pages for home, all and so on have broken.

{"banner":{"small":{"url":"https://banners.kissu.moe/req?s=https%3A%2F%2Fbanners.kissu.moe\u0026f=dKoWVekfJv0lMI4KOWQxptRUfMjYydNuiPzeuWQF.png","uri":"storage/image/dKoWVekfJv0lMI4KOWQxptRUfMjYydNuiPzeuWQF.png","name":"jacno","clicks":0},"wide":{"url":"https://banners.kissu.moe/req?s=https%3A%2F%2Fkissu.moe%2Fsum\u0026f=wNrMTVQVkXiPfvXuSUsI7umk4ENPcBk4ICrsoRL7.gif","uri":"storage/image/wNrMTVQVkXiPfvXuSUsI7umk4ENPcBk4ICrsoRL7.gif","name":"Ciuie","clicks":17}},"board":"all","title":"Overboard","title_descriptor":"All Threads","presentation":"overboard","new_post_counter":""}overboard","new_post_counter":""}

you can put that into a json linter to see what I mean. It might probably be a race condition where it writes chunks without locking first.

I mean by this that they'll exist so long as vichan is still generating HTML pages but I don't intend to put a lot of time into fixing issues around them.


File:Screenshot_2020-09-02 Over….png (192.01 KB,1626x991)

one more tiny issue…. this is the latest on /all/…


there being a seperation between what happens on the two servers means that occasionally when there's an issue with the API server this sort of thing will happen.

It's easy enough for me to fix… i'll do it in a bit, but things are going to break again anyways so take your time on this feature


on the archive issue, there's very little percieved support for doing anything other than basic upkeep on it. Creating a light version of it would be done(along with better no-javascript support) if vichan's HTML generation were to be fully discarded.


Range optimizer and estimator took ~160,000 down to 139,220 bans. Currently /17 isn't in the list, but that wouldn't knock out too many more. There are currently 1163 /25 bans

This operation likely took a total of 20 hours where the ban insertion is a combination of string comparison and golang's CIDR creation from string and associated net.Contains method with an IP and range,

The ban insertion methods are n * m time complexity comparing all bans against inserted bans whereas the optimization method is n * 6n time complexity where it takes a given ban, creates /9 /17 and /25(6 times) variations on it and checks it against all bans for whichever is contained within it. The comparison method also is built to take a string parameter and convert it into an IP every time, this can be improved.

This process of 160,000 * 160,000 causes it to take the time it did(~20hr) and likely there need to be an adjustment to the search method and the comparison algorithm. A binary search would make the complexity roughly n log n, by comparison 160,000 * 5.2, however visualizing this for a []byte is a bit more complicated and I want to get back to fixing the UI.


Just the act of sorting might be the fix and tell it to stop when items are no longer contained within the optimization range… In which case the O(n*n) complexity is inevitable, but a bit better. A binary search seems like the best choice here but I'd rather not go there for now unless necessary


These adjustments made it so that the entire process of adding 160k items and compressing them took an hour so with that done, kissu now has archive restore and a good system of removing IPs that are regularly reported to spam/public listings. If there are any mistakes then you can appeal them.


speaking of appeals and stuff I ought to program a moderator input bayesian spam filter because the current weakest link of the system where ips are whitelisted is the appeals form….
It's an old method, but I know how to do it easily… There may be more accurate modern alternatives that don't rely on neural networks.



File:1598382101421.jpg (125.68 KB,960x960)


seems like some boards such as /jp/ have a index rebuild issue on delete that isn't throwing any errors.
This isn't the case on /test/ though… I'm waiting for kissu to be backed up to my test machine so I stop spamming /jp/ with "test 234" messages.


in vichan there's an option in the deletePost function to not rebuild after a delete, this was turned on accidentally.


File:[MoyaiSubs] Mewkledreamy -….jpg (302.07 KB,1920x1080)

Do you think it's possible to add webp support? It's increasingly common when I google an image to post in a thread that I end up getting webp results and it's a quite an annoyance to be unable to post them.
I know nothing about the format other than newer wikis seem to use them almost exclusively and I have nothing on my computer that can open them


> $config['allowed_ext'][] = 'webp';

this is strange, I have it enabled but for some reason I'm getting the invalid image error. Was working not long ago


File:test-webp.webp (629.87 KB,1536x1024)



I see, found the problem.

should work as it has in the previous months


File:Googolplex_in_the_show.webp (47.58 KB,544x416)

might as well test the image I wanted to post


not sure if people would consider this to be too reddit or not but i was trying to think of a way that you could make it easier for people to dump images on /ec/ and came up with an idea that maybe there could be a way to that's tied to the board's unique feature. my idea was that maybe for every 5 likes or whatever they're called that somebody gets they can skip a captcha on /ec/ only. 5 because it's small enough to be easily attainable and large enough to not be that abusable. maybe it's a dumb idea, but it might be nice


Why not just allow multi-file posting?


The UI for multiupload is poor and gives threads with image spam an unfair advantage. Also gives way to dilution of individual post focus and drives interest away from text towards images


There are other more technical issues, but hard to explain


captcha skips are an interesting idea.

Something I could consider is IP hierarchy. If an IP is deemed safe (a temporary entry in the whitelist?) it gets exempt from captchas. This means there would be another page for requesting captcha exemptions.

Concerns with this idea are mostly adminstration


I considered this as well, but it's probably not the best idea. For one not everyone has a static IP so you'd have to keep whitelisting IPs and this may run into issues for people that use VPNs or IPs without captcha that are no longer in use by the people who you meant to whitelist. If somebody with malicious intent were to stumble on one of them it could be very bad. Also, thinking in long term it may become a bit unsustainable with people maybe wondering why others are deemed worthy of this "kissu pass" of sorts and they aren't, and the more the userbase grows the more headaches such a system would cause. For my idea I think it'd probably incentivize using the features on /ec/ a bit more and maybe encourage people to post more if they don't need to solve a bunch of captchas each time they esnt to dump.


hm, I guess it could be that this is a form of IP verification. However, all I need is a phone and I have a free pass anyways. It's much more flimsy because I don't have mod tools built around fixing scores or polls, they exist solely for the sake of entertainment rather than accuracy.

I can't really trust anonymous peer reviews to give out exemptions. I think it has to go through a bureaucracy just as a ban would, with clear cut rules that a paper-pusher could follow…


You could make the exemptions reply-specific, so people can't use them to avoid thread-making captchas


limits to what can be done is a good idea regardless of what system gets used.

Captcha and rangebans are both exemptions that the 4chan pass gives and so far that's the ultimate system of security and freedom. But when you apply this into a 100% free model that I'm going for with kissu that idea falls apart and is too easy to abuse. It's tricky


Noticed that just clicking on the boards up top doesn't show the new posts anymore, seems that you need to refresh to get an updated page


Altered a bunch of mod features, whitelisting, ban appeals can be given deny reasons to allow more flexibility, and also added in embed deleting which wasn't possible before.

annoying… I turned off some server config settings a while ago so might have caused it, but it could be a variety of things. Turned these settings back on, but I might need to find something else.


Beginning to make changes to logins and passwords


Added a counter to bruteforce on /mod.php? and increased complexity of SQL password in the rare case where the server IP gets exposed and someone begins bruteforcing the sql port.


Speaking of the mod login page, I've noticed that when you delete one of your own posts, you're redirected to that page, and not to the board. Dunno if this has been brought up yet.


uhhh, that's not the case for me.. I winder back on the bord.

can you explain what exactly you do to get this?


Never mind, I just tested it and it redirected me to the board. As recently as a couple of weeks ago, it would redirect you to the mod login page - more specifically, iirc it would take you to a "post deleted successfully" page, and the "return" link on that page led to the mod login page.



seems like that kind of thing only works reliably on UDP sockets


File:7d23bad385.png (15.04 KB,1162x161)

phashing looks good.

The video version is broken(library outdated) so it can only be applied to images and gifs, but still, looks like a good tool

tests from https://kissu.moe/test/res/1078


If you get a VPN banappeal it and I'll add it to the whitelist.

If you appeal it, it doesn't get cleared, and don't get a denial reason then appeal it again because I probably messed up the code


also something's making kissu posting slow again


attempting to get information from rbl.efnet.org was slowing the site down to a terrible pace.

Posting is back to normal speed


getHostByAddr is probably too strong

my whitelist was also having an issue that I'll have to test out


So anon that was submitting appeals should be able to post again



I'm undecided if I'll turn it back on or not, but in any case I'll enter this IP in to the whitelist manually after this is sorted out.


yeah, it was a silly mistake. My bad


Seems to still be happening on /qa/. There's a deleted wojak stuck on the front page for me, because nobody's posted anything to update the board.


whitelisted 169.46.*.*

anyone can try to delete it at that point and it will go away.

It seems like multi-board pages with an archive have it happen. I'll look into it deeper


2600:1700::/32 phone range is associated with Heyuri bs(wojack and stuff). The log of this subnet is both mostly unused and dubious in usage so ranging it for a bit


I'll be uploading some code,
If things start looking funny that's why


Added perceptual hashing but currently no filter rules are set up. Blockhash works well, spammers will have to put in a lot of effort.

Banners is also having perceptual hashing set up. To stay consistent I need to finish off making test cases for this and do the documentation work for it.
Banners also has a similar anti-bruteforce setup for it.

Also made it easier for mods to see ban appeals so we'll have a faster response time to these kinds of issues and requests for whitelisting.

I figure if I'm going to be causing problems for VPNs I might as well commit to it.

I manually added you into the VPN whitelist. Seems in order, but this is still an experimental idea.


so currently I need to:
Prep a banners security update,
Create hashes for existing banners
Begin building up an imagehash blacklist
Create a basic spam filter for appeals

then security issues are resolved.


mp4 and webm posting will be broken for today until I get the experimental video hashing working


looks like mp3 and flac will follow in being busted for now. I'll make it my primary fix


[4/6] Linking build/libstblockhash.a
../videohash.c: In function ‘process_video’:
../videohash.c:129:5: error: unknown type name ‘CvCapture’; did you mean ‘CvCmpFunc’?
CvCapture* capture;
../videohash.c:140:15: warning: implicit declaration of function ‘cvCreateFileCapture’; did you mean ‘cvCreateKalman’? [-Wimplicit-function-declaration]
capture = cvCreateFileCapture(filename);
../videohash.c:140:13: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
capture = cvCreateFileCapture(filename);
../videohash.c:152:5: warning: implicit declaration of function ‘cvSetCaptureProperty’; did you mean ‘cvSetWindowProperty’? [-Wimplicit-function-declaration]
cvSetCaptureProperty(capture, CV_CAP_PROP_POS_FRAMES, 0);
../videohash.c:152:35: error: ‘CV_CAP_PROP_POS_FRAMES’ undeclared (first use in this function); did you mean ‘CV_WND_PROP_VISIBLE’?
cvSetCaptureProperty(capture, CV_CAP_PROP_POS_FRAMES, 0);
../videohash.c:152:35: note: each undeclared identifier is reported only once for each function it appears in
../videohash.c:154:12: warning: implicit declaration of function ‘cvQueryFrame’ [-Wimplicit-function-declaration]
while (cvQueryFrame(capture)) frame_count++;
../videohash.c:168:33: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
IplImage* frame_image = cvQueryFrame(capture);
../videohash.c:181:17: warning: implicit declaration of function ‘cvEncodeImage’; did you mean ‘LZWEncodeImage’? [-Wimplicit-function-declaration]
mat = cvEncodeImage(".bmp", frame_image, NULL);
../videohash.c:181:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
mat = cvEncodeImage(".bmp", frame_image, NULL);
../videohash.c:233:5: warning: implicit declaration of function ‘cvReleaseCapture’; did you mean ‘cvReleaseData’? [-Wimplicit-function-declaration]


not looking worthwhile


i see, it's the API
in fact, all the images and videos were going through from the looks of it
it's just that vichan's "4chan api" breaks if the hash is wrong


File:1599946042964.webp (11.37 KB,225x350)

the MD5 part of the API has been changed, but should still function as intended.

videos and files maintain the same MD5 hashing algorithm, but images use the perceptual hashing system.


finally, I'm retrialing the idea of duplicate checks. We'll see if it gets in the way of things or not.


There's a big bug in vichan filters where if someone posts at the exact second as someone who violates a filter rule, they'll be effected by it.

This might be some sort of condition where the $_SERVER['REMOTE_ADDR'] field gets mixed up… it's really odd


it might be caused by something else.. it was a really strange situation.

Banners have a security update(account limits per IP, max login attempts per time cycle, blockhashing without hash distance). No new features to that as yet. Registration was previously closed but is open again.

Kissu has distance evaluated blockhash.
You can test out the no-distance blockhash by posting an image and trying to modify it slightly and posting it again. To test out distance evaluated you'd need to trip up a spam filter.

Last item is a simplistic email spam filter for the ban appeals in case it becomes such that someone tries to deny mods from picking out real appeals.
The value of proper appeals is because the proxy searcher and proxy range compressor are starting to catch legitimate VPN users. It might be of worth to also provide a key to donors that lets them auto-whitelisted from rangebans.

After this it's about bugfixing what's been done, from the UI that I haven't touched in a while to the bugs created from new mod tools.
It also goes without saying that since effort was put into vichan, kissu will likely always use vichan's post insertion and mod tools… items such as archive, deletion, polling, scoring and so on will likely eventually be moved over, but vichan's post filters and mod tools are great. I don't see a way around this.


I don't think they are supposed to represent "likes"…


if it looks like a like, and feels like a like, then it's probably a like.


-Deletions restored from archive.
-Seems like an image that was filtered got past hashing check


Also was not proxy


Resolved, it was setting the wrong board for rebuild


I have to start concerning myself with money.

I stalled it out for a long time but I'm paying an affordable rent now and my savings are going to start getting chunked out every month. Is it possible to make a poverty level living on imageboards alone? It's time to put it to the test… I'm pretty certain getting a full-time job will mean quitting imageboards or making it a background project. I've got a commitment towards this site and community that goes beyond myself and want to continue as long as I can afford it. I want to focus on this site as long as possible and keep living a life of flexible hours and see Kissu gain in quality.

I'd like to give some sort of reward to donors and am thinking that it might be ideal to privately give out a whitelist key that exempts you from any vpn/proxy/tor/phone/agent bans and captchas. There are some ways I could do it without a sort of cash down deposit, but this is by far the most practical and my current donors are very generous and I want to give them something special.
This is the donation page should you be interested https://www.patreon.com/ECVerniy

Money is an important priority in this stage of my work here, but it's more important for me to finish off the last security feature and create the whitelist keygen. At this point Kissu is in a state of management, maintenance and bug fixes, where beta features are ironed out(new UI) and fixes/adjustments are made to Kissu's software. However, ultimately I'd like to get away from the software and start focusing on the brand and I'm not too far from this point where I have a software and financial model I want to push. One that doesn't let me compromise my beliefs and stays true to the easy going atmosphere.

You won't have to deal with this kind of stuff right away, but in the next few weeks I'll start making a push. Until then, there are still bugs to solve and features to test.


added IP to whitelist. That ISP provides server hosting and residential IPs


What do you think of using koremutake instead of base64 for displaying secure tripcodes?

A major drawback of tripcodes is that nobody remembers them. So to impersonate someone, it's often sufficient to get the first few characters right. Koremutake encodes data as pronounceable strings which are easier to remember, so instead of someone's tripcode looking like !!PiTTj6CgcA, it would look like !!pikevafujojigru. It would only make sense to do this for secure tripcodes because with normal tripcodes it's desired that they look the same on every site.


hmm, it's an interesting idea and it would have to be done before anyone starts using them.

A system of base127 seems like it would be interesting, but could it just be done by appending a vowl to the end of each capital letter constantant

PiTTj6CgcA would become PiiTaTaJu6CagcA. It's a similar system kind of like how in navigation when they read out the codes they say Alpha Beta Charlie Foxtrot isntead of ABCF


>A system of base127
correction: base128, so all it needs is bit shifts and lookups in the array.

>seems like it would be interesting, but could it just be done by appending a vowl to the end of each capital letter constantant

Wouldn't that still produce unpronounceable tripcodes when there are a lot of lowercase consonants in the tripcode? Looks harder to remember too.


Another option to consider would be words instead of syllables like gfycat uses for its content IDs.


For example, "doppler squalidly phoenician interfaced" using the Niceware wordlist. Might be a bit long, though.


Not sure if people would find it hard to see patterns in that. By contrast something brand new might be overkill. I suppose bitshifting it wouldn't be too hard though and this is a decision that should be made early rather than late, meaning overkill might be a good thing and give growing space.

too long. I'm also reminded of anonymous sign in on other websites.


Made a calculation mistake there, to have about the name number of bits as current secure tripcodes (6 bits per character*10 characters displayed), it would have to be 9 syllables, e.g.:


File:sade.png (4.64 KB,480x73)

can u change thise plz it maeks me so sade why r the replies so smal


Testing some different options for encoding tripcode data. So far the one I like best is Koremutake with capitalization added:

If we do change the secure tripcode presentation, it might also be a good idea to consider whether we should update the hash function used.



File:0MKG1zK.png (162.33 KB,1227x705)

Are you doing these in PHP? The way that makes sense to me in PHP is a base64_decode which turns it into a 7 character binary string. Characters are converted into an array of 255bit numbers. Each one is shifted 1 bit. It's not accurate to your method so I'm wondering if you had a better way to do it.

07ANLLIBMQ(60bit) into Ó°
,²1 as D3 B0 0D 2C BD 01 31(63bit) and each 8bits gets shifted 1bit resulting in "FROVUDA - GUVYBA - HA"


I don't think it needs to be any more complicated than that, but the layout can be played around with


Yea, that's small. I made it a bit bigger, but I don't want it to be jarring.


Ah, I see, I think I misunderstood the point of the bit shift because I was working with arrays and not straight binary. I need to backshift and modulo by 128 to maintain depth


It feels to be like when a tripcode gets past this length it starts being way too long for people to care about it. I did a quick birthday paradox check and it seems feasibly impossible for someone to pick the same one in a set of 128^7 so I might just run with this unless there's a reason to think otherwise


Is it worthwhile to have a disjarring difference between trip styles? I think it looks ugly to mix and match them…


If you're worried about the length, you might want to consider the capitalization idea, where you use the 8th bit of each byte to decide whether the syllable is capitalized. You could also think about the last option in >>4461, which is a bit shorter than the Koremutake encoding with some loss to pronounceability due to long strings of vowels. That one is just (in Python) 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'[n//5] + 'aeiou'[n%5] for each byte n.


After looking at some examples, I no longer think the capitalization idea is good:

If you're going to do 7 syllables, maybe just for aesthetic purposes it would be a good idea to move the last hyphen between the 5th and 6th syllables so you have SOHEHO - RITO - SEDRO instead of SOHEHO - RITOSE - DRO.

I can't think of a reason to have insecure trips at all if they're not consistent with other sites.


Titlecase and lowercase seem like the best quick fix. It might be possible to maintain case consistency by adding 128 more pronunciations. I used the list on http://shorl.com/koremutake.php without any modifications.

> Insecure trip

I suppose so, there's no reason other than perhaps using a solver to get funny combinations. Keeping legacy makes two different styles in one application. I'm not sure if I want this sort of inconsistency.


>It might be possible to maintain case consistency by adding 128 more pronunciations.

['b', 'd', 'f', 'g', 'h', 'j', 'k', 'l', 'm', 'n', 'p', 'r', 's', 't', 'v', 'w', 'z', 'bl', 'br', 'ch', 'cl', 'cr', 'dr', 'dw', 'fl', 'fr', 'gl', 'gr', 'gw', 'pl', 'pr', 'qu', 'sh', 'sk', 'sl', 'sm', 'sn', 'sp', 'st', 'sw', 'th', 'tr', 'tw']
for the consonant parts and
['a', 'e', 'i', 'o', 'u', 'y']
for the vowel parts would give 43*6 = 258 combinations while maintaining phonetic distinguishability. I'm a bit torn between "gw" and "sv"; neither are very common, with "sv" being the more common one, but I think "gw" rolls off the tongue a bit better.


The 256 set starts looking a lot more foreign


What I'm thinking here is trying to make them sound like names, that way people can remember them easily. Some of these sylables make it seem off, but I suppose this is an improvment over before and the total hashes is now in the quadrillion range like before so I think it's alright.

Debugging my spam filter now


In which case title case works well




Inspired by the name concept, I used the SSA baby name dataset
to construct a syllable list that may be a bit more natural. I tried to pick syllables that were commonly used both at the start of names and within names.

['ro', 'be', 'ma', 'li', 'ri', 'sa', 'na', 'la', 'de', 'me', 'vi', 'ra', 'mi', 'cha', 'ni', 'ca', 'le', 're', 'ta', 'da', 'mo', 'co', 'lo', 'so', 'che', 'za', 've', 'ke', 'va', 'ly', 'ge', 'ga', 'te', 'sha', 'se', 'the', 'ce', 'ne', 'sta', 'ste', 'bi', 'no', 'fe', 'bo', 'tri', 'my', 'cy', 'dy', 'lee', 'ci', 'do', 'bra', 'ja', 'lia', 'to', 'ka', 'di', 'ry', 'gla', 'go', 'wa', 'pe', 'xa', 'lea', 'ha', 'dia', 'gai', 'mia', 'we', 'si', 'ze', 'ba', 'gi', 'ree', 'phi', 'ti', 'ko', 'die', 'lei', 'ty', 'su', 'by', 'sie', 'lai', 'dwi', 'sca', 'pri', 'tha', 'rey', 'roy', 'tu', 'brie', 'sy', 'ny', 'kay', 'que', 'cia', 'cie', 'wi', 'bri', 'rya', 'sco', 'lio', 'xi', 'ki', 'lu', 'sto', 'nia', 'tie', 'vo', 'gu', 'fa', 'she', 'dua', 'hi', 'ria', 'tho', 'tia', 'nya', 'spe', 'pa', 'ley', 'vio', 'qua', 'loi', 'qui', 'bia', 'sey', 'chi', 'lay', 'nee', 'ru', 'dra', 'via', 'mu', 'teo', 'fre', 'miya', 'shia', 'kie', 'kia', 'saa', 'sea', 'sia', 'cly', 'he', 'maya', 'rai', 'sue', 'jo', 'mee', 'riya', 'mya', 'nie', 'shi', 'wre', 'niya', 'bree', 'sho', 'xo', 'rio', 'fu', 'dee', 'vie', 'dwa', 'cla', 'thea', 'tra', 'ble', 'shau', 'kai', 'lie', 'lya', 'naya', 'laya', 'ney', 'sla', 'blo', 'nai', 'po', 'way', 'smi', 'nu', 'xe', 'fi', 'kae', 'kee', 'phe', 'rae', 'jua', 'nea', 'mai', 'zia', 'kiya', 'liya', 'fo', 'zi', 'rye', 'kei', 'lle', 'nei', 'mie', 'cho', 'bria', 'tya', 'nay', 'nye', 'rea', 'toya', 'pha', 'ky', 'deo', 'hu', 'cle', 'tzi', 'lou', 'brey', 'dre', 'thia', 'khi', 'leya', 'llu', 'raya', 'cu', 'fae', 'mou', 'ho', 'cre', 'loy', 'sai', 'mae', 'rie', 'tre', 'cae', 'nyo', 'zu', 'leo', 'ceo', 'shee', 'pi', 'ray', 'thie', 'maa', 'shu', 'veo', 'bu', 'naa', 'xy', 'loui', 'lau', 'gra', 'sti', 'vy', 'xia', 'je', 'dio']

The code I used is at
if you want to tweak it.

Also, the code STI wrote years ago to generate "secure" tripcodes is pretty bad. There's very little point in using a semi-modern hashing algorithm if you're just going to use it to generate a salt for ancient DES crypt(). Wouldn't surprise me if someone could crack the "secure" tripcodes just by enumerating over all possible 12-bit salts. You should rip that garbage out and replace it with a proper key derivation function.


Another thing that might make it look nicer is adding consonants to the ends of the words. If you're doing two words, you could end one word with consonants[n>>4] and another with consonants[n&15] where n is one of the bytes in the binary string being encoded. consonants could be something like
['', 'b', 'c', 'd', 'f', 'g', 'h', 'k', 'l', 'm', 'n', 'r', 's', 't', 'x', 'z']
where I've excluded q, j, v, p, and w for being less common than other consonants at the end of words in the SSA baby names list, and the first item in the array is an empty string so that sometimes it ends in a vowel.


Came up with some more syllable list candidates:

syl1 is the same as >>4483

syl2 also requires that the syllables be common in words in Moby Dick. This removes a lot of foreign-sounding syllables.
Moby Dick from: https://www.gutenberg.org/files/15/15-0.txt

syl3 first enumerates over all consonant-vowel combinations except those starting with Q (Y considered a vowel). Then three-letter syllables are taken from the SSA baby names list. The result is slightly shorter syllables. I think it might look a bit better.

syl4 is like syl3 but with the Moby Dick filter applied, and with syllables starting with X also excluded from the two-letter combinations.

Here's some sample names generated from each syllable list. I've also applied the final consonant idea from >>4484.


From what I'm getting, the strength of crypt is based on installation settings, but I'll double check this

>PHP sets a constant named CRYPT_SALT_LENGTH which indicates the longest valid salt allowed by the available hashes.

>CRYPT_SHA512 - SHA-512 hash with a sixteen character salt prefixed with $6$.


But it could be interpreted that the salt has to be prefixed with $6$ to force it to pick sha512 as default


I see, so the autogenerated salts for vichan are in of sha length, but none of the salts for the crypto functions are prefixed with $6$rounds=1000$ to make it not default to a DES hash


well, they didn't make that mistake for the passwords so I guess trips was just a decade long oversight



I see, GPU cracking


I suppose moving data from RAM/Cache to CPU to GPU is going to take more time for more data so that the bottleneck becomes the transfer speeds rather than the GPU speed.

>Bcrypt isn't known to be much gpu friendly, the primary reason being the ridiculous amount of memory being used by each bcrypt hash. To make the matter worse the memory access is pseudo-random which makes it very difficult to cache the data into faster memory. With this we are left with two choices:

>1.Use the slow and large global memory and spend more time fetching the operands than processing them.
>2.Use the fast but small LDS(64KB) memory and severly limit the number of concurrent threads.

seems like the logins should be redone more than tripcodes


vichan has an easy system for changing hashes so they're using blowfish now.


some comments from IRC:

<me> https://pastebin.com/WwsRWuX0 < sorry, didn't make myself clear, it's divided into four sections; which section looks like it has the more natural and memorable names?
<Anonymous> <syl1:Crenyaxiam SyrobohSuexothok BumiyatisLeebraneer NaisemaacKaesiadr - Pastebin.com> @ kissu.moe
<Anonymous> sy14 for me, but it's hard to see a difference
<Anonymous> way too much data…
<Anonymous> syl1:
<Anonymous> Crenyaxiam Syroboh
<Anonymous> Suexothok Bumiyatis
<Anonymous> Leebraneer Naisemaac
<Anonymous> Kaesiadreg Thaxagair
<Anonymous> Jedybil Tredeemeer
<Anonymous> syl2:
<Anonymous> Tribouwot Queshescoc
<Anonymous> Guquiesiez Theojouslyg
<Anonymous> Ledeaphah Reescotryc
<Anonymous> Neasaispe Roofutiam
<Anonymous> Scheleebral Traclesheen
<Anonymous> syl3:
<Anonymous> Chireechal Woseymon
<Anonymous> Raeglalex Bratenyz
<Anonymous> Thinieseex Lyawrevun
<Anonymous> Pyletiec Frehacek
<Anonymous> Radrezer Nyoleystim
<Anonymous> syl4:
<Anonymous> Taizyzun Jeepydeak
<Anonymous> Smakizus Fonemaut
<Anonymous> Bijeescoh Getyneg
<Anonymous> Niwoophox Philaytes
<Anonymous> Gaysituh Midraquir
<Anonymous> How could you miss the new line before "syl4"? If you're going to do it, at least be consistent.
<Anonymous> the one after 4 isn't a \r\n
<Anonymous> just a \n
<Anonymous> 4 seems arabic, 3 seems latin
<Anonymous> 2 doesn't really make sesne
<Anonymous> 1 kind of reminds me of biblical names
<Anonymous> i think 3


accepted an appeal


New tripcode system made to immitate names(set3 in https://pastebin.com/GTJ0NL5z)
Ban list won't display the automatic vpn/proxy/tor bans.
Ban appeals can be detected for spam. Currently only detecting and not filtering
Update hashing of logins and secure hashes

Future tasks:
Whitelist tokens
Insecure tripcode solver(no point to having insecure hashes at all if there's nothing to do with them, why not have people break them to create names)


If you don't want to do the final consonant thing in >>4484 it might be good to add some syllables with consonants at the end. I generated a new list where I'm allowing some consonants at the end of syllables. Consonants allowed at the end of syllables are not allowed to precede another consonant at the beginning of a syllable to prevent two inputs from mapping to the same string. I've also dropped some of the frequent consonants from the two-letter syllables; it seems to improve the fraction of names that can be generated. Currently 34.3% of the female baby names on the SSA list (weighted by frequency) can be generated from combinations of these syllables and a smaller fraction of the male names. I'm probably going to fiddle with this more to see if I can improve coverage.

['ba', 'be', 'bi', 'bo', 'bu', 'by', 'ca', 'ce', 'ci', 'co', 'cu', 'cy', 'da', 'de', 'di', 'do', 'du', 'dy', 'fa', 'fe', 'fi', 'fo', 'fu', 'fy', 'ga', 'ge', 'gi', 'go', 'gu', 'gy', 'ha', 'he', 'hi', 'ho', 'hu', 'hy', 'ja', 'je', 'ji', 'jo', 'ju', 'jy', 'ka', 'ke', 'ki', 'ko', 'ku', 'ky', 'la', 'le', 'li', 'lo', 'lu', 'ly', 'ma', 'me', 'mi', 'mo', 'mu', 'my', 'na', 'ne', 'ni', 'no', 'nu', 'ny', 'pa', 'pe', 'pi', 'po', 'pu', 'py', 'ra', 're', 'ri', 'ro', 'ru', 'ry', 'sa', 'se', 'si', 'so', 'su', 'sy', 'ta', 'te', 'ti', 'to', 'tu', 'ty', 'va', 've', 'vi', 'vo', 'vu', 'vy', 'har', 'ter', 'tho', 'ber', 'don', 'san', 'sha', 'den', 'lin', 'dan', 'lyn', 'the', 'bra', 'tri', 'ral', 'ric', 'nor', 'vin', 'lan', 'ver', 'lee', 'dia', 'ron', 'fre', 'lea', 'nel', 'lor', 'lia', 'gla', 'ger', 'phi', 'sta', 'ran', 'mer', 'min', 'han', 'war', 'mia', 'lon', 'lau', 'lei', 'fer', 'der', 'lar', 'mar', 'dal', 'ker', 'ken', 'per', 'nan', 'del', 'lay', 'wen', 'nic', 'bec', 'roy', 'mon', 'ree', 'die', 'kay', 'jan', 'bel', 'car', 'mil', 'ben', 'dre', 'bri', 'sco', 'tia', 'son', 'col', 'ste', 'man', 'lai', 'van', 'wan', 'tha', 'vel', 'rey', 'len', 'gio', 'tru', 'win', 'mai', 'mel', 'for', 'loi', 'bur', 'kie', 'gil', 'zel', 'dra', 'sue', 'rai', 'dol', 'woo', 'dee', 'gia', 'leo', 'cia', 'kia', 'lio', 'dor', 'sel', 'loy', 'cin', 'shi', 'xan', 'her', 'tra', 'key', 'nia', 'tor', 'mya', 'zan', 'mal', 'rol', 'von', 'wel', 'til', 'ray', 'kai', 'kel', 'ten', 'gen', 'way', 'nai', 'nya', 'she', 'pal', 'kee', 'gri', 'fan', 'ley', 'cie', 'rae', 'ton', 'kei', 'hai', 'tan', 'ren', 'sey', 'hel', 'qua', 'lil', 'sto', 'sie', 'kae', 'kin', 'tae', 'lou', 'can', 'sea', 'sol', 'bil', 'hen', 'hea', 'nee', 'vio', 'dwi']

generator: https://pastebin.com/GCgbhdiE

some sample names:
Riccocejo Leiquajo
Dydeefini Suenuwar
Handociesco Rodiaco
Nugiovingio Pywentu
Laudrekerte Kayvalo
Keywanlanju Seagevu
Bellortaeste Laukeldu
Muronlape Keitonbu
Vonhermucar Mondoru
Derbelilko Loysufor
Bilsuedendie Tanreehi
Wayleosuedan Cancito
Gutenkyvu Herleolyn
Nyawoovovel Fedonsol
Kiakastovan Verhenru
Lidolloigia Haivilia
Gialeeselnu Butiaco
Donleykiage Falefan
Rolpalcinsan Beltandon
Linlarlorno Volaihel


it's beggining to become more than anyone could ask for in a tripcode on an anonymous website, but I can simply modulo the number by vowels+1 and it won't take me any extra time.


did what you suggested in 4484




Do you mean by the number of consonants? The idea of >>4484 was to take one of the bytes and instead of looking it up in the syllable table, compute n/16 and n%16 and use that to look up consonants to end the names with (with one option to let it end on a vowel). Wouldn't be much extra work. Switching to a syllable table with final consonants like >>4497 would work too, albeit producing slightly longer output (about 1 character longer).

A noteworthy consideration is that male names tend to end in consonants while female names tend to end in vowels. Thus >>4484 would be heavily biased toward male-like names whereas >>4497 would be biased toward female-like names. At least in theory.

Running some numbers:
probability of randomly generating real names from the SSA lists
where the numbers are probability (first word) * probability (second word) = probability (both words)

syl3 without >>4484
2.29804e-07 * 5.81503e-04 = 1.33631e-10 (female)
4.16767e-08 * 1.055e-04 = 4.396e-12 (male)

syl3 with >>4484 modification
4.15631e-05 * 4.15631e-05 = 1.72749e-09 (female)
1.03712e-05 * 1.03712e-05 = 1.07562e-10 (male)

final consonants included in the syllables >>4497
2.21422e-07 * 5.669e-04 = 1.255e-10 (female)
4.21423e-08 * 1.31249e-04 = 5.53113e-12 (male)

Hmm… by these numbers, they're all female biased in a way, and the main thing affecting the numbers is the word length.

Another interesting measure is what percentage of names can be generated if you're using a tripcode cracker.

If we want a whole word match, syl3 without >>4484 can get to fewer names because it requires the name end with a vowel.
Below, the percent of names reachable by syl3 for various numbers of syllables (out of all names of the given gender, weighted by name frequency):
1 syllable: 0.7% of female names, 0.7% of male names
2 syllables: 14.9% of female names, 4.8% of male names
3 syllables: 9.2% of female names, 1.2% of male names
4 syllables: 1.9% of female names, 0.0% of male names
5+ syllables: 0.0% of female names, 0.0% of male names
total (any number of syllables): 26.6% of female names, 6.8% of male names

If we want a partial match, syl3 without >>4484 should perform better than above because a lot of names ending in a consonant will be found as substrings even though the whole words end in a vowel. I haven't calculated those numbers yet, though.

Here are the same numbers for the alternatives:

syl3 with >>4484 modification
1 syllable: 1.4% of female names, 3.5% of male names
2 syllables: 22.4% of female names, 22.7% of male names
3 syllables: 11.3% of female names, 3.2% of male names
4 syllables: 1.9% of female names, 0.1% of male names
5+ syllables: 0.0% of female names, 0.0% of male names
total (any number of syllables): 37.0% of female names, 29.5% of male names

final consonants included in the syllables >>4497
1 syllable: 0.6% of female names, 1.0% of male names
2 syllables: 21.7% of female names, 12.2% of male names
3 syllables: 10.0% of female names, 2.3% of male names
4 syllables: 1.9% of female names, 0.1% of male names
5+ syllables: 0.0% of female names, 0.0% of male names
total (any number of syllables): 34.3% of female names, 15.6% of male names


Why is it still 7 syllables?


a mistake. >>4502 is 9

This is too much tripcode… these modifications make it much better than what anyone else uses. The combinations don't have to be masculine or feminine, they just have to look somewhat appealing and recognizable without the use of a solver


Is this still the list from >>4475? I thought you changed it to syl3.


If you implemented >>4484 it should be 6 syllables not counting the final consonants. >>4484 is supposed to make the tripcodes shorter.


good catch, I mixed up the backup and upload




I'm happy with how they look now. It's achieved the goal of making tripcodes less like random characters and into sylables that are pronounceable and somewhat pleasing to the eye. There are other tasks to build on that getting stuck on a feature no one uses as yet would be kind of wasted time.

It's also had the sideeffect of increasing hash security for both tripcodes and mod logins


As it is now the final consonants are just making the tripcode longer but not carrying any additional information. What I was suggesting with the consonant idea is that you can drop one of the syllables and instead use that byte n to make the two consonants with n/16 and n%16.


Are you pushing these changes to Github? I know you don't want to waste any more time (and I probably shouldn't either), but if I could see what you've implemented I could just send you a patch or pull request with the fix.


I see. Yeah that could be good.

I'll make another push into a seperate repo because this version of kissu is practically pointless without the golang server. I just have to check there's nothing important in any of the files


yeah it looks a bit nicer

uploading the single file is faster
function makeKoremutakeString($str)


It's still not quite what I was suggesting because now it's discarding some of the data.
I updated the code so it doesn't discard or duplicate data here:

On another note, not addressed in this commit:
Since we're not using the Koremutake encoding anymore but our own list of syllables, to avoid confusion, I would remove the comment linking to the Koremutake encoding and rename the function to something like encodePronounceable.


That's like a hybrid of what I did at first with the enders and afterwards. But anyways I tested it out and renamed to phoneticEncoding. I'll add it in soon


Alright, it's up


Oh, one other thing regarding the tripcodes and mod logins. You should probably measure the time it takes to compute the hashes on your server and verify it's not so long that it makes denial of service attacks possible. On my machine it takes about 0.3 seconds; your server is probably a bit faster than that, though. I imagine if it's small compared to, say, the time it takes to thumbnail images, it might not be worth worrying about, although posting a bunch of large images to try to shut down the server might be constrained by the attacker's bandwidth, whereas this wouldn't be.


Another small thing. I assume the purpose of
>sha1($trip . $config['secure_trip_salt'], true)
is to make it so we can use arbitrary length salt which would be very difficult to crack by testing all possible salts against a few known secure tripcode password + output combinations. It's probably not critical, but since SHA-1 has been broken in a few ways (probably not relevant to this particular code yet), while we're changing these things, we might as well update SHA-1 to a more modern hash function. And we might want to look at other ways SHA-1 (and the even older, more thoroughly broken MD5) are used in vichan.


Kissu has it so that login attempts for accounts are locked for unknown IPs after x attempts per minute, so no one is going to lock the site out with that.

yes, it's a bit odd that vichan gives you a 100+character salt yet is forcing it down into an md5 or sha1 hash.
The function mkhash($username, $password, $salt = false) in inc/mod/auth.php is bizarre if there's somethig to look at. This is only for the mod cookie generation I believe


the bigger issue with denial is that we don't actually have enough CPU cycles to run blockhash, thumbnailing and etc as well as scan for bans at the same time. The server that handles ban appeals, archive and auto-bans will have to be placed onto the other server and make DB actions over the net.


When playing with insecure tripcodes https://kissu.moe/test/res/1241 I realized it's kind of annoying we can't generate any words starting with a vowel. So I thought of a simple small change that would enable it.

If you just add
$phone_str = preg_replace('/\bx/', '', $phone_str);
before the last line of phoneticEncoding, then when it generates e.g. "quality xanime", it would be converted to "quality anime."


blockhash appears to have worked because there was nothing filtered that showed up.

I'm adding an easy filter to the mod UI so I don't have to do SQL queries to add them


Vowel starters added


Assuming I can find one




cool, thanks


Neat. I'm guessing the insecure salt is the same, but what's the actual equation for generating this style of trip?


I'm just running the encoding backwards and generating a tripcode search pattern that I can feed into an existing tripcode engine like MTY or Merikens. For example, these patterns search for "anime" as the first and second word:



Oh, and if you want to know what's implemented on Kissu, the tripcode generating code is at
with the piece that converts the trips into pronounceable style at
The code there doesn't seem to be updated for >>4523 >>4525 yet though.


After I download a site backup I'm going to upload some files.


Database will be broken for a bit so posting will go down


test test


Names are back to being stored in memory.

Also added whitelist-tokens which I'm going to send to donors. This personally assigned code allows you to bypass filters such as captchas and rangebans allowing for an easier time dumping images or posting with captchas.


Also some other small fixes such as passwords are back to being ***'d without the annoying effects of autofill in common browsers


>I'm just running the encoding backwards and generating a tripcode search pattern that I can feed into an existing tripcode engine like MTY or Merikens.

Wrote a Python script so that anybody can do this:


if it's not clear, that program turns normal tripcodes into phonetic equivalent


It's mostly about going in the reverse direction: you have a word you want to search for in a phonetic tripcode, and it prints a bunch of regular expressions that can be used to search for the regular tripcodes that give rise to phonetic tripcodes containing the word.


For example, if you run the program and enter "watashi", it will print:
If you put these into a tripcode searcher, it will find regular tripcodes that convert to tripcodes containing "watashi" on Kissu. Note that some of them convert to things like "dwatashin" so if you don't want that, you can use ^ $, and \b in the search string. Entering "\bwatashi\b" will print:
Once you have a list of ordinary tripcodes that contain the string you want, you can see what they look like by piping the list to `./reverser.py forward`, which will convert them to the phonetic form you'd see here.


File:ablankreply.png (2.17 KB,329x139)

Bug: Clicking "New Reply" with empty text fields posts a blank reply.


from what I see there's not actually an option for no body and with image


I c


Seems like I've done everything I wanted to on the mod side of things. I've just got to fix up the javascript UI now…


File:1600914914154-1.png (1.42 MB,1240x1754)

There's some issue with trying to post pic in >>>/jp/6301, I think it started when I tried to post a different file with the same filename. Site says it either already exists in >>>/jp/6321.


must've switched over to perceptual hashing for everything instead of keeping md5 for that rule


That must be why the one-pixel changes weren't working. Strong stuff.


well, the spamming guy got past it with some phone changes.

I'll disable duplicate checks




Wrote down 10 categories of issues and I might try to knock one of them down a day. The API server is currently not getting post information from kissu so it's not live.
Likely I will ask what some of the technical problems are starting with home page issues then resolve them.

An improved spam hasher would probably have to manipulate the images slightly to get rid of common methods of generating variance or maybe I just need to rework my block distance calculation to weight exact matches higher.

IMO when a spammer has to start squiggling all over his image or replace it all with noise to get past the filter it's fine, but simple actions such as rotations and borders should be dealt with to an extent.


in these antispam cases it's probably the problem that kissu doesn't have a good enough CPU for this not to impact posting badly.


>An improved spam hasher would probably have to manipulate the images slightly to get rid of common methods of generating variance or maybe I just need to rework my block distance calculation to weight exact matches higher.
You could also try a different algorithm; for example some of the ones on https://github.com/KilianB/JImageHash say they are rotationally invariant, although I haven't tested them out myself. Of course you'd have to evaluate whether the CPU cost is within Kissu's budget.

I would think the main cost would be computing the hash for the image. Once you have the hash, there ought to be a way to compare it to a large number of known hashes very quickly.


>I would think the main cost would be computing the hash for the image. Once you have the hash, there ought to be a way to compare it to a large number of known hashes very quickly.


I was implying that something stronger than blockhash will take longer. There's a slowdown of 0.5s to 2s, probably longer with something else


I've been considering moving the hasher to Tabas server to get more cycles, but turning the image into a thumbnail at that step in the posting procedure requires some effort/planning.

good article


Are you hashing the full images or the thumbnails?


blockhashes act as a replacement to md5 which is done on the tmp file, before it's turned into a thumbnail. This allows it to be used in the do_filters function of vichan. The thumbnailing function could be moved back closer to the start in which case it could be used instead of tmp, but I'm not sure if it's placed after the filters because someone found an easy way to ddos vichan by flooding with post files


well, I guess it would be tinyboard in anycase


I suppose that it's not actually a huge issue to move blockhash back towards the end because I isolated it into it's own function and MD5 is more nicer to users with duplicate checks


File:182f8cf8617def7266ca52e0e8….jpg (4 MB,2845x4030)

duplicate checks for users and database storage is done with MD5 and blockhash is computed whenever needed.




File:N5rJZEUBpy.png (475.65 KB,1920x1080)

Why is the catalog on some boards broken for me?


been out all of today.
about to fix it


back to the way it should be


rule suggestione: prohibitte political postse


File:[MoyaiSubs] Mewkledreamy -….jpg (394.83 KB,1920x1080)

That's already the most fundamental rule of kissu, dummy


hmm, maybe I should have said "one of"


for the most part yes, but blanket banning a topic doesn't get done a lot. It's better to target specific concepts and commonalities.


There was some discussion about this a while ago. >>3768 and >>>/poll/570 from back then are still up.


when I've finished styling(dark, yotsuB, kissu css files) and weeding out the last few bugs the homepage will be swapped with a new version. The original will be left available as an optional version. The new version will offer more things to do and better information on what's happening on kissu. This is the first page that will be made default of the Kissu UI remake and serve as testing for things that go wrong and presentation unappreciated.

Links from homepage will 302 to vichan pages since the variant isn't yet ready for true usage. The homepage will hopefully help evaluate which design choices aren't appreciated before styling and fixes are done to thread and board pages.


two new anti-spam measures to take into account when spam becomes a question again are an issue with the checkBans function that was brought up to me and perceptual hashing with image modifications.


rsolved an issue with slow file uploads


Added whitelist item. Reappeal if it didn't go through


File:Screenshot at 06-51-10.png (305.58 KB,1849x924)

Homepage variant almost complete.

Another item is to make the trip decoder easier to use with this system… easy .exe file and some readme doc stuff.


Cool's idea for temporary name change


but I wanna be anomalous


File:It might be higurashi no n….jpg (22.89 KB,300x442)

we've got anonymous at home


File:Screenshot at 06-18-00.png (401.8 KB,1849x923)

updated the site, but running into some small things that need to be fixed with the server config.

For example, it shouldn't be possible to reach this page and I need to turn on api updates.


File:Screenshot at 06-45-30.png (642.62 KB,1852x923)

From the looks of it the new homepage is functioning as intended with some missing images for spoilers and youtube videos.
I'll keep the changes to that until issues around this page are fully resolved.


Why is everybody now Maebara Keiichi?


File:Screenshot_2020-10-02 all ….png (838.29 KB,1812x2660)

Looks like video thumbnails on /all/ are being overriden by the music thread's thumbnails. Was this happening before?
We all have a little Keiichi on the inside.


Actually, it's not the thumbnails, it's the linked videos being overridden.


It's a long-standing issue related to youtube embeds in general.


ack, I must have changed the config file without thinking about it


When you use vichan's easy config editor it will overwrite some of the config you do manually to the instance config file.

I suppose I might as well try a JavaScript extension vichan provides to replace videos with thumbs


I set up alternative system that vichan has to do youtube embeds.

Names are cycling again, but probably will be removed when cool wakes up.


Nice, that was fast.


File:cf3de4c102.png (682.97 KB,1899x1007)

Homepage has… a few bugs. Namely it seems to give a 404 error page whenever I enter it now in which every link is broken aside the /all/ one. Clicking "Home" leads to an actual 404 page, and trying to select the boards tab doesn't work.


Or maybe not? I just clicked into it again and now it's working fine.


Problems to fix:
- file io race condition
- non file and static thumbails
- Recent post times
- Recent post CSS
- Mobile button CSS
- mobile data usage
Race condition causing API pages to be suffixed with garbage data. I had to fix it from my phone


File:09aea03b04.png (609.08 KB,1443x737)

Another small issue I have is with the expanded thread that shows up when you hover over one on the homepage. You can see a scroll bar on the expanded thread that pops up, but when you try to scroll through it, it disappears. A minor annoyance, but I'm not sure if that's intentional or not.


- error page full body color


Right click and enable preview pinning


File:firefox_G1w3raYe1r.png (5.59 KB,362x283)


Also with youtube videos having a thumbnail of sorts now will you be able to add those to the front page?


Summary of things


Need to handle it for spoilers, moved files and such as well


File:nonfree javascript.png (596.79 KB,1280x720)

The new homepage refuses to load properly on certain browsers.

Not Working:
Firefox (Mobile; not quantum)
Internet Explorer



load it without JavaScript and it should work

if not I'll work on that amoung with testing it on these browsers


react is mit open source, and this UI is designed to be readable with no JavaScript users


File:Screenshot_2020-10-02 Home….png (113.9 KB,1903x938)

Still doesn't work.


I see,
I wonder why I made this client js only. I'll change that.

I also intend to make the default page still available but i haven't set it up yet.

I'll have that around in a few hours


File:IMG_20201002_203429.jpg (1.6 MB,2976x3968)

Ah, beta.kissu navigation doesn't work either because I disabled the SSR functionality so I'll have to do some work there along with setting up original.kissu.moe to handle standard style with navigation


original.kissu.moe exists as a vichan fallback on all pages currently and in the future
beta.kissu has SSR navigation with new css sheets and same homepage
waterfox working,
assumed similar reason for fail on other browsers, still need to test on windows.


File:c37faffefe029142176f19a25b….jpg (845.24 KB,1000x1412)

>waterfox working
cool, thanks!


wokring on that 404 bug


File:firefox_ohoKo6i0hv.png (271.76 KB,1055x500)

this is really bright, and on the dark theme


yeah, you shouldn't use dark or hazuki on threads as yet, assuming you're browsing through beta and not a bug that you're vaguely alluding to.


Is kissu.moe/all not using the beta site as default for you? I can't get the original /all/ to load


I set it to the way I want it, you shouldn't be able to reach that page unless you're in beta.kissu
original.kissu.moe/all should have worked too


File:waterfox_qzHVPr8tsQ.png (9.77 KB,307x240)

Already talked to vern about it, but if you use ublock origin one of its filter lists breaks the RSS button on the main page.
"Fanboy Annoyance' filter list has a line to block ##.fa-rss. So if you're using it you might have that problem. I have a bunch of other filter lists active so I don't think I need that one, it seems centered around social media


File:Capture.PNG (190.95 KB,1903x967)

wtf is wrong with https://kissu.moe/qa/2
and why do the first six page numbers link to /ec/ ?


ugh, forgot to setup nginx rules for the pages. It's expected there to be some issues because I only wanted the homepage to be available at this point in time


you shouldn't be able to reach those pages now. I still need to debug and finalize the thread pages and the homepage is to work out the most basic of issues beforehand.

currently working on nojavascript, thumbnails, recent post issues and putting a mutex on the filewritting.


going to be uploading a set of fixes so try to tell me if something's broke


uploaded a new set of fixes to the homepage. I think this is everything listed


decaching doesn't always work that well. I'll have to improve vichan's communication with the side server


-Home page not decaching for rebuild properly
-Mobile buttons and other mobile CSS


not sure why decaching wasn't working. Rebuilding the server file fixed, maybe mixed something up.

1) mp4 thumbnails not showing(will have to go through all the types) [Finished?]
2) News Items times and updates [Finished]
3) Mobile theme starts slightly zoomed out [Finished]
4) Notifications on new posts not triggering[Finished]
5) Optimizing side server ban ops
6) Optimizing of server communication

That's all I currently see for technical issues. I think a combination of them leads to decache issues where the homepage is showing "corrupted" data.

Some other issues:
Refactoring side server
Optimizing scripts for better performance


when the homepage has the above issues resolved, I'll address some other site software issues(better hashing and trip decoder) giving time for more obscure issues with the homepage to show up.

This way when approaching the thread pages it can be in a more ready state from the getgo.


uploaded a set of fixes. The odd issue of homepage not updating makes me wonder if it was a change I made to post requests. Waiting to see if that fixed it.

In a stage of optimizations and refactors now.


- notifications crash mobile[Patched]
- notification permissions not set properly on click[Finished]
- preview Read More treats [random] as if it were a tag of that name and tries to close it[Finished]


notifications on mobile(chrome specifically) have to be done using the webworker notification system. https://notifications.spec.whatwg.org/#dictdef-notificationoptions it's based around persistence meaning even when an application is in the background you can still be notified for it. I believe this also allows for people to be notified of kissu even when it's not in a tab on moba and desktop.

This isn't in my design philosophy currently and was always just an extra on the roadmap. I'd like to keep it simple and focus on making everything work before adding and tuning something intrusive.


I really like the randomly generated names. Because its inconsistent, it keeps anons anonymous, but it feels a bit warmer, and it allows to namefren without standing out.


reasonable and interesting idea to at least consider hypothetically, but what would be a good set of random names that don't age?


don't think there are any more issues with the home page in terms of features. Just problems with updating now


File:Capture.PNG (639.3 KB,3840x2100)

What the heck is this, Vermin?


Going with names of evergreen shows is the safe path, but in my opinion it doesn't matter.
If you stumble upon a name you don't know, you either ignore it or it's a recommendation.


File:home page.png (742.29 KB,1920x938)

I do have an issue, the home page is not refreshing and looks the same way it did about eight hours ago. Even the banners aren't rotating.


problem with updating yeah. I have to address those today


Could you please remove or change the "dancing on a thin line" flashing banner?
I don't have photosensitive epilepsy, it's just kind of annoying.


Site stuff on >>>/b/4243 or >>>/b/
It was considered yesterday, so I modified it down to one frame.


Much appreciated. pardon, thanks for letting me know, I'll use that next time!


I'd rather it be removed altogether then, frankly.
t. banner maker


File:tummies....PNG (336.32 KB,440x733)

i dont think this is the right image for the happenings thread on the homepage


Post it as a url. That will help me




I see, odd that it's getting flagged


f81ff407f007ec03ff83fc03fc01f801fc01fc01fc01fc03f801fc03fc03fe07 collides with fe01fe01fe01fe01fe01fe01fe01fe01fe01fe01fe01fe01fe01fe01fe01fe01 with value of 259

I had originally thought that blockhashes were similar based on image similarity but that might not be the case

I lowered the similarity threshold for the time being


or more likely my initial tuning was too strong


Believe the problem with no homepage updates was a mutex not getting unlocked on error.

issue with the thread thumbnails being incorrect on homepage might be that the server cache isn't indexing properly because I can do a cache purge and it fixes but deletes don't.


>whitelist token is invalid
unban me please kudasai


why do you have something in the whitelist token field


oh there is junk in there, it's the same junk as password field
i didn't do that


epic, suppose that's a bug then.


i forgot what i wanted to post
this is really your fault


Modified so that it won't block from posting when garbage is in the wl token field.

More of a temp fix, though my ideal might be impossible if browser autofil gets in the way.


Why not a button or something that you can press to input in a whitelist token, so that it can't autofill.


possible. I still have to program something for the react UI to handle token input so it will probably be similar in design.


put up a fix.. will know pretty quickly if it's working or not.


It looks like it's operating within my expectations as an acceptable replacement.

There are just some performance issues to work out now on the three axis of post server, API server and SSR server.


bleh, global search on mobile mode is broken.

Actually a few mobile issues I'll have to get to


File:20201007_100211.jpg (490.32 KB,1076x1913)

Speaking of mobile, could you fix the banners? They extend past the boundary of the page sort of, meaning that a portion gets cut off unless you zoom out.


something on the server went flat and had to reboot it. No .php files could be used. Tried nginx restart but that wasn't it, so it could have been any variety of possibilities around PHP


restarting php7.4-fpm fixes it... time to read logs...


requests to API server are causing PHP to die.

I had planned to deal with this today. I guess there are too many requests being sent and never terminate?

 No.4738 - - [07/Oct/2020:02:30:18 +0000] "GET /api/properties/error.json HTTP/1.1" 200 531 "-" "-" - - [07/Oct/2020:02:30:18 +0000] "GET /api/properties/site.json HTTP/1.1" 200 1414 "-" "-"
access.log being flooded with this

I see a problem with the NGINX config. I dunno if that's what's causing it to crash out, but it's a problem either way


started the page again after some server configuration changes.


yeah, probably won't be too hard to do this.


File:26aad19394.png (6.86 KB,464x133)

I like how the homepage notifies you of new posts in the corner of the screen, but are you potentially thinking of ways that people can get these notifications (if they want them) without needing that page open?


summary system is designed to be on every page and integrated into the way that people get notified of responses to their posts.

These notifications will be on a slider value of "notify of everything", "notify of owned", "notify of nothing".


probably should add a board filter for it too, noticed that i was getting notifications for /test/ posts, and i'm assuming that /trans/ posts may show up on it too.


Or not /trans/. Although I know there's some people that probably would just want to be notified of all /qa/, or /jp/ posts.


likely will be based on the options of which boards you have hidden or not, but I'm not there yet.


File:Screenshot at 20-46-00.png (6.66 KB,446x57)

https://imgur.com/qPt82YR time(min) of optimization operation by ban count
https://imgur.com/E7zrOit average time(sec) to process a ban by ban count

The mix of ipv4 and ipv6 is causing some problems with sorting for quicker ban optimization operations. Getting it down to a O(n*m) or O(n log m) is going to mean copy some niche MySQL queries.


select hex(ipstart) from bans order by length(ipstart) desc, ipstart desc;


k, change made the optimization operation last 4 seconds as apposed to 40 minutes. Nothing to write home about.


all should be stable now, if something's not working then it should be wokring.


added more fixes


could you maybe fix this thing of posts taking forever to show up/not showing properly?


Why isn't there an option to add an image to polls on /poll/ anymore?


pretty sure i know what causes it, unless you mean something I recently fixed

the hell...


I set vichan to message the api-server after certain functions are called, but from the looks of it this causes a lot of redundancy wasting the CPU and slowing down the api-server considerably.
When I call the rebuild function or perform mod actions this issue is much more problematic.

This issue is to be addressed ~today leaving UI optimization and mobile fixes for later sessions


For example, stopping the API server right now causes posts to go through instantly and I imagine page rebuild as well


did lazy fix for post speed. Still need a real fix


when did replies lose the subject field
I miss it


like yesterday


but why


Unused and the last use was someone accidentally posting their tripcode in it.



I can do a quick check, but I don't think it was used before that.

(check shows subject is used for replies 11 times out of 4500 replies on the main boards jp and qa)


May have resolved the post speed issues, but communication is still pretty ugly


also made it so you no longer get notifications on hidden boards.


File:a.JPG (301.65 KB,1920x970)

Cloudflare error page in /ec/ counter (on /all/), fixed by refresh but annoying as every reply takes half a page


Going to be uploading another post speed fix, this time resolving issues with mod tools through batching requests

520 error... Odd. Doesn't trigger for me. I ought to make the error not fill up the entire page though.


multiple fixes uploaded.

Also added an error check on the score counters.
Seems like Post-server => API-server communication is at a stable state.


Being able to use the old home again makes me very happy.


original pages will be on the original subdomain indefinitely.I haven't put a lot of thought into legacy pages.


Not a particularly big issue, but the notifications for new posts from the homepage -- not the recent posts section, the actual browser notifications themselves -- improperly link to the aforementioned new posts. Instead of formatting the link as it should (e.g. https://kissu.moe/jp/res/7139#7153), it instead extraneously adds the board name and a dash, like this: https://kissu.moe/jp/res/7139#jp-7153


that's to make it easier to highlight and refocus on posts from the overboard in the future version of the thread pages and make it easier to work with scenarios that involve posts from multiple boards on one page, but it causes issues with vichan pages.

I suppose for the timebeing it can omit the boardname+dash


I'll probably have to bite the bullet and begin writing automated tests for the high risk aspects of the various software used. Anything that deletes a post or file requires a test case to be safe. 99% coverage is completely overkill.


Invalid token error came back, but should be fixed now.
Made mobile fixes and etc to home.

Working on fixing mp4s after making a change to strip exif data from them. Hover not working as intended in home as well.


File:aeiou.png (6.23 KB,527x114)

Seems you can't post without attaching an image.


things are messed because apparently removing exif data from an mp4 file so people don't accidentally post their GPS coordinates is a tough task


k, that's done now.


remaining to fix before more new stuff:
- posthover on homepage
- wltoken input


More new stuff as in updating /b/ or other things that need to be implemented? Really looking forwards to the release for boards after how nice the homepage turned out


Probably moving to board pages. Refactors and non high risk security are secondary.


modified homepage preview behaviour.

Unless there are any big issues with that then work on the home-page and error-page are done. This puts work thread pages in a good position with the majority of work already done through similar components with the previews.



modified whitelist token behaviour so it won't get acted on by browser autofil


File:1598349917058.jpg (56.03 KB,420x510)

>time was up for /megu/


Please don't alter the files people upload.


Inadvertent doxxing shouldn't really be tolerated...


Has inadvertent doxxing been a problem?
Why break the site for everyone else just in case?


The files people open should be the files I post, not the ones the administration thought I wanted to post. Metadata can contain useful information. Altering every file breaks all sorts of stuff like looking up a file in boorus by its hash. Most of the files being altered don't have personal info in them in any case. It's just pure damage to the file.


What about things like APNG or 4chan Sounds or 3D Custom Girls models? Should that data be scraped away because it's metadata and metadata might be used for doxxing?


GPS data shouldn't be included in someone's upload. That it's the norm for exif data to contain sensitive information is a problem with file formats. An anonymous site shouldn't be giving away information about who the poster is without their permission and exif data is often attached without the user having awareness of it.
I haven't seen a situation where stripping exif has been a problem.

I haven't confirmed, but I believe all that gets modified is jpg and mp4. These are the common formats for cameras. If it's that png gets modified too maybe can see about removing that.


It would be one thing if you just modified files that had GPS data in them, but you're modifying the majority of files, almost all of which contain no GPS data in their metadata. There's no need to strip out all metadata, most of which is legitimate and intended, to deal with the few cases where a camera silently added GPS coordinates. Just detect when that happens. I would also argue that instead of silently stripping it, you should warn the user that the image has GPS coordinates in it so they don't dox themselves by uploading the same image somewhere else.


It's not my job to make people smarter, it's to prevent conflicts and controversy before they happen.

I can look into which tags I think should stay and go. Effort for not much gain, but it's not like you've been wrong in the past on these things.


Good to hear. It's hard to predict how much gain we'll get out of something like this. My main concern about modifying files and removing metadata / extra data is that it might stifle creative uses of the board like the 4chan Sounds script was for 4chan before their mods decided on no fun allowed.


new thread and board ui almost there. Fixing thread sorting, poll graphics, optimization and layouts, then beta.kissu ought to be back up for read-only purposes. Still have to get the submission UIs prepared.


Vern... Why is the archive broken?...


not sure. Splitting it's actions between two processes causes complicated scenarios. I'll check it tomorrow


notice that sometimes i need to refresh to see new posts on a board, and just clicking on the board doesn't workl


still not sure if that's a browser thing or a server thing. Attempts to fix it are mostly futile


API server was trying to archive a thread that the post server deleted

I think it's browser settings. Either this or Vichan isn't writting the pages fast enough


I suppose it's possible that I removed the cache headers that it's acting worse than before, but even with them my ff browser caches basically everything it can.


The free react charting libraries are hopelessly littered in watermarks or sluggish.

At least nice tutorial on doing it yourself..

seems mostly fixed now


File:Screenshot at 22-43-19.png (77.51 KB,426x651)



File:1588578385041.png (6.63 KB,354x208)

i tried to make my own kissu from the github to dab on otamin but whenever i make a post from the quick reply it says the thread doesn't exist
what am i doing wrong
i tried rebuilding using nothing but the js files listed in the quickreply js but it still doesn't work


it's probably broken


i don't plan on fixing it anytime but you probably need the "advanced_post_form" setting turned on


File:Screenshot at 02-27-05.png (369.61 KB,1346x882)

few bugs I've realized while doing the CSS but looks nice and will upload when those are done. This will be everything prepared except posting.


File:Screenshot at 07-58-09.png (331.53 KB,1468x881)

beta.kissu.moe running again with new UI
Homepage updated to allow you to hide threads

beta.kissu will continue to be tuned for a bit and then final dev work on the UI will being to allow users to post. Initially plan to put it onto /b/ and /poll/, but will be default with original.kissu holding the vichan layouts.


File:post time and post number ….png (162.03 KB,1901x595)

Interesting edge case: >>>/qa/56354 was posted before >>>/qa/56353, but the post numbers are swapped. My only guess as to why this happened is because I had to fill out a captcha, which as far as I can tell just holds back the post until the captcha is submitted. Probably not too serious, but could potentially present problems in the future I suppose.


Home notifications aren't set to work with previous localstore values. I'll patch this, but before then you can just set it to what you want in options.

Yeah, it holds back the post until it's sent. I could alter the time it's stored. Could just leave it in as a funny quirk unless there's a bigger issue(though it could mess up certain sorting methods, I'll have to see).


I think it may be better to have the post form expanded and board name at the top of pages. As it stands right now the header feels a bit empty.


the idea is for the head of the page to be used for content. The first thing seen should be threads.
A standard board list might be a bit nicer however.

You mean the button or the post form? No work has been put into preparing the post form otherwise it would be on the site in some places. Button could be bigger as well.

It might be good to put the header banner somewhere else.


File:e989893899.png (508.3 KB,1920x969)

looking at vichan's layout it seems more like there's a lot more color on the top of pages. That might be a factor as well



Vermin, you might really want to consider doing something about the whole rebuild on deletion thing. Although a CP ad was deleted, because there's no rebuild on delete, the post stayed on the homepage until someone makes a new post. Which, if you figure someone posts CP in the middle of the night when nobody's posting... Not a very good scenario to say the least.


did i not fix that or maybe


most likely overwrote a fix on upload


Communication errors between api and mods seem to cause delete to not issue the rebuild command, so indeed I fixed it as I knew in the past, but the design choice I made seems to be error prone.


I've made a list of 21 bugs on the thread layouts.
In advanced 16 things to check over in the posting aspects.

Redesigns and refactors are lower priority at this stage. When everything on that list is checked off it will either be on /b/ and /poll/ or beta if I'm not confident in it as yet due to bugs in posting or layout issues... but I'm hoping that the post form is the most straightforward to test and fix since it was verified to work before I started finishing sections.


Lately captchas don't work. I'll fill them, get the code, and then get stuck there. I'll have to close it and wait until the requirement for a captcha goes away, only then will I be able to post.
The token isn't working either. I tried to put it again in the new field but it says it's invalid.


JavaScript may be crashing somewhere. I entered a token in and it's fine


post me first line info on kissu.moe/agent.php


The token does work now, must've been something on my end.


the captcha's still my question though


Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0


if that's still needed



It might just be unclear that the captcha is sending, but I'll install that version


I checked with the same useragent and don't get any issues with captcha on /test/ or /all/. If it happens again press:

go to console
copy paste everything in there into the reply box or a pastebin and send it



might be of some interest that I managed to eat on donation money this month


Will a Tommorow theme be added to kissu-vi? I noticed its missing from this site


How does it vary from Dark-Kissu? I added too many themes just because it was easy to do it. In the future it's going to be cut back. Though an idea to create freshness might be to switch around the theme sets and temporarily remove the defaults for something new. Just a thought. I'm not thinking of styles as much as technical problems right now.


I read a comment here about tomorow, but it looks deleted. I likely won't put dev effort into making a dark variant.


made a tomorrow theme for kissu, although it feels incomplete and i lack motivation for learning more CSS


File:Screenshot (43).png (18.8 KB,1188x200)

caught the captcha issue on camera
is this it?


naruhodo. You're on original.kissu.moe
That makes things clearer.

Should be fixed now


Looks pretty nice. Let me send it to cool as well since he doesn't check this thread.


yeah sure


the reply background shouldn't inherit from default he said.
I think the option colors should be different from kissu dark or unified like other themes.
there's some small issues that I think I'll point out tomorrow, but otherwise I think I'll add it as an option when I update the site again monday morning and work them out as they come.


in response to concerns on spoilers, going to add in NSFW image spoilers and Spoiler image spoilers so there's no ambiguity between the functional purpose of features. If something has a spoiler then it should be assumed that it will be spoiling something. Kissu won't unspoil things, but it will spoil things the staff thinks will ruin a show.


On a similar topic, perhaps it's worth discussing that there should be a casual markup-spoiler and a real-markup spoiler so people can use hidden text creatively.


You could probably do this via the functionality of the spoilers themselves. "Surprise text" spoilers could remain hover over to unspoiler, whereas "real spoilers" could be made click to unspoiler. This might also have the added benefit of preventing users from inadvertently spoiling themselves. But, that assumes people differentiate and use them appropriately.


im going to be uploading and replacing files shortly.


captcha not working as intended. Just give me a bit to work that out


-Kissu-Tommorow.css added as a new theme
- Mods and users can make file uploads into NSFW spoiler and content spoiler
- More updates to UI(noticed two other bugs to resolve by end of day) putting thread data into a pretty solid state. Layouts will likely be altered when the next part of the project is done, the post forms.
Since the post form needs to handle the same data as vichan I shouldn't update any more data that can be sent by user to server.


File:6wsYV1w.png (41.02 KB,845x665)

new design likely having a good effect on keyword rankings


File:LefZSa3qRnkg6nPl6049YdAMFi….gif (413.1 KB,500x90)

this bannre makes me sade, forlorn, angry, confused, n numerous other negative emotional states plz remove id.


The pain will maek you stroonger


I really can't get used to the board title being on the sidebar rather than above the threads. It just looks better the other way.


File:a74pK4bfpu.png (189.48 KB,961x764)

The Last50 Posts view button is broken for Kissu-Vi. I would have to manually input https://kissu.moe/qa/res/4165+50 for the Last50 Posts view to work. Not much of a big deal since there aren't huge threads on kissu that lag machines.




Made a mistake with cites for the beta UI so the post chain feature is going to be a bit unreliable until threads expire. Doesn't effect vichan because this table isn't even used in the software.

Broken the stages of preparing the post form into 5 days of tasks, roughly 17 items to accomplish of which some might already be finalized in my initial development. Post form was already fully functional, just had a bunch of bugs so it might be that these 17 steps are the last before I'll place it onto /b/ and /poll/ for public tests.

These kinds of things after the entire UI works


WL'd autoban


Can you reinstate the reverse image search links?


Never mind, I'm a retard who didn't realize he had accidentally turned 4chan X off.


all that's left is handling bans and captchas, removing bugs from the text field, misc missing features and CSS... then it is officially completely usable..
after which I'll keep it in beta for a few days to find harder to see bugs, then put it on /b/ and /poll/ where more specific issues can be addressed such as useability and design


The quick reply post preview system makes the work on richtext less valuable. I'll likely end up releasing a near finished version on beta without it and perhaps the final if it doesn't get done by then.


after backup, going to be replacing files for vichan again and set a new version of beta before I finish the richtext, captcha and ban handling.


performance, specifically on mobile, is abysmal. I'll have to address this before setting it up as default UI on /b/ and /poll/.
Likely my tag parsing algorithm is badly written.

/f/ item limit is going up to 30 because fileboard indices can hold more data


All that's left now is to finish off the CSS, bugs as they appear and rich-text. If rich can't be done tomorrow I'll work on it as things go along and progress as planned. It's an optional.

Performance is improved, but catalog generation on mobile device still takes a bad amount of time to do.
Going on a few trials,
on desktop-Vichan this thread takes 0.9s to complete
On desktop-Kissu this thread takes 2.3s to complete, so there's still room to save time.
Mobile, just counting it's something like 3s to complete vs 8s. A factor of 3.5 I guess

Default dark theme.


site might flicker on and off for a bit


File:1ff80554bb40907f0be9f64ea6….jpg (213.9 KB,800x466)

/b/ and /poll/ have been switched over to the new UI. If there are problems with the functionally then tell me. Now would be the appropriate time to address stylistic issues. No new features will be added at this point in time.


File:filenames-for-edit.jpg (305.99 KB,777x1088)

currently there's some bugs with poll colors and YT thumbnails clip off in the catalog.

I'm quite happy with how it's overall turned out. When all issues have been resolved the site will use this by default and the vichan layouts will stay on original.kissu.moe


File:b69f341666.png (209.41 KB,326x808)

I think the amount of empty space to the left of replies is a fair bit excessive. If possible it should probably be kept to a minimum like on the regular design.


Some of the changes strike me as odd.
Like taking out the update and index buttons, how posts are now highlighted or >>5114.
The sidebar is fairly large, only the RSS warrants its size, and I don't see the point of having the news/boards/circle widget on the lower right when it could also be on the left, like in 4taba, or the post tools part being minimized by default when it's so small it's hard to notice it.
It's nice to be able to scroll a thread while in the catalog, but now images are so big that a row on my screen has gone from eight images to five. If I scroll to just below the link banner I can see 36 threads on original, only 15 with the current UI. Though that's not a real issue given the slow speed.
And finally the pettiest one, the options box says priveledges.


File:509aaf9824.png (333.7 KB,1920x969)

The original idea with the sidebar size was that it was going to match the recent posts size, but that's no long the case. I did make it smaller that it used to, but it also contains the square banners so it can't be too miniscule.
It's also the only way to navigate a board and update the index.

The problem is that my idea for the boxes is to have them be separated by function. If I were to put the bottom left widget into the sidebar then it would be doing too much. Futaba's sidebar is solely for threads, while this is used for navigation and post controls.

The catalog was hard to do, they're just thread thumbnails put into a catalog display. I think they should be smaller or customizable size, but that wasn't a feature I had planned. I'm not that satisfied with it and think I'll revise it a bit. As a quicker fix, probably will reduce the thumb size so that it's not a vichan large, but medium.

Typo yeah


Since you've finally put the new design on /b/, do you think it may be time to make a new thread for bugs/design feedback? I think that there's a fair bit that could be tweaked before it's applied to every board. And I'd rather it be something that looks appealing than not.


File:1525997487801.png (830.01 KB,770x650)

Uhhh, where are the boards? I can't even get out of /b/ now without clicking on all/home.


I see, alright.
>It's also the only way to navigate a board and update the index.
Does it need to be? I would also bring up redundancy, in that having links at the top and bottom of the page took up very little space and was simple, the current UI requires you to click on the boards tab and is always present. I personally think sidebar+top/botton would be a good compromise.
>If I were to put the bottom left widget into the sidebar then it would be doing too much.
I'm not sure. Currently half of its space is vacant, it'd more economical.


If you shrink the screen it's no longer economical but instead you can't open up the report tools without it overlapping. I would need to put a scrollbar inside of the sidebar for it to work universally... or possibly have it do different CSS with different screen height which is possible.

The bottom widget is a bit odd, but it's the best place to put a hideable news tab. When you read the current news, you switch back to boards and don't have to worry about it until it gets updated later.


My opinion on the design: don't fix what isn't broken. Making regular browsing the same as the home page with no way to opt-out besides using https://original.kissu.moe/ is a very bad idea. It's way too different from what people are used to. Add a n optional sidebar at most that doesn't eat up space and get rid of everything else.


if the UI is largely differnt then it means that just because of the software there's a reason to use kissu over other imageboards that try to appeal to peoples autistic lack-of-change ideals. That's my opinion on huge changes.

Not fixing what is broken just means more stale 4chan clones, never advancing the idea of what an imageboard can do. The concern with changes being unintuitive is a bigger concern to me.


>Not fixing what is broken

I wouldn't consider any change over the usual imageboard format "fixing what is broken". There are many parts of the usual imageboard that I'd consider near, or just, perfection. 4taba is probably what I'd consider to be the closest to perfect looking design for an imageboard, even though it harkens back to the classic design a bit it improves upon and perfects it. There's nothing about any of the design choices that I'd consider unappealing there, and while this may sound like an argument that you should just copy it, it isn't.

What I believe is that you should do with your more modern imageboard look what tabamin did with his classic look. Improve and perfect any and all potential problems with the design until you can't make it look unappealing in any way. A different look can attract people to any imageboard, but at the same time it can also serve to repel them from one if it doesn't look good.


But there's nothing good about this change. It just makes browsing more difficult. I had to switch to the original layout just to post here.


Yeah, if you're not using JavaScript you would because noscript posting isn't set up yet.


File:shion shrug.jpg (110.66 KB,696x716)

He actually said he was going to base the new design on 4taba's once like what you're talking about. What happened with that? This one is hardly even a design, it's just the home page slapped on top of regular browsing. It's very unintuitive and clunky to use.


Some more thoughts:
now that i think about it there's too much in the side bar that's just there for the sake of "compartmentalizing"it doesn't necessarily look any better it just makes the information presented on the main page more minimal, which isn't necessarily appealing design, just more "modern" if I'd have to call it anything
at the same time the sidebar still looks a bit of a jumbled mess, it could probably be made thinner while retaining most of what it currently has
and that empty space (that needs to go) could probably go if you reduce the size of the rss feed
from what i remember having the hidden posts toggle be on the sidebar as well isn't the best idea, as some people don't want to remember that the posts they hide exist, so being constantly reminded of them seems like a bad idea


My point in the design could be stated as this.

Old fags are the cancer who have left imageboards to rot in obsalesence


Well then I could just call you foolish for trying to reject as much as possible about nice design for the sole purpose of spiting oldfags. You're better than this.


File:1438153778593.png (264.75 KB,480x600)

viichan is already modern and it has a lot of nice features compared to 4chan. There's no reason to drastically change the layout itself. It's very uncomfortable to be forced to use the home page.


My point is that this supposed constructive criticism isn't about improvements, but dragging things into the norm. I expect better of others to want originality and nog nostalgic repetition


My criticisms have not been made out of wanting to return to a more nostalgic design, I want your modern design to work out. However, when you reject any ideas to improve design that may seem like a reversion to the changes you've made as clinging to nostalgia you come off as obstinate and not willing to admit any possible faults. The design you've concocted isn't perfect. There are issues with it that you'd be better off addressing. How complete the main page feels without the sidebar is not a concern solely based off of feelings of nostalgia, unless you are willing to argue that the page looks good with the sidebar hidden. The empty space on the left is also a concern that is not in any way connected to past design except for the fact that others were observant enough to realize that meaningless empty space is not a good look. When I compare how the page looks without sidebar to the normal page it is not to say that old=good new=bad, it is to point out how barren the new page objectively looks in contrast, and suggest that it would be better if there were more in it.


I think it's a bit overly dramatic to state it like that. Imageboards have indeed been relatively static in design, but there's still been a lot of changes to them over time as well. In some ways there's more modern than social media, with WEBM and MP4 support.

There are some really great changes with this, but people have been pointing out the things they have issues with because that's generally how criticism goes.

Great changes:
-The letter buttons at the bottom for text stying is really useful to me. If possible, it'd be good for the letters themselves at the bottom to be affected by the effect it's responsible for, but this might look too gaudy for people.

-Post preview is amazing. Nothing else really needs to be said about it, it's just that good.

-There's post queuing. Others may not have noticed this yet, but just like 4chan X on 4chan you can queue up posts, such as for an image dump. This still needs support for uploading a list of files at once, but it's there.

-Good condensed reply window. There isn't lines for youtube videos and such. Condensing is good.


Have you considered that this "nostalgic repetition" is actually better than just the home page slapped on top of the entire site? It's much clunkier and less intuitive to use. You can add all the quality of life improvements that you want otherwise, but this isn't one of them.


yes, because even if a design is poor, originality has functional value. The initial version (which anyone could have trialed on beta.kissu) is not final and modifications will be made to it. Those who are obstinate about software have no choice but to use 4chan because everywhere else is just a copy. Originality is king.


>Condensing is good.

I disagree slightly, the condensing done on the reply box is good, the condensing done on removing the board header and top/bottom & other controls from a thread have been a bit much.

I disagree that it's just the homepage slapped on the rest of the site. It's obvious that what he's going for is the site to be in a sidebar, but I really disagree with such modern web design condensing choices, especially when he can't make the sidebar look that much better than a not-so-great design.


File:1490919093757.png (38.91 KB,161x194)

Originality for the sake of originality is retarded and for desperate web-designers who want to justify their reason for being employed. You can't just slap together some crap and then claim that it's good because it's shiny and new. You have to justify why the changes you are making are an improvement over the old. You're no master class web-designer, and shouldn't consider yourself impeccable when it comes to what looks good.


Cool, but the basis of goodto you is how well I can copy from 4chan.


It's not and I haven't claimed it to be you stubborn teen. God, why must you be so infuriating? Just keep the new design on beta if you're unwilling to listen to any differing opinions on design.


File:1527209207043.jpg (38.49 KB,556x556)

There it is him again with his self-righteous arrogant attitude. You really need to stop being like this if you want your site to be successful. Learn how to accept constructive criticism.

Don't mind him, he's extremely stubborn and says stupid things like that all the time.


You're not helping.


>You can't just slap together some crap and then claim that it's good because it's shiny and new

In case this went over your head I wasn't referring to the new design as crap (it's alright), I was using hyperbole to express what comes off to me as the the philosophy of many misguided folks trying to innovate.


I've told you. It's original because it's original. Anything less is a copy of something that other people could find anywhere else. If you don't think the originality is good then it needs to be revised, but you can go to any other imageboard if you want the good old stuff. Having something unique means you can only get it here.


And I've told you countless times, original!=good. Good is when you take what is original and then refine it until it's something that can truly be appreciated as a breakthrough.

Why is the empty space before replies a design choice I should praise as marvelous and beautiful? Because it's something the other imageboard designers haven't done?

Why should I praise the barrenness of the page when not using the sidebar? Why even make the sidebar hideable when it's so integral to making the page not look trash?

Should I not say that the sidebar can be condensed? Do you consider the way it looks as though it's the result of months of hard work on it? Everything you've done and changed is certainly functional and works great, it just suffers currently from looking crap.


Your argument is subjective opinion so I retort by saying originality+execution==good. Your argument is not originality but execution of design. I don't think my execution is good, but if you think some design is bad because it's from the intention that nostaligia is a problem in imageboards then I'm just going to tl;dr


I've been saying that all the technical changes you've made are great, and that your execution could use some work. Not in a single post have I said anything bad about how the changes function, I just think they could look better. And of course that's a subjective argument because art is subjective.


>I disagree slightly, the condensing done on the reply box is good, the condensing done on removing the board header and top/bottom & other controls from a thread have been a bit much.

Hm. What do you mean by "board header"? The list of stuff that's in the bottom right corner now?


File:1527209207043.jpg (80.55 KB,556x556)

Being forced to always use the home page objectively clunkier, unintuitive and less aesthetic than the regular layout. Regular browsing shouldn't be exactly the same as the home page, no fucking site does this. Go consult with some web-designers if you think our opinions on this aren't good enough.


i have been discussing development for months here and no web designers or input had been given so I assume I am right and you are wrong.


File:1527209207043.jpg (86.66 KB,556x556)

Go ask one and see what he thinks about it then. I don't think you have much experience in web designing, you're primarily a programmer/coder.


File:1541374592366.jpg (169.22 KB,500x500)

Admittedly I didn't want to give any design input until you were finished working on the technical aspects of it. And the home page looked great so there were no problems for me to bring up, and I assumed (or hoped) that they regular layout would turn out just as nice. Evidently that hasn't been the case and there's a few things that I think you could improve upon.


so who am I asking?
the default homepage is garbage though. It cements in my head that you're a brainless nostalgiafag who thinks the amount of culture and preconceived notions locked into your head is the most valuable metric for a poster on an imageboard.


I think people need to see it directly themselves before they'll feel open to commenting on stuff. This is basically the reveal day to the majority of site users and not people specifically following site development.
I think when it comes to site development and such this is still the midway point and not the final stretch.


File:1527209207043.jpg (84.14 KB,556x556)

You are misunderstanding my point. I'm not saying the new homepage is bad, but being forced to use it for regular browsing is. It should be separate from it.


File:fdff253701.png (450.97 KB,1920x969)

It's literally the exact same thing as ota.
In what way is what's here any different


To be fair most people don't browse ota with the sidebar, they browse it through ota-ch.com/jp

Also to add onto this I have brought up my concerns with the main page's emptiness before now.


I have no idea what you're talking about. Do you want a ton of clutter and useless "lol im the admin and i something important to say" clutter everywhere?


1) It's not optional like ota (unless you switch to the other site with the original layout which also gets rid of the new homepage)
2) There are no boards on the sidebar for you to click and browse comfortably
3) Annoying notifications popping up
4) Unnecessary bottom right thing staying there all the time
5) The issue of properly allocated space people having been talking about


File:1429849963868.jpg (15 KB,190x190)

Who are you talking to...?


File:154892cd78.png (20.02 KB,454x595)

just disable notifications. And they're only annoying because you don't actually want to know what's happening on the site.
It shouldn't actually default to notify for everything though.

Bottom right is draggable... just drag it off screen. Admittedly it could be improved and hidden somehow


I don't understand. Do you just want me to throw random images around or have a background with a pattern to it?

use your eyes and guess


File:137360812.48_Screenshot_20….png (171.12 KB,1920x1006)

I legitimately can't understand the connection between me advocating for less barrenness on the main page and
>"lol im the admin and i something important to say"

Just look at how 4taba handles its header. Not much clutter, just information about the site you're on, the board you're on, a banner, some links to other pages and the ability to navigate back to the board's index. Everything is functional without the sidebar with the benefit of also looking appealing. Even with the bit of empty space on the bottom 4taba has it covered with a very nice css. You could probably do similar with all you've got tuckered away in boxes or the sidebar right now and it would look much nicer. Also while neat, I don't think the banner needs to really slide into the page.


File:1527209207043.jpg (79.38 KB,556x556)

Democracy time.


File:No Contribution.png (20.63 KB,400x400)

Here's a list of technical as well as aesthic problems I've noticed:

Post hover activates even when the quoted post is within view.

Ancillary to post hover, is that it causes the quoted posted to grow by a few pixels, causing the entire page to shift and undulate. I believe this is also present in 4chanX. Nevertheless, the default behavior of vichan and 4chan to simply highlight the post feels much less distracting and off-putting. This isn't the case when the quoted post is the OP, however. That said, this behavior is completely absent when using the Luna CSS. This is part of a broader trend of the CSS themes not being consistent in behavior and feel.

The gradient that is applied when highlighting a post (i.e. clicking either the quote, or clicing "No." (#)) seems a bit excessive. In my opinion, it stretches way too far across the post, but at the same time not far enough it seems. I suppose what I mean by that is that the gradient approach seems too inconsistent. Frankly, I feel the standard method of highlighting the whole post present on vichan and 4chan is sufficient and looks better aesthetically. On Hazuki in particular, the combination of the pink gradient highlight with the light gray, and white colored font as well as name text is a bit straining and difficult to read.

Speaking of CSS issues, the dark blue "[Expand Poll]" is very hard to read on both Luna and Hazuki, but perfectly fine on Kissu.

The condensation in the reply window is too abstract and non-descriptive in places. For instance, the "M" (presumable for "More options") gives the user no indication as to what it actually does. Seeing as it's already on a line of its own, there's really no reason not to change it "text formatting options" or something similar. Someone also mentioned possibly giving some visual cue as to what each type of formatting each letter represents. I'm not necessarily sure I agree, but the current method of needing to hover over each letter to learn what it does seems a bit convuluted to me. This frankly just strikes me as uncessarily striving towards further compactifying the reply window. On the one hand, this could be beneficial for mobile users who have limited screen real estate, but there's really no reason why the relevant options can't just say what they are on desktop.

Relatedly, certain icons could really do with a hover description. The chainlink for linking videos or images makes sense, but the pencil and ruler for post preview is a bit more abstract. The thumbs-up icon for stickied threads also seems a bit out of place.

The post queuing feature is a nice touch, but it has a rather fatal flaw: it's prone to nuking posts because it works contrary to the expected behavior. Instead of doing what you'd expect upon hitting the x icon for "remove selected post," it instead deletes the contents of the left-most post instead of whatever post is actually selected. So, if you have 3 posts queued that each say, "This is the x-th post," when you hit x icon, what will happen is that, "This is the first post," will be deleted, regardless of whichever post you're currently viewing. Furthermore, if you're looking at, "This is the second post," and hit the x icon, you'll suddenly be shifted to seeing, "This is the third post." You might initially think it actually worked properly in this case, but you'd be wrong. Upon clicking 1, you'll be greeted by, "This is the second post", again, showing that the left-most post is always deleted regardless.

Not really an issue, but the post preview window updates in its entirity every time you make a keystroke in the reply window. This is mostly a good thing, but the "post line" updating every single time is a bit distracting. The post number constantly pings around between 1 and 999 everytime you type something and the date and time updates as well, albeit accurately.

The linking option is also a bit stupid to say the least. Even if you put in a valid link, but forget to include "http://" or "https://", you'll get an error stating, "Invalid URL Format URLs must contain an http." I'm aware that this is already the case with URL linking on the vichan UI, but there's really no reason why you should assume whatever's being posted is a HTTP link, especially considering I don't believe you can link from FTP, so this seems a bit... stupid.

Having a "[Read More]" button on long posts, seems like a good idea, but I think its really only necessary when viewing posts from the index. Having to expand long posts in "reply mode" for a thread is frankly a bit of a nuissance.

Altering right-click behavior is an anti-user feature, in my opinion. While true that for things like copying or selecting text can still be done via Ctrl-A or Ctrl-C, this detracts from users being able to open links in new windows or from being to use extensions that make use of the right-click options window. Relatedly, it also somewhat breaks the ability of mobile user to post hover. On vichan, mobile users can click-hold on a quote backlink to post hover. This is now impossible for mobile users because the default behavior is to open the custom right-click options menu instead.

Finally (Not really, there's probably more issues I've not yet found), there's legitimately no reason not to include the CSS theme selector in the sidebar. Its exclusion honestly baffles me considering literally everything else was moved there.

I would comment on the over all aesthetics, but this is apparently a contentious issue, so I'll abstain for now...


i suggeste: renaming /cry/ 2
bc /cry/ sounds gaye


how do I get infinite scroll back on /all/
[str]I can't close options once they're open[/str] the X was invisble on dark theme
how to make it stop asking to enable notifications

post preview and formatting toggles are neat


>how do I get infinite scroll back on /all/
Figured it out, original subdomain still has it


Why are long posts truncated even inside the thread? Also, why not integrate the bottom right thing into the sidebar? Also, this feels way less responsive than the previous layout. It takes a full second to display off-screen quotes and replies when you hover over them.


Also, I think the reply form at the top of the page should be expanded by default.


4chanx causes the x to vanish


File:b8a0ca0192.png (265.49 KB,1113x571)

It shouldn't default to notification spam mode, should have been set to notify of replies to own posts. You can fix it back in options. >>5200 . Did you get onto this new UI's /all/ somehow?

Performance reasons mostly. As a tradeoff because when reading a thread a second time you don't need to see all the posts you've already read. Just reduce their size.
Because I want a way to have the news hidden by default and to put the boards somewhere else to the side since they're not important.
I don't know why it's taking so long for yours to load cites. It takes ~190milliseconds on my computer and this was never a concern when I was fixing performance.

Having a giant post form taking up all the room for posts was what I wanted to get away from. On small screens having it open becomes very bad UX


there is a bug with the previews after page navigation that needs to be fixed.


>Performance reasons mostly. As a tradeoff because when reading a thread a second time you don't need to see all the posts you've already read. Just reduce their size.
This seems like a pretty major issue to me. Truncating posts in board view is okay, but inside threads? If I'm viewing a thread, obviously I'm interested in the posts therein. Having to manually expand every single long-ish post, including the OP itself (?????) is ridiculous.

>Having a giant post form taking up all the room for posts was what I wanted to get away from. On small screens having it open becomes very bad UX

The old reply form is about twice the height of a banner, hardly "giant".

I also don't understand the point of the right click override. There's already an options button right there in the sidebar, and the other functions don't feel significant or well-implemented enough to merit it (why not a minus icon like in the old layout, which only requires one click?)

Regarding load times, it may very well be something on my end. That's not the only way in which the new layout is unresponsive, though. For example, when you make a new post, you need to refresh the index before it shows up.


this post >>5201 is no longer important to you though. It's now me responding to you. When you open up this thread again, your post won't be worth reading in it's entirety. It seems like wasted space. There's no reason you need to see the OP every time you open this thread or view the catalog, you have the images and first few words basically memorized so additional information is just bloat.

The old post form dominates the entire screen when you open up any page. That's terrible. Why are the viewers looking at a post form and not posts as the first thing they see?

Right click changes exists for the sake of existing because it hasn't been done and I figure no one right clicks anyways. Double right clicking brings up the default context just like how YouTube does it. Hiding threads shouldn't be something that gets thrown in your face for every thread. I want people to just see the threads and not a load of options that no one cares about 90% of the time. If you look at 4chan or the original layout, posts do not even get a minus icon, so there's no reason for me to add one to them either.


the refresh thing is probably easy to fix. I just modified the post server so I wonder if it will work as expected now, if not I'll keep checking how to fix that.


as expected, it works now, but posts are much slower to process. There's still work to do in that department.


>you have the images and first few words basically memorized so additional information is just bloat
This is simply not how discussion works...

>Right click changes exists for the sake of existing because it hasn't been done and I figure no one right clicks anyways.

So, change for the sake of change. I bring it up because I actually do right click all the time, to open threads and images in a new tab and to copy text.


it's how conversation works... you don't go back to a previous soundbite every time someone says something. I don't need to reread my post to remember what it said. Unless you're a first time reader it's helping cut fat

It could be that a triangle(click for more options) beside No.5207 would be better. Then I could remove the post tools in the footer bottom left. It exists for sake of experiment. On FF it was originally placed into the context menu itself but Chrome doesn't have that capability to it was unified into an override to make things more consistent to test across browsers.


The ability to quickly reference what was said is one of the greatest advantages of text-based discussion, and is something that basically everyone takes for granted. And, if anything, it's the first time readers you should be pandering to here, because all it takes for someone who's already read the thread to bypass the "fat" is to scroll to the bottom/press the end button/etc.


File:5edb08019b.png (220.87 KB,1920x969)

I don't think a single click is impeding anything since the majority of posts in a thread are not worth reading and it gives smaller posts the chance to be recognized along with big ones. Anything other than the first 150 words is unnecessary to decide if a post is worth reading or not. Academic papers have an abstract that basically shows off that you can judge a text wall(aka an entire paper) based off of a few key words in an 150 word paragraph. Having to scroll past a large wall of text that might not be relevant to you though, that's making it less desirable to read a thread because there's more things that are irrelevant on the page than relevant.


That's just your opinion, though. In any serious discussion you're expected to read the whole thread to be able to keep up. Requiring an extra step to view longer posts is just discouraging for lurkers who want to jump into the discussion, and for posters who put effort into their posts.

In >>5201 (which I had to manually expand to check, of course) you say the reply form is bad because it takes up all the room for posts, but it seems the majority of posts are not worthwhile or relevant according to you, so I'm having a hard time understanding just what it is that you want to do here.


Many in my opinion can be ignored, but having a post form take up the entire top of the page means you're given less of a chance to see which ones you want to keep


To my knowledge the main places that practice this sort of principle(every post is equally important and no consideration should be made to `cut fat`) are forums, imageboards, facebook and instagram. Though I haven't used instagram ever and facebook like a decade ago.

Those who try to cut down on content that the user may not care about are far more numerous and used by people for serious discussion. The cite-chain feature is an aspect of this, but I think read-more hiding is also important. Perhaps it can be improved upon, but just because you open a thread does not mean you care about every post. The OP might be an exception.


Read more hiding is a bother that does not need to be. There is no reason that the "fat" as you call it needs to be trimmed down to a tweet's length. Those interested in discussion where they have quick digestible posts can go on twitter if they so want to. On an imageboard it's simply a nuisance and a "fix" to a problem that doesn't exist, in fact, given the opinions of most it seems more like something you broke. If I am to hover over a reply now in a thread to read what it may be the discussion flow is now broken since all I can read of those replies is the little snipped you assume to be all that I'm interested in.

Don't assume that everyone has the same dismissive mindset as yourself and has no interest in ever checking over discussion while writing new posts. There's no reason for this change, and no demand for it either. It's probably the worst decision of this new design since it's intentionally worsening the user-experience.


Also for any text art/ASCII threads this would discourage ever having any. Since would be such an annoyance to have to click to view each and every art post.


Imageboards by convention already do this hiding thing in the index. Other imageboards agree that having huge text walls is a problem. I am not the only person who thinks text walls shouldn't dominate a page.
4chan banned ascii and braille art for this reason >>5216 that it dominates a page and prevents others from having their opinions equally valued for being brief and not a giant wall of braille. The read-more system allows both to thrive together.

Lets say I added memory to what's expanded though, so that when you refresh it doesn't force you to do it again. I think that would be the compromise here, no?


And yet the same can be said for the banners, with the key difference that the reply form is actually relevant to the act of posting. It would help a lot if you took a moment to explain what you want to prioritize, what is expendable, what is the goal of the new layout, and so on, because as it stands, you claim to be open to feedback, but all complaints are met with "well, I disagree", "you're asking for a 4chan clone", etc.

This is not true. Social media actively strives to prioritize "relevant" content: on Twitter, for example, when you're viewing the replies to a tweet, tweets that generated more reactions and replies show up near the top, while tweets that have been flagged as possibly containing offensive content are shown at the bottom and are hidden by default. The same goes for other sites like Reddit and YouTube. To me, this idea of "cutting the fat" feels very condescending and insulting, and far more reminiscent of social media than imageboards.


I disagree because I actively programmed it with an idea in mind and I can defend every decision I made and tell you the reason I did it. If I think it's a bad criticism and don't understand why you're complaining then I'm going to challenge you on it.


Social media vs imageboard. The arcane arts of elitism.
Obviously without a doubt we have the superior platform to them. It's not like the main constituents of the fanbase are psychopathic stalkers and nazis.


No, I still think it's a bad decision that doesn't warrant compromise. 4chan's mods are dickheads and everyone agrees that they can go fuck themselves for removing brailleposting and ASCII threads when people were enjoying them. I don't see any reason to take the terrible decisions they make and employ them, especially when you say you don't want to be a "4chan clone".

The read more in the index is simply a necessary evil because it prevents extremely long posts from taking up most of the index in case the thread itself is of no interest to the reader. Once the user enters into a thread it means that it has their attention and interest, so obviously it follows that any posts within would as well.

You are extremely unwilling to accept criticism and that's been evident throughout this discussion, where you use the most baffling logic to defend your contentious and poor choices, and then act dismissive towards said critics. If you want to make kissu into a niche board solely tailored for yourself then feel free to slap it onto a subdomain entitled something like "verniy.kissu.moe", but don't just make choices that people en masse feel to be a bad idea and then force it onto them because it's "change".


No one is complaining about truncating posts in the index, because that's not a new feature.

>it dominates a page and prevents others from having their opinions equally valued for being brief and not a giant wall of braille. The read-more system allows both to thrive together.

Text art is not an "opinion". In a discussion/exchange of opinions, long posts tend to be valued more than short ones because, unsurprisingly, you can say more in 3 paragraphs than you can in 10 words. Your system discourages actual effort and earnest discussion.

>Lets say I added memory to what's expanded though, so that when you refresh it doesn't force you to do it again. I think that would be the compromise here, no?

A good compromise would be to show all posts in their entirety by default inside a thread, and add a button to the sidebar or top of the page that trims long posts. And then in a few months you can make a poll about how many people use that feature.


Don't attempt to change this into a discussion about elitism, this is about your poor choices.


That's faux logic. Practically every defense you mount amounts to, "we'll, it's change and change is good," or "I designed it for this reason." Both of these responses neglect the very real possibility that people can and do disagree with you!

What the hell are you trying to prove? Who are you trying to impress by saying this?


No no no, you don't see. If he can dismiss everyone's opinion in this thread because some shitty people use imageboards then he wins.


I've accepted that right click isn't going to work. Saying I don't accept criticism is false.
>The read more in the index is simply a necessary evil because it prevents extremely long posts from taking up most of the index in case the thread itself is of no interest to the reader.
4chan works, but there is only one 4chan, the rest are poor imitations. I'm fine with accepting things work on 4chan and applying them, but it can't be the site. Trying to copy 4chan just means an irrelevant clone


You're defending your decisions with an awful lot of speculation, like "this post is no longer important to you", "I figure no one right clicks anyways", "the majority of posts in a thread are not worth reading"... while I am telling you that this isn't the case for me, and that these changes are detrimental to how I use the site.

You were the one who brought social media sites up in the first place, but yes, I do think the imageboard format is far better than social media. I'm also confident almost everyone here would agree with me. What about it?


Did I say you have to copy 4chan you illiterate? And of all the design choices you could concede on you chose the one with the most promise that probably could have been something good if you put some more work into it. I don't see that as a good concession, just unwillingness to make it work.


Irrelevant to whom? Do you think people post here because they want the cutting edge of imageboards?


Well then I just don't understand what you're trying to convey because we're obviously on completely different terms of what is valuable and what isn't.


I develop here so it can be the cutting edge of imageboards. Unfortunatly I am not a schizo admin or an autist admin, but a paranoid borderline admin who wants to make things that I think are interesting and high tech.


Is all you're able to think of in terms of "4chan" and "not-4chan"? I've been saying that being able to fully read the contents of each post in a thread without needing to expand everything is valuable to discussion and just the general readability of threads. All you've been saying to justify your reason for changing it is that 4chan doesn't do this or that somehow cutting fat is used on places for "serious discussion". Even though from what I understand on places for serious discussions like mailing lists there is not fat cutting.


You are acting fairly autistic about your design choices.


I suppose the question, then, is whether you care more about making the site interesting for yourself than about the userbase.


I mean, I get paid like 10 cents an hour and handle the BS that would make others quit. Knowing that tabamin ended up quitting imageboards for a fulltime job with a similar community for going the no javascript route, I know that this userbase is going to the grave on the belief that tradition is more important than creativity.

I don't think anything valuable is coming out of this discussion anymore. I'm trying to hold a reasonable discussion on a feature and decide if it's worth tossing or not, but it's just about tradition and partisan social media vs imageboards retoric.


Go fuck yourself, vermin.


As I say, it's not about the features but weather I submit to what you want or not.


That comment isn't about you not submitting to my whims, but rather to you just dismissing the entire argument like a dickhead.


I literally already told you why I think it's a bad feature, in a civil manner and without resorting to appeals to "tradition". I'm not even saying I don't care about your opinion or don't appreciate you running the site. All I expect is that you heed the userbase's opinions when making major changes to the site's functionality. I don't think I'm being unreasonable.


You make it very clear that you don't want feedback, you want praise for your "originality". With >>5235 you make it extremely evident that there's no reason to try and discuss anything since you will ultimately dismiss whatever reasoning people present to you. So with no reason to continue discussion I say go fuck yourself.


The discussion on if read-more is a good or not has arguments on both sides.

As soon as someone starts using brail in a discussion and people are getting their posts flooded out by legitimate posts will you praise the idea and wish(who am I kidding) that the feature existed. Your argument to this point was that 4chan is a bad website, and I disagree. 4chan is the best imageboard. But there is only one 4chan.


Gosh, that sounds like an awful scenario... If only imageboards had a safeguard against people flooding threads.

Ah, I've come up with a brilliant idea! I dub it "moderation", they will be people that have the power to moderate discussion and delete that which is a detriment to a users experience!


At that point, it's an issue for moderation to deal with, not a unilateral decision to implement a punitive measure. People left 4/qa/ because of bullshit like that.


So your solution is that only one type of post may exist in a thread. Ascii art in legitimate threads is to be deleted because it floods.

Man, it sounds like you guys really hate ascii art being used in threads.


Quit being disingenuous.


I don't see how I am. You can't use ascii on vichan or 4chan. You guys said that this is a reason the idea is bad and I'm saying that this read-more on the contrary actually helps it thrive in a thread as a legitimate response.


If someone posts text art in the middle of a discussion, I'd probably chuckle or react with indifference, and then scroll down. If someone made several posts in a row consisting of text art with the obvious intent of disrupting discussion, I'd probably report them for flooding. What is your point, if there is one?


No. You presented a scenario in which, "people are getting their posts flooded out." That phrasing only makes sense in the case of spam. /jp/ started off thriving off of ASCII art, but you gradually eroded that away by allowing more and more images making it no different than any other board. Were you to apply your same standards now as then, ASCII posting would have never been possible or acceptable. This pointless posturing you keep doing is ridiculous and proves nothing other than your unwillingness to actually earnestly listen to what people are trying to tell you. I'm nowhere near as inclined to say that you're making things worse, but you acting obstinate even over the most mundane features is not helping my image of you whatsoever.


That intent isn't clear and common usage of text are is in practice spammy requiring the eventual removal of charactersets. Truncating posts means that flooding either intentionally or unintentionally ceases to exist


Okay, so, again, what is your point? Are you saying that the reason you implemented the "read more" feature is actually to prevent flooding, and not what you said 40 posts ago?


No, it's just another point to bring up that despite the thoughts that it's useless it actually can be useful in some scenarios. In practice the idea was done because of potential and untested performance issue where people spam tags to kill load times and on the other because I think that long posts are unnecessary.

The argument that condensing a post makes it harder to use was met by the idea that most platforms, and even imageboards, condense items that get too large. The response to this was that social media sucks. That's why I'm not very convinced.


>The response to this was that social media sucks.
Not even Floens Clover app, let alone any other imageboard browsing app condenses posts. Your premise is faulty. If you want to implement app-like features, make an app.


File:80070a5116.png (3.89 KB,323x333)


File:0768a48203.png (809 B,236x36)

more abstractly


It's a scenario I have never seen happen here.

It doesn't make sense to condemn me/us for what you perceive as sectarianism when you yourself are resorting to appeals to majority. Just because most platforms condense posts/tweets/comments/whatever doesn't mean it's a good thing, and again, I must remind you that no, imageboards typically do not truncate posts in-thread, only in board view.


just to be clear... my argument that successful companies decide long posts should be shortened before you consent to seeing them is met by a claim of 'that which hasn't been tried must be bad' when it is in fact true that people have tried it albeit in a different medium.


hopefully it's also clear now why I am calling you a purist or a traditionalist and that i think you believe that the correct way fo doing things is more valuable than trying something new.


File:22 - Myth.mkv_snapshot_00_….jpg (111.5 KB,1280x720)

Verniy, kissu isn't a fucking business or a successful company. Get off your high horse. It's just a silly site made to house in people from 4/qa/ who got kicked out of there by the manager. You will never turn it into anything more than this no matter how hard you try. All you're going to accomplish with this mentality is kill the site, not make it successful.


Cool, but was I right that you're dismissing ideas just because a company has pulled them off to great success or did I misunderstand you? I think that just as certain people here suck off 4taba's design, I'm allowed to praise Twitter's brevity for creating a fast paced, constantly evolving environment.

It's not like post truncating even prevents people from having a long post. If anything it speeds up the rate at which you can skim. I don't understand why it's hated.


How in the hell are "successful companies" relevant in any way for a niche imageboard?

>that which hasn't been tried must be bad

I never claimed this. I'm complaining precisely because it's being tried right now before my eyes and I don't like it.

Well, yeah, I find "it's worked fine so far" to be a more compelling argument than "it's new". But just because I believe in "if it ain't broke, don't fix it" doesn't mean I'm not willing to give new features a fair assessment. For instance, I think the sidebar is a good feature, because it alleviates the problem of wasted horizontal space.


> I don't understand why it's hated.
Maybe if you read the constant swell of posts telling you exactly why they dislike it you would know.


He can't. They go past the [Read More] mark and therefore he's incapable of digesting them in full.


>Cool, but was I right that you're dismissing ideas just because a company has pulled them off to great success or did I misunderstand you?
You're talking to more than one person here. I even explicitly told you so, and I've been posting from the same IP all this time. Please stop bullshitting.


It would be nice if there was an option to always expand large posts in thread

When you hover a post reference the highlight on the referenced post has a thickness and causes everything below it to offset by a couple pixels

Minor but the regular right click popup disappears on mouse0 down (on windows, when clicking elsewhere to dismiss it), the override one only disappears on mouse0 up


>It would be nice if there was an option to always expand large posts in thread

No, it would be nice if that was the default and Vermin's personal preference were an opt-in option.


File:1444353969881.jpg (35.49 KB,419x396)



On the truncation, I would retort that long posts do actually deserve to take up that much space. Short posts of one or two lines are by far the majority, it's actually a disservice to the rarer posts of greater effort. I would argue that on top of that, walls of spam are a funny imageboard thing or should not be counted because they are to be removed by default, but that may well discredit me.
On the new design as a whole, I'm only interested in its upgraded RSS. Some features like the catalog search are good and I like them, but the other changes outweigh them for me so I'll stick to original. The real issue is that as it has been shown, it strongly clashes with the simpler imageboard aesthetic and functionality. I fear that will drive users away.


What I agree with:
>If I am to hover over a reply now in a thread to read what it may be the discussion flow is now broken since all I can read of those replies is the little snipped you assume to be all that I'm interested in.
That's bad design.

>It would help a lot if you took a moment to explain what you want to prioritize, what is expendable, what is the goal of the new layout, and so on, because as it stands, you claim to be open to feedback, but all complaints are met with "well, I disagree", "you're asking for a 4chan clone", etc.

I haven't done this yet and I should.

>To me, this idea of "cutting the fat" feels very condescending and insulting, and far more reminiscent of social media than imageboards.

I don't harbor ill will to other platforms. To me it's just optimization, not insulting, but it could be seen as imposing as you imply.

What I disagree with:
>How in the hell are "successful companies" relevant in any way for a niche imageboard?
Because good sites copy from good sites.

>If I'm viewing a thread, obviously I'm interested in the posts therein.

Not 100% true. An ascii post in a thread may not be relevant to you and require being seen.

>>you have the images and first few words basically memorized so additional information is just bloat

>This is simply not how discussion works...
You can know a post by a few words, just open it up if you need to quote it again later

>and, if anything, it's the first time readers you should be pandering to here, because all it takes for someone who's already read the thread to bypass the "fat" is to scroll to the bottom/press the end button/etc.

>discouraging for lurkers who want to jump into the discussion
More time is wasted by having them read something that might not be relevant. A person can skim faster with more hidden.

>In any serious discussion you're expected to read the whole thread to be able to keep up.

I don't think this is 100% true. You can decide what you want to read it by opening it up.

>Those interested in discussion where they have quick digestible posts can go on twitter if they so want to.

Too many people have gone to twitter instead of imageboards. More can't afford to go. Many for discussion have gone to reddit as well.

>Don't assume that everyone has the same dismissive mindset as yourself and has no interest in ever checking over discussion while writing new posts. There's no reason for this change, and no demand for it either. It's probably the worst decision of this new design since it's intentionally worsening the user-experience.

Arguably there is no need for any change, but I think that it's required for a site to be good to have it's own unique systems and not be a webring of similar software. Have something that makes you stand out from the others. A controversial system would be pretty good in this sense. To me, it benefits user experience. That's why I'm pushing it.

>Also for any text art/ASCII threads this would discourage ever having any. Since would be such an annoyance to have to click to view each and every art post.

Ascii art as a response to posts is too spammy and a truncation would make it easier to read threads that consist of 10% ascii art.

At this point it's caught up. I'll post and get to more from this point on if need be.


meant to respond to this


This post is too long. By skimming the first few words I not only memorized the entire contents, but have determined I don't need to read it.


>A controversial system would be pretty good in this sense. To me, it benefits user experience. That's why I'm pushing it.

But every user aside from you (who arguably has just pushed for it because it's "change") has just acknowledged it as controversially bad and detrimental to their user experience, what makes you believe that with such a bad reaction from the little test group of sorts on here that people as a whole will respond positively to it? Even with all the justification you've given I still disagree with the decision and feel that for myself it would be very annoying to deal with it all the time. Also I have to agree with >>5268's point that it is detrimental to discussion in the way that it discourages people from effort posting and encourages small dumb replies.


File:1450704415963.gif (983.14 KB,370x278)



File:1501781678696.jpg (269.82 KB,739x734)

>Because good sites copy from good sites.

What "good sites" are you talking about? Twitter and reddit? Why didn't you just stay on those instead of using 4chan then?


Unhelpful, and unproductive. Cease posting.


You're the reason imageboards suck and the only people who come from other websites are politically minded people. Nazis are literally the only people who can put up with such asinine imageboard nationalism


Stop replying to him and get back on track with your failing arguments.


>I don't harbor ill will to other platforms.
It's not ill will, it's recognizing that different sites fill different niches and not every site needs to be part of the same amorphous blob of intrusive, curated content.

>Because good sites copy from good sites.

See above, and again, popular =/= good.

>More time is wasted by having them read something that might not be relevant.

Not for you or I (let alone an automated character counter) to decide.

>I think that it's required for a site to be good to have it's own unique systems and not be a webring of similar software. Have something that makes you stand out from the others.

I would posit that content and community can be this something, and are much more important than unique features.

Unrelated, but greentext is kind of hard to read on the Hazuki theme.


I suppose it requires a more clear explanation of intention. This is just my opinion on it and if knowing this you still don't like it then fine. I'll consider the alternative. of just in index.

Having large posts means it's easier to notice them.
Space becomes a resource on imageboards that's contested.
In order to prevent it from being contested it's better to make the playing field level, that way someone's 200 line, poorly spelt essay does not have more weight than a brief and concise 3 sentence answer that clearly states the problem.

What I feel like this current system promotes is people being meaninglessly flowery in language just so that they get more reactions. That's the core of the problem.

Are you fine with people padding out their posts just to have more lines and more impression against others and are you fine with a concise post being harder to see than a brief one.

Is long more valuable than brief and is it worth the convenience to create such an easy meta of padding posts. The people created the reddit spacing meme because they hated what I'm describing.


No one is intentionally padding out their posts to garner more attention or epeen points on an anonymous imageboard mainly devoted to anime and discussing arbitrary things people find interesting.


No one yet


And no one has yet created a bot to dump CP across all threads. Should we preemptively disable image posting now too?


What if's are not a good argument. As I think I've been told by you before...


Well, the flaw with your premise is that it doesn't occur. Something similar is only present in the handful of boards where being verbose is cool, but that is not likely to happen here. The few longer discussions we had in the past no longer happen.
>make the playing field level
Quite the opposite, you are discriminating against large posts.


If every one is poor but me, then the playing field has been leveled


I understand your point. However, I think you're trying to solve a hypothetical problem that will probably never come into play. Do you have any concrete examples of posters here "being meaninglessly flowery in language just so that they get more reactions"?


File:6738045d8d.png (43.63 KB,623x678)


green text pasta basically is an example of this


Do you have any examples on this site that wouldn't be deleted?

And how would you justify how annoying it would make reading a thread like https://kissu.moe/qa/res/57768, which since you featured you acknowledged as a good thread.



But we don't have greentexts, and pasta is rare.


>posters here


well, I think doing it by character count is a bit of a mistake so things are getting truncated inconsistently making it seem worse than it is. By line would be better in which case there wouldn't be any effect.

Most posts are 3-5 lines in length. Doing it by character count makes it worse so you will have to hypothetically assume that I'd change it to work based on number of lines rather than characters.

But again... the software defines the meta and text walls will get responses regardless of quality


Why do you base so many actions off of these baseless presumptions?


Because they have a base that doesn't exist in this site yet, but I assume that eventually the site will have to deal with the same problems every other place faces of histrionic posters.


So why punish the current userbase based off of paranoia?


File:single fact.png (19.13 KB,207x239)

>the software defines the meta and text walls will get responses regardless of quality


Loaded question. Not worth answering that, but I'll assume you said "So why punish the userbase off of things that haven't yet happened".

To which I would say that making a change in response to a problem is much harder than planning for problems ahead of time.

Why does everyone gravitate around greentext in /r9k/? Because it allows them to get easy attention on an otherwise mundane story.


No, I asked specifically about your paranoia. Because that's what this comes down to, not things that haven't happened yet, but things that given the nature of the site and the posters on it, are extremely unlikely to happen.


It's not really that unlikely. Henri on ota is called by some an attentionwhore and the only reason he didn't come here was because I made using tripcodes a novelty rather than a method. An actual decision about the software effected what kind of poster did not come.


So why not extend that to the rest of 4chan, since it's all running the same software? Hell, what's the point of having different boards then?

It's ridiculous to suggest that the software, and not the userbase, defines the meta, except maybe in specific cases such as live boards.


I guess you're right. You could effectively fend off all the effortposters with this design.


>the only reason he didn't come here was because I made using tripcodes a novelty rather than a method
See >>5297

This is literally just your conjecture.


I don't know if the argument about software effecting meta is really relevant.

Is it worth discouraging attention whores by making text walls harder to exist?


UNATCO hurt my weenie


File:[SubsPlease] Ochikobore Fr….jpg (172.31 KB,1280x720)

I'll be writing a few things today, but not all at once...

As for the social media thing, it's important to remember that those places are for-profit businesses that prioritize monetizing traffic and clicks over people and content. Stuff like "click to expand" or articles being split into multiple pages is there for tracking and advertising purposes and not for the user's benefit. I know I'm interested in the content because I clicked to view it already.
I consider posts, especially long ones, to be a type of content creation that everyone is able to do. I think that by default it should be seen in total for a couple reasons. The first is that superfluous mouse "work" can be aggravating to people, this is most easily seen by people expressing annoyances with spoiler tag abuse. The second is that there shouldn't be any barriers to dissuade people from long posts, as people have said. When someone decides to write a long post they're making a conscious admission that the place they're posting to is worth the time and effort, much like creating an image edit or whatnot. I think the UI itself shouldn't take this for granted.

>Unrelated, but greentext is kind of hard to read on the Hazuki theme.
Do you mean the replaced green text or the original? There's just something overriding the original CSS turquoise-like color in the new setup


> You can't just slap together some crap and then claim that it's good
I literally can. Henry Ford did this all the time with his cars.


File:firefox_PhDBFAsBPZ.png (21.22 KB,760x148)

What do you mean by "replaced"? Anyway, this is what it looks like for me. Granted, my screen is pretty shitty, but I think the shade of green is too dark to read comfortably.


File:1445278996014.png (242.78 KB,368x438)

I'm sure vern will love being compared to such a great, successful capitalist.


File:Untitled-2.png (89.06 KB,427x664)

Hm, is it different for you? For me, the original CSS greentext color is there until the post is expanded.

Oh yeah, something I forgot to mention, vern. It'd be really, really good if you could keep the drag and drop functionality to files. As in I can drag an image file from a folder onto this reply window and have it as my upload choice. I really got spoiled on that feature of 4chan X


No, it's still the same color (the bottom one) even after expanding the post. Top one looks good.


File:815312d28a.png (5.96 KB,467x212)

open up options. You might have an entry for quote that's overriding.


File:waterfox_WlSPaDp6vD.png (9.42 KB,422x172)

Strange. Yep, I blanked it out and it's working with the original color. I definitely didn't edit this myself, though, so maybe something needs to be purged in the site files somewhere?


if you checked the site on beta.kissu a few weeks ago you probably picked up a localstorage value i unset


File:5c4091be83.png (7.92 KB,533x275)

this is the way it is by default. I removed the style override


K, I wrote down 42 issues.
I'm going to remove everything from the main column except the footer and threads/posts. Likely to put boards into the sidebar and put the wide banner in it's place. Reply will be moved into the sidebar. CSS changes into sidebar

>This is now impossible for mobile users because the default behavior is to open the custom right-click options menu instead.
It's impossible because I completely disabled any previews in mobile mode except quote chaining. Previews in mobile is a really dumb idea and gets in the way of opening a link in a new tab.
Likely to discard custom context menu


>Previews in mobile is a really dumb idea
I literally use it all the time. Having to click replies, and then being flung back and forth around a thread is an objectively worse user experience than just being able to see a preview like normal. Being able to "skim" quoted posts to follow a conversation is immensely helpful. The only time when it's not is when the quoted post is particularly long, then genuinely warranting going to the post itself and reading it there. But... if those long posts are going to be truncated anyways, what point is there for a casual reader to even bother looking to begin with?


File:IMG_20201124_234726.jpg (248.46 KB,1080x1799)

weather it's used or not doesn't justify that it's a hacky solution to the problem that isn't actually intended design. The cite chain system is controlled and easier to work with.


File:Screenshot_20201124-235352….jpg (600.86 KB,1080x2071)

Works on my machine.


File:IMG_20201124_235952.jpg (420.26 KB,1080x1782)

are you fucking with me?


File:Screenshot_20201125-000209….jpg (847.42 KB,1080x2071)

Operator error isn't my problem.


then you've just proven that it's an inconsistent and hacky approach to previewing on mobile...


The logical solution then would be to fix it, then?... I swear...


The previews are really nice and I don't want them removed, but do you think that you could make it so that if you do want to jump to a certain point int the page you could quick double click a post link?


Do you think you could make the scrolling through threads in the catalog more 4chan-x like in the sense that you need to click on them to scroll through the replies?

Just now it hit me that a real benefit of the catalog is to easily look through a bunch of threads at once and possibly find one that you remember and want to post in, but can't remember the exact text from (which now that I think about it is another reason that read more in threads would be annoying). The catalog really aides that searching goal, and the constant interruption that comes from accidentally hitting a thread makes it a bit annoying to try and skim through.


something like that is probably needed.

Holding down a button, bringing up the ctx menu, then closing it to act like a hover is a hack. It's not intended. This should be explicitly programmed by the author. It's not intuitive to anyone except someone familiar with imageboards. It's bad design.


however, clicking the link and a preview item coming up makes sense. doing 3 steps to get your desired outcome does not.


I suppose if you disable cite chains then I'll allow you to have this default shite behavior, but it's not ever going to be default asnd I'm not imitating 4chan's mobile approach, just because it's explicitly there's and I like my sytstem


Up to 54 issues.

Readmore will be re-balanced to trigger more rarely, but not selectively removed.
What I plan to do with Rightclick hijacking is have it act selectively on certain locations and be toggle off on double rclick.

- On homepage rclick will be enabled on featured threads to allow for preview pinning.
- On threads rclick will be enabled on the post info and file info lines to allow for hiding. This will be addition to adding an expandable that will allow for deletes and reports, meaning the "post tools" section will be removed.
- Readmore adjusted, rebalanced and altered to trigger only on posts of length:
>>4243, >>4244, >>4422, >>4483, >>4245, >>4494, >>4497, >>4503, >>5194, >>5269
So effectively only 10 out of 588 posts would be truncated. The same rules will apply index and catalog.
If it's found that there's still problems with this then more adjustments can be made


File:thats terror.jpg (14.2 KB,208x241)

Number 1: In 2019 95% of the Kissu population was satisfied with the website layout. Now it's about 20%.


Number two: In 2018 it took one click to open a thread in the new tab. Now it takes two clicks.


File:0db057f80ef52cd8afd0beb6d4….jpg (81.5 KB,784x808)

That's within acceptable margins


this has already been addressed as issue


File:Deleted File.gif (143.16 KB,200x200)

The beatings will continue until morale improves.


it would seem my agreeableness is causing some controversy.


hey... that's not deleted


My list of things to do is at 65.
Been procrastinating on writing them down here and giving a plan on each of them+removing anything redundant or contradictory.
Think I'll do it tonight


) Technical issues and bugs
1) Version numbers desynced
2) YT-Thumbs clipped in catalog
5) Poll labels are clipped. Not enough vertical space
8) correct oyasumi's image on /b/
9) When citing a post the cite won't be inserted at textarea caretposition
10) Deleting a QR Bud should prompt if you remove something with contents in it.
11) Clicking QR No. removes filename field
29) allow mod?/thread/number
Trigger drag and drop on any form item
14) Default notification level too high
15) Post Footer expansion after navigation
16) Performance on post generation
18) > character missing in QR Previews
19) QR items are missing titles
20) Mod action icons aren't all clear
21) QR Preview post no. should be fixed
22) QR Preview and post truncation issues
23) A URL should not need protocol to be uploaded
Shift hiding doesn't cancel sometimes
set all cookie reading to use memory after first access

24) CTX override should trigger on homepage preview images and post-info lines
25) Deleting a QR Bud should remove at the current position.
26) Updating and sorting(any long action) should change cursor type to progress cursor
bug fix causing bug in post hiding
37) Preview pinning off doesn't trigger instantly.
28) Article CSS style effects previews
31) Summary preview isn't always scrolled to bottom
32) Handle situations with cookies disabled
33) QR Quote shouldn't target contents in text area(or outside of post contents for that matter)
38) Submit QR through the meta fields
6) Add missing cites to database
34) Performance on ctx window and Previews
7) Handle conflict on frame close X's with 4chanX
36) Updates remove selection
Requires a different computer/OS to cross off
??4) Poll colors different in index and thread??
??12) Hover preview bugs up on navigation??
??17) Performance on comment generation??
??30) Page numbers show in threads on mobile??
??3) Poll submit colors bugged??
??35) QR textarea shouldn't have lineheight??
??Fix truncation leaving tags unfinished??
27) Changing summary notices can spam when changed to a more permissive level
13) Own post notifications sometimes flood
N Replies Ommited not updating on return

) Feature Additions
1) Thread updater
5) Handle public bans
/f/ needs styles
3) Mod edits or raw HTML posts should be given a tag for html injection
4) A cookie should be used to transition between UI types (Still needs NGINX config)
2) Posts should have a pop out triangle for deletes, reports and hiding(allows for removal of redundant features)

)Stylistic modifications
2) QR Previews need borders
9) All themes should have post borders so that cite hovers don't cause page shifts
3) Restrict readmore to index and previews
6) Allow floatbar to be minimized(hover effects off, bar size on, bar size off, positions)
7) Relocate widebanners into floatbar(refresh banners) and boards+circle into sidebar(style and why is it not working)
floatbar and QR should remember position(why is it not working and don't place items offscreen[default to 0:0 if fail])
9) Move style select to sidebar
14) New thread/reply should be moved into sidebar
5) When sidebar closed, offer limited ability to navigate site(return, boards)
11) Submitting a post should have a progress bar
12) Cite chain mode should not move to post, but if off it should move to posts
4) All truncations(summary, posts, titles etc.) should break with whitespace
??8) Cite hover preview position should target the cite like backlinks, not the post??
10) Post highlights have too much color/gradient
15) Generally speaking, improve catalog(imagesize and scrollability scrolling).
13) General layout and style of sidebar should be improved.
1) Shadows on QR items

) Merge Tasks
1) Make sure no forward progress on desktop machine is overwritten
2) Verify non-replicable bugs still exist
3) Finish off remaining tasks
4) Modify NGINX config on local
5) Upload to kissu on /b/, /poll/, /f/ and /ec/


The page refreshing can be rather intrusive when it comes to making responses. In particular, because everything updates, if you're trying to highlight something to quote, your selection will be undone due to the page refreshing. On the topic of refreshing, although I'm certain most people prefer auto-refresh to be on, the lack of any toggle is a bit annoying, at least as it relates to the highlighting issue. The real-time editing is interesting, but I'm not a fan of memory-holing.


>36) Updates remove selection
>1) Thread updater

The live updating I like. Undoing it is going to be a major hastel because this is just the way the library works. Makes it more flexible if the site were to allow user edits(memory holing perhaps resolved with time-lining them)


The JSON API is broken on /b/.


vichan API set to work again.
new api is on /api/(threads|properties)/[a-z]/[a-z0-9]*?\.json


Add feature:
Needs to handle public ban messages.


Improved tomorrow css from NPFchan repo (the rules page isn't broken)


Some modifications to vichan-post.php is making posting from the new UI messy. Going to keep it off on page starts, but still navigatable into from the homepage. beta.kissu.moe still open if someone wants to examine something about it.


Work continued today.
11 technical issues knocked off. 3 couldn't be replicated at this time.
No updates live versions(I need to get some files off of a desktop that's unavailable right now)


fixing some bugs in >>5564 made me realize there's an issue in vichan boards which use cloudflare which exposes the true IP.
If anyone needs to know it then they can pm me through some means.


9 technical issues with 3 more big things to cover in this segment.
3 left over can be put into the next set of items.

Additionally fixed the items in referenced in the above post as well as resolve a source of server IP leak through squid server making use of 4taba.
Issues on vichan seem to be resolved for the time being.


it'd be nice if the xmas board played christmas music.
just a thought.


This isn't really an issue, but it slightly bothers me that the homepage's banners don't rotate until the page gets rebuilt on a new reply rather than banners changing on refresh.


File:Screenshot 2020-12-08 1810….png (467.28 KB,1331x517)

Also, it doesn't handle banners with transparency well.


there's a backing on the banner items that would be removed, but I'm contemplating how to change the wide banners for this UI and other ways to integrate it into the layout without breaking the organization of posts down the left


The banner rotation might become a change after other things are worked out... there were some issues had with the banners loading after the page so loading with the page makes things more complicated, yet nonetheless more doable than on a php implementation


Found huge performance issue in cookie reading. I think this might completely fix a bunch of performance issues

Pointed it out to Cool.


shitaba subposts when?


It really is an amazing feature


caught up in fun arguments so less work done. Knocked off two bugs to make right click hijacking more isolated to locations where it's needed. Also some dumb QoL with cursor load icons

The next 10 bug chunk after this has some items I'll have to leave until after xmas since I don't have a proper testing environment to do these. There are three junks like this so the last few weeks of December will finish off the 2.0.0 version


in the near future (feedback #5) we're gonna have to discuss moderation and things of that nature.
There's apparently some problems the site has in this aspects and if the site ever needs new staff we need a reliable system which won't cause internal friction.

I'm thinking of ending feature development soon and running with what we have. Subposts are a major addition that also changes the meta. I'm fine with 4taba having it.


should probably have a side discussion on aesthetics, since that's the only thing that really needs work after the features are done


aside from moderation that is


Going to publish a Ruby(for fun) tool to fix kissu's cite table. I don't think anyone will need it for their vichan servers, but I haven't publicly released anything in a while and haven't touched Ruby before.

Also will fix the truncation issue in >>5354 if viewed through the 2.0-UI. This will wrap up all bugs I can touch at this time with my current setup.

We'll see next month, but I tend to like to focus everything in this thread since it's easier for me to notice issues if it's all in one place.


Have you done any measurements on the amount of moderation on Kissu? Creeping increase in moderation tends to be an issue with boards.


Too hard to track. Moderation is a feel thing where numbers don't help. Some people think more some people think less.

More an issue about if actions are justified and justifying actions


I think that the amount of moderation on the whole has more gone down recently than gone up. Only reason that it may be dwelling on people right now is that there have been a few cases where moderating wasn't handled in the best way, and it got talked about. Which is probably why vern wants to iron out any kinks in the current way moderation is handled in the next feedback thread. Personally, I think that most of the current issues have to do with more impulsive decisions on matters that certainly deserve more thought to be put into them before taking action. Also there's issues with indecisiveness, but those don't really leave as much an impact.


From the looks of it most of the ??-?? items are actually done, but I noticed bugs that I hadn't actively fixed on my linux FF that aren't appearing on a windows FF. In other cases something else I've fixed elsewhere has probably caused some bugs to go away in other areas. Likely there are only 3 technical bugs left to cover when I get back to my desktop.

The next chunk of issues are features that were requested. All should be doable without a full dev server, but if anything 2 will be harder to do.


1) Thread updater
5) Handle public bans
/f/ needs styles
3) Mod edits or raw HTML posts should be given a tag for html injection

4) A cookie should be used to transition between UI types
2) Posts should have a pop out triangle for deletes, reports and hiding(allows for removal of post-tools)


Completed all feature additions before day is done.. I guess I'll spend the rest of my time trying to figure out how to set up NGINX on Win10 so I can touch every item before xmas. Still can't upload because the stylesheets are different between my laptop and my desktop.


File:b8ae87b82a.png (379.9 KB,1404x803)

Style modifications will start after


Indent looking a bit better in that screenshot


that's all the indent i have


set up lubuntu boot on old laptop so should be able to do go over some of the items I had to skip. Specifically ones involving responses to posting.


looking like at current rate all items will be done on the 18th-19th except merges and checking over unreplicatable bugs.

Will spend some time to fix some issues on /trans/ and maybe see about a thread watcher, hover over images and tabbed options feature if there's time.


File:EoYNturVEAEOn5x.jpg (386.01 KB,1597x2048)

Petition to allow the file extension .JFIF so I don't have to rename my files every time I want to upload something I've downloaded from Twitter.


File:EpLi8gwU8AI2uAL.jpg (227.79 KB,1184x2000)

I'm not sure what you mean. They serve them as .jpg


File:JFIFs.mp4 (6.96 MB,1520x780)


I enabled them. I know of the format, but my win10 FF just renames it to jpeg anyways


stop saving twitter images the wrong way. you're not saving the original image


Last major addition:
11) Submitting a post should have a progress bar
From the looks of it the bulk of the work will be done on the 17th. What's left is stylesheets and layout.

There's some issues with /trans/ I need to sort out after that, but this shouldn't take more than a day


filtering and remaking the list since the majority of items are covered:
) Technical issues and bugs
1) N Replies Omitted not updating on return
2) Progress Bar not working on upload
4) Search for cite-chain errors
5) Truncation cause unicode errors
6) /f/ New File
Add Hide post to dropdown
Untestable at this time
??A) Poll colors different in index and thread??
??B) Hover preview bugs up on navigation??
??C) Performance on comment generation??
??D) Page numbers show in threads on mobile??
??E) Poll submit colors bugged??
??F) QR textarea shouldn't have lineheight??
??G) Fix truncation leaving tags unfinished??
H) Changing summary notices can spam when changed to a more permissive level
I) Own post notifications sometimes flood

)Feature Additions
1) Thread watcher
2) Image hover

)Stylistic modifications
1) Post controls should close on item click
3) Post preview on luna requires border roundings
4) Generally speaking, improve catalog(imagesize and scrollability scrolling).
5) General layout and style of sidebar should be improved.
6) Server should have alternative methods to serve depending on UI
Unmodifiable at this time
A) Shadows on QR items
B) Post highlights have too much color/gradient
??C) Cite hover preview position should target the cite like backlinks, not the post??
D) Post controls needs style

) Merge Tasks
1) Modify NGINX config
2) Upload to kissu on /b/, /poll/, /f/ and /ec/
3) set up UI alternation


Goal of the 17th: Bugs 1-6, Stylemods 1-3, start Feature2
Goal of the 18th: Feature 1-2
19th-25th: /trans/ bug, catalog layout, sidebar layout

25th-31st: Merge Work with other version, Finish off untestable issues, remaining bugs, split UI using nginx cookie, create different post procedures depending on UI used.
1st: Upload to /b/, /f/, /poll/, /ec/, /trans/, /test/


File:Untitled.png (11.37 KB,1271x66)

dunno if it's the "5) Truncation cause unicode errors" bug but that thread has a broken title https://kissu.moe/poll/res/1041

the other titles on poll seem to work fine though aside from the first character being truncated

hopefully never


Vichan has a big issue which sort of required me to do a hacky quick fix. This has been around for a long while. I think I'll get to this on the 25th+


)Feature Additions
1) Thread watcher
2) Image hover

I'm a day ahead of schedule so some people were asking about threadwatchers. I'll see about adding one to the Recent-Post feed. Also allow image-hover to be turned on from options

What I write here is about the 2.0UI


Not sure a thread watcher is all that important now, I rarely ever check my 4chan-x one, and usually it's just to clean it up.


I think it's more useful to people who post once or twice a day


Ah true, I guess that may be helpful to them.


File:image.jpeg (7.6 KB,225x102)

what's this?


If you donate I email you a way to get past autobans and captcha.


Did externals of threadwatcher.
Everything technical(well, I guess except the rich text but that can be for later) I've wanted to do will be done after that leaving more design considerations and changes.


huh when did hiro buy kissu


The trade-off of the "imageboards require no money" idea will be that whenever there's some sort of emergency that requires full attention(such a situation has come up where I needed to get 3 hours of sleep a day) the site will never get it.


File:17e3afbb71.png (106.68 KB,1239x746)

With this feature done this new UI does everything I could want it to. Mind you there is still one feature that's only partially working, but I'm not overly enthusiastic about it.
it's only bugs and style to deal with.. and the alternation between themes, but that can wait until I'm back.. I'll do an unstable upload to beta of it's current state and fix some issues with kissu-vichan.

Until the 26th I'm going to fix issues with /trans/ and easy to solve problems on beta.kissu
Color and layout


I'll edit this post over time to list the style changes and bugs that need to be covered after the 26th. Currently I'm going to fix things on vichan.

- Poll expansion color
- Watcher Icon to leftmost
- Modify QR close behaviour
- close mobile threadwatcher on nav
- Ban bugs
- trans data
- unspoiler threads
- automatic backup system


everything on kissu seems functionally complete, but stylistically poor and potentially buggy.

There's actually some more functions that I'd like to add, but there are other priorities to deal with


Can we please enact a complete ban on all vtuber content?


You're free to say you don't like something, but hating something isn't culture. I can't reasonably reject an aspect of culture for a reason of hating it.


I'm not suggesting it be banned because I don't like it, I suggest banning that garbage because it's not /jp/ content. Those are vloggers and let's players/streamers, having a shitty 2D avatar doesn't change that. I don't want talentless whores and their inane drama here.


The first thread about it on /jp/ is a copypasta. This is jp content
The first thread on /ec/ is an imagedump. This is ec content
The most recent discussion on /qa/ is about 4jp. This is /qa/ content.

I don't see anything that's outside the realm of board content on given boards


Timetable of final UI modifications to be roughly followed. Style mods may take a while, but resolving bugs and adding transition between vichan and k-fr is a trivial task

) Entry Point(27th)
1)Overwrite versions of UI and API on dev Server
2) Merge SSR Server and Stylesheets on dev server

)Bugs and Technical Issues(28th)
1) Poll colors different in index and thread(try submit)
2) Hover preview bugs up on navigation
4) Cite hover preview position should target the cite like backlinks, not the post
5) Page numbers show in threads on mobile
6) Poll submit colors bugged
7) QR textarea shouldn't have lineheight
8) Fix truncation leaving tags unfinished
9) Changing summary notices can spam when changed to a more permissive level
10) Own post notifications sometimes flood
3) Verify cached pages are being used
Mobile nav bar tabs
mobile nav bar list style
previews are clipped by page start/end
Hidden boards do not build threads on SSR

) Feature Additions(29th)
1) Server should have alternative methods to serve depending on UI
2) Set up UI alternation
3) Fail and server-crash page needs UI alternation
4) Cookie bans

)Stylistsic Modifications(30th-1st)
1) Generally speaking, improve catalog(imagesize and scrollability scrolling).
2) General layout and style of sidebar should be improved.
3) Shadows on QR items
4) Post highlights have too much color/gradient
5) Post controls needs style

) Merge Tasks(2nd)
1) Modify NGINX config
2) Upload to kissu on /b/, /poll/, /f/ and /ec/

) Other
resolve good practice errors
Page jump positions on navigation
Remember options
submit/progress from options field
option menu tabbing


How did yesterday's spammer get around the filter?


which filter... mobile phone if you mean bans


The one that stops you from repeatedly posting the same pic or the same text.


idk, other people dealt with it while I was sleeping.
The duplicate checks aren't on and typing the same thing is just a captcha.


whitelist item added


Might be able to revise the sidebar and catalog today, but unlikely. I think the catalog needs more mind into it that I have today. Revisions should go live on the four listed boards on the 3rd, then catch more bugs and design issues for a second revision.

There's also a big bug in communication between vichan and golang that causes a thread not to build which needs to be fixed. It's rare but experience breaking, likely because the server runs out of memory making this a hard thing to fix...


Last items

- Bug on overboard vs boards
- Custom CSS Storage bug
- Previews being effected by catalog.css
- mobilenav bug(.numbers)
- mobile preview issue
- hover box on non-existent items errors
- catalog focus wider and offset to left:10px
- Home previews multiple scrollbars appearing
- outline:none; on threads
- TypeError: Cannot create property 'mobile' on string 'Thread Props 404 - json 404 - returnReactAsStringObj err - Build Composite err - TemplaterBridge err - thread err on /jp/thread/12037' - TemplaterBridge err - thread double err on /jp/thread/12037
- deleted no box
- delete shouldn't delete delete?
- dependancy updates
- Configure legacy-new UI toggling
- Update config JSON files
- Upload v2.0 for more evaluation


json api no longer working


This will be added with a list of issues to solve.

Bugs and Technical Issues
01- Clarify and fix errors when cookies don't match up with UI type
02- image previews/post previews on site navigation
03- Navigating from home into thread shouldn't keep hover open
04- options and name field not clearing on empty post submit
06- Options position
07- Post chain settings not being set, don't remove jump feature
21- Thread titles not matching between navigation and server requests
13- don't tab into filname input when no file active
14- Dragging text inside of the QR
20- Sidebar closed menu with catalog closed
18- Remove highlight in catalog, reduce OP highlights
12- Some issues with hiding threads from controls dropdown
19- sidebarscroll issue https://kissu.moe/b/src/1609876834182.png
17- shared passwords between UI
15- Flash file url oddities
11- progress bar that won't vanish
16- Markup issue on https://kissu.moe/b/thread/5941#b-6049
22-Index activity counter doesn't work after manual rebuild
10- Threads that do not make it to build(very hard to replicate this) [logging set up]

Style Modifications
01- Submit button focus borders(and etc, remove globally)
02- Multipost submit bar not vanishing
03- Don't trigger hover on spoiled images
04- image frame styles ( .op .img 1px solid #ffffff1c etc.)...
05- Post chain box dimensions
06- mobile text wrap bs
07- .com and mod-com lineheigth default
08- zip thumbnail too small
09- style select z-index
10- more sidebar modifications(https://puu.sh/H4LXK/8314ac36c2.png and https://kissu.moe/b/src/1610006132332.png)
11- Relocate banners and create meta info in the main column
12- improve feel of Kissu.css and CSS for sidebar alterations
16 -4chanX like notifications

13- add update thread to sidebar closed menu
14- Add some basic CSS rules in <HEAD> such as thread <LI> or <UL> in threads shouldn't have text decorations(new sheet, basics(x.y.z).css
15- Mobile mode requires options

New Features
Remaining bugs
01- scrollable QR preview when in thread, but read more in index
07- Hide backlinks from hidden boards
03- Add 4chanX compatibility with threadwatcher(feature to be discarded without 4cx-API improvments)
04- Finish rich text
Markup bugs
05- Similar to Feature
06- Drag to enlarge frames



roughly 41 issues this time. Hopefully one week. I'll break them into chunks and sections later


File:Screenshot_2021-01-07 qa ….png (147.9 KB,1705x329)

I think for the preservation of niceities and aesthetics you can keep home, return, top, and bottom. leave update where it is and it'd look nice while retaining anything useful towards thread/site navigation. i think you can keep toggle-ui and options where they are alongside css options, but just left-align them so that they fit in with the improved boards list and other sites list above them

i'm still convinced that keeping a header on every page like pic related would be the best choice aesthetically and technically. as it'd look nice and also retain some familiarity for users. since even if you may say the sidebar makes it redundant (even though there's no better place for wide banners) keeping some basic design intact for new users would be good so that they're not too confused when coming to kissu


save for reply, that might be better.
Putting the header in the sidebar is more trouble than worth


Much less technical issues, a few less style mods, more features to add

work timeline will probably be 10-11 days.
All of the issues are more complicated than before because we're getting into finalization issues rather than basic problems. Might take a few days longer depending on how the workflow goes


updated to 2.1.0 resolving all current bugs except for one that will take a bit longer to verify if it's fixed


Updated to 2.3.1 which covers every style modification requested.

Most noticeably is the effects of closing the sidebar and what's placed in the sidebar


need to fix mobile [return]
make OP highlighting much more subtle.
Margin-bottom of thread/reply create needs non zero numbers.
4chanX header needs bg on kissu.css.
Reply shouldn't target OP.
4chanX messing with notice style
article mode backing
post made notification
QR preview height
QR spoiler cycling


Update to resolve above issues, fix QR Preview issues and modify cross board backlinks to exclude hidden boards(unless you are on the hidden board).

Note few more:
- OP highlighting more down(to blend better)
- Hiding posts from index not working
- Try and resolve filenames falling off threads
- Fix forbidden string
- Toggle UI on mobile
- remove H1 background on mobile

Tomorow is finishing the rich text feature


Lots of markup issues to fix, still a bit of richtext bugs but getting there.
After that add the similar-threads feature which will hopefully act to give more attention to old threads and reduce the reliance on thread layouts for navigation.
Finally see about some 4chanx things and then release V3.0 which will become primary, but still accept feedback on revisions and a much lower priority V4.0 if new features exist

New Features
Remaining bugs
01- scrollable QR preview when in thread, but read more in index
07- Hide backlinks from hidden boards
03- Add 4chanX compatibility with threadwatcher(feature to be discarded without 4cx-API improvments)
04- Finish rich text
Markup bugs([br/] tag, https://imgur.com/uNen852, https://imgur.com/5jwQoY1, https://imgur.com/DX8ZyJz, https://imgur.com/gUue2y2)
05- Similar to Feature
06- Drag to enlarge frames

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

[ home / bans / all ] [ win ] [ qa / jp / cry ] [ f / ec ] [ b / poll ] [ tv / bann ] [ fr / tab2 ]