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 192.168.1.0-192.168.1.223 it will make the decision that the 192.168.1.0/24 subnet is unusable due to spam and automaticly issue a ban. Naturally this will cascade upwards to 192.168.0.0/16 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.
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
- B: /b/R: 737
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.
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.
- 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.
- 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
- 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.
- Posts can be expanded inline meaning text walls do not dominate threads
- Custom insertion of style tags. Typing text 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
- 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 text 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 text 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.
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
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
>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…
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
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
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.
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.
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.
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
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.
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
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
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…
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
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.
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.
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.
[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’?
../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]
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 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.
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.
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.
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.
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
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
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.
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
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$.
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
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> Crenyaxiam Syroboh
<Anonymous> Suexothok Bumiyatis
<Anonymous> Leebraneer Naisemaac
<Anonymous> Kaesiadreg Thaxagair
<Anonymous> Jedybil Tredeemeer
<Anonymous> Tribouwot Queshescoc
<Anonymous> Guquiesiez Theojouslyg
<Anonymous> Ledeaphah Reescotryc
<Anonymous> Neasaispe Roofutiam
<Anonymous> Scheleebral Traclesheen
<Anonymous> Chireechal Woseymon
<Anonymous> Raeglalex Bratenyz
<Anonymous> Thinieseex Lyawrevun
<Anonymous> Pyletiec Frehacek
<Anonymous> Radrezer Nyoleystim
<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
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
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']
some sample names:
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
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.
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.
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."
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.
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.
>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:
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.
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.
>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'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.
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
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.
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.
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
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.
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.
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.
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
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.
127.0.0.1 - - [07/Oct/2020:02:30:18 +0000] "GET /api/properties/error.json HTTP/1.1" 200 531 "-" "-"
127.0.0.1 - - [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
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.
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
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
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.
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.
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.
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
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.
Interesting edge case: >>>/qa/56354(OP) 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).
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.
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.
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.
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.
made a tomorrow theme for kissu, although it feels incomplete and i lack motivation for learning more CSS
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.
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.
-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.
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
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