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 m
- R: 601
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 an
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 f
>- 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 subnet
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.
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 me
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.
https://pdfs.semanticscholar.org/c89f/030b95247e3316385db3fd8765c5737a8867.pdf looks modern enough
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 dum
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.
just storing some info I want to read
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
[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]
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
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
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.
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.
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$.
Generally Blowfish crypt is recommended over sha512
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 glob
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
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
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
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 t
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:
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 >>4591
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 "corrupt
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
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
does this actually work?
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.
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.
nice query I'll put into vichan eventually
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
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
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 3
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
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
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 so
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
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.
-The letter buttons at the bottom for text stying is really useful
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.
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.
>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
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?
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.
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.
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.
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
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
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.
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
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
>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 post
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 l
>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.
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.
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 discussi
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.
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
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 discourage
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?
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.
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.
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.
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!
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.
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.
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.