> Put the Entire thread link on the top of the thread, not the bottom.

Well, since the current update has removed almost all links to entire threads, I won't do THAT, but I guess a Last 50 link could be snuck in somewhere... Maybe the thread title should be an l50 link?

Argh, beaten and >>n isn't even implemented. orz

>>323-324
The 2channel moderation request forms that are mods of 0ch use 強制リモホ, which is Forced_Remote_Host, more or less. And it makes sense, there.

Forced_IP is only enabled on the "Siberia super-news flash" board: http://etc3.2ch.net/siberia/

And I have no idea what that board is about...

Semantical nitpick: shouldn't the "Page top" link be called "Thread list"?

I think it'd be a better idea to have some kind of load-balancing/distributed server cluster approach, like what dmpk2k was working on for Wakaba.

> Frankly, the combinations of many things into unrelated fields is a design flaw.

I don't think so, not in these cases. What's the alternative? Having a different field for fusianasan, a new checkbox for sage, etc.? That's just cluttering up the interface.

> What if you want to use a name/trip and fusianasan?

Then just make one post with your name/trip and one with fusianasan and let your ID show up in both.
fusiansan is just intended for rare or special cases anyway, as is the whole subject of identification on anonymous message boards.

> What if your email address contains the string 'sage'?

Huh?

> What if you want to sage a thread, but have an ID still?

Then the board has to be configurated to just do that (it already can).

> why should I have to remember something so foreign?

It's rarely needed anyway. Also, these things are pretty easy to remember. "sage" and "fusianasan" is all there is, really.

Hmm, looks like my ISP fails at keeping my IP secret.

> I'd like to have the interface reduced to what is absolutely neccessary

That's why there is a "More options..." link, instead of putting the controls there on every single thread everywhere.

>>20
"|" is not "¦"

>>69
The sage seems a bit off...

And my post ist a good example for chosing the wrong markup :/

> partition to kill secure tripcodes

signed

> add functionality for multiple uploads in one post.

I think this was decided against before.

Oops, here's the screenshot. orz

Recapping, here are the things I'd like to see in the final release:

• better configuration of date and time (with optional timezone offsets), parsing certain characters for individual elements (ie, yyyy/MM/dd(D) hh:mm:ss -5:00:00) and also accepting numerical inputs for fixed dates and times (Eternal September)
• config.pl parameter to permasage after a certain thread filesize/total number of characters has been reached
• change the no-ID-on-email option to no-ID-on-sage
• no EMAIL_ID parameter (most if not everyone uses "Heaven" anyway, and if they really want to change it they can easily find the string in kareha.pl)

Some nitpicky template adjustments to mode_message in order to more closely resemble 0ch (see http://f17.aaa.livedoor.jp/~zerotest/jikken and http://0ch.mine.nu/jikken):

• multi-page links (1-, 101-, 201-, etc) at the top of subpages
• red, bold thread filesize indicator near the bottom of subpages
• "read all later posts" link just below the filesize indicator
• non-bolded post numbers
• colons before dates
• colons before names (thread subpages only)
• colons after thread position number in main page thread list
• smaller and (at least for Pseud0ch) black and bolded title in "Create new thread" box

>>336
IMO minimalist web applications like Kareha should only focus on core content/functionality and leave the inconsequential presentation options up to browser extensions so that each user can tweak them to his whim. That's why I was pushing to offload the CSS selector to an extension.

>>337
Here's a better example, I think. Even if we can't remove the excessive side borders, is there a way to at least have rounded corners?

On formatting options: I think >>338 fails to understand that leaving the formatting options up to each individual user is a good thing by all means. Besides, they are absolutely necessary to the interface and core functionality, just like the Name and URL fields are. Preview functionality, on the other hand, should be implemented in an extension.

I think the issue that people have with the formatting options is that we don't have a Japanese counterpart to blindly model it after. Since we're going at this on our own, nobody is quite sure how it should be done. I'd like to see how it turns out on mode_image (if you feel the need to include it at all). :)

Getting back to inconsequential nitpicking: I find the "___ image replies omitted" phrase to be a bit redundant, and for one it confuses me as to whether or not those image replies are separate from text-only replies. How about simply calling it "images"?

> You still end up with no way to link the fusianasan post with the name/trip one without IDs enabled (unless the ID method is known and no secret data is used).

You'd figure that people who know what fusianasan is will also know how to trigger IDs.

> You spelled it fusiansan once.

So I misspelled one word once.

Sue me!

> Also, how is Kahera unrivaled when there are still large sites that are not running it? Shiichan is still on world4ch, Thorn on parts of wakachan for example.

Neither world4ch nor Pichan are by any means "large". Also, yes, as Shii said, their webmasters are stubborn.

>>189

>The effect would be miniscule in comparison to the huge increase in bandwidth that would result from sending the entire static thread pages.

How about a config.pl parameter to split up thread subpages into X posts per page? The navigation links already use 100 posts per page for practically everything except "Last 50 posts".

Hmm, I just remembered: >> links would not work at all with static pages. Not good.

>Why? Even if 0ch or Futaba implemented secure tripcodes, you wouldn't get the same secure tripcode there as on another board. That's the nature of the security.

Right, I guess it was dumb to mention 0ch/Futaba in the first place. The point is, as you said yourself, tripcodes are a gimmick, and if someone wants to maintain a persistent identity across multiple boards and sites (ie, everyone here with a tripcode), they have no choice but to use ordinary tripcodes. Secure tripcodes are useless because they limit your identity to a single board, supposing each board/site's cipher key is different -- which it should be, since that's the point of having a secure tripcode in the first place. No one should be so paranoid about a tripcode that they'd need to have a different one per board/site.

>Not without doing a lot of changes throughout the code, and not without breaking current installations.

Shouldn't we sacrifice some backwards compatibility for a more robust and scalable design? It might even be possible to provide an upgrade.pl for old threads.

>>193

>You could only trigger the functions in a specific format, say...

That's a cool idea, though for now it would have to be left alone if we want to keep Kareha compatible with 2ch/Futaba conventions.

>>195
Exactly. The methods and the effects of saging a thread are separate subjects.

P.S. I recently discovered "rXX-XX" for threads in /soc/. How exactly does this work? From the sound of it, it's supposed to randomize the post order, but when I hit refresh I get the same order.

>>251

Again, the list of tags allowed on that page don't correspond to what would be allowed in Kareha. Of course <img> tags wouldn't be allowed, for instance. This is just for testing the actual cleanup engine.

http://wakaba.c3.cx/sup/kareha.pl/1114201493/l50

Or use some sort of filter to replace them characters with underscores on upload.
This offcourse for files that keep their original filename.

>>70

?

> Personally, I find the reverse order listing, as well as the random order listing, to be a bit silly & useless.

Well, no, duh, that's the point. They're jokes.

> The only useful bonus feature here seems to be the comma range seperator, but it seems even in that case there is not much benefit to it (saves 1-3 links in the average case that it is needed, which is rare to begin with).

On the contrary, it's very useful when referring someone to a specific discussion in a thread where several discussions are going on, since you can make a link that only shows the relevant posts. Not just on the board but when linking to threads elsewhere.

I don't see any inconsistencies in >>341 except for the rounded corners.

>>177

> It's not worth comparing until it doesn't break regularly.

The only problem with it is that it doesn't do paranoid file writes. The fact that the entire server occasionally breaks isn't related to how broken the script itself is.

Also, I forgot to mention: fusianasan works now! Put it in as your name to test it!

I don't see what's so bad about >>330. The alternative is to force the table to be full width, which will make it uglier (because in HTML all columns will become wider, including the skinniest ones), and harder to read.

> No need for a database, just a text file. You're right about storing IPs, though, but then how can you implement a banning system? Do you use an encrypted IP like the algorithm to generate ID codes?

Banning is done through Apache, which really makes more sense than doing it in the script. I don't want to re-invent the wheel for that.

> I mean that (for example) if I wanted to replace the permasaging function under the MAX_POSTS condition (permasage after X posts) with the thread-closing function (close after X posts), all it would require is a simple replacement of the proper function references in post_stuff(), correct?

No, they're done at different different places, because they are essentially different functions. The permasage behaviour doesn't actually permasage a thread, it only refrains from bumping it. There's no permsage flag added to the thread. The closing, on the other hand, does add a flag to the thread.

> Making "More options..." an option in the configs.
> Seems sensible, when you already have the ability to turn off WakabaMark as a board admin.

No. And I actually removed the DISABLE_WAKABAMARK option since it's no longer really needed. The replacement will be an option to select the default markup for a board, which makes much more sense overall.

>>321
Wait, why should l50 links be indexed/cached? IMO the only links that should be on Google at all are main pages and "entire thread" links.

Some final points (I hope) before the whole thing is wrapped up:

• The CSS in the All threads page is unsightly. Is there a way to properly wrap the outer color border(s) around the table of threads?

• I still say that the "Navigation: " text is extraneous when people can clearly see what the links do. Also still partitioning for 0ch-style error pages (with displayed user host and all).

• Now that we do have filesize indicators in the backlog page of mode_message, do you still find it useless to have the red bold filesizes near the bottom of thread subpages?

• Does mode_message now work in PAGE_GENERATION => 'paged'?

• Idea: forced anonymous/sage/ID/fusianasan by IP/thread/board/whole site (some of these combinations already exist, I know)?

• Finally, I imagine that the permasage/close/delete functions in kareha.pl will be easily interchangeable among the conditions in post_stuff(). Can you confirm this?

> They can modify it an claim copyright on their modifications, at least as long as they're significant enough, but that doesn't affect existing works in the public domain.

Devil's advocate: What if they make significant changes you would want to add yourself? before you do? Can they then tell you to stop if they license their work first?

> Did you ditch customizable capcodes?

No, I removed the dumbass capcode I put in as a demonstration, because I don't like capcodes.

> Using "◆" as the default tripkey character.

I dunno, I always thought that was a kind of big and annoying symbol. Especially when it's so close visually to the question-mark-in-diamond marker some fonts use for characters they don't support.

> How about placing the Formatting menu to the left or right of the "File: " field? I'd also like to see WakabaMark changed to its real name (Markdown).

The File field is almost never there. Also, WakabaMark is similar to, but not the same as Markdown. There are significant differences that make them incompatible (since Markdown is designed to be used when you know you're using it, but WakabaMark tries as best as it can to not do unexpected things if you don't know about it). I might add optional support for real Markdown at some point.

> In Pseud0ch, post numbers should be the same size/format as the rest of the header text

I tried, and it looked much worse than the current solution. Besides, post numbers in Kareha and 0ch aren't the same, since they're clickable here.

> PS. What's "Raw HTML"?

Pretty useless. I'll probably remove it. It's HTML input without turning newlines into <br/>.

> Oh, and "AA mode" should be changed to "Text art mode"

Maybe just "Text art"... hmm.

I've been meaning to change some of the defaults away from Futaba-style to saner behaviours. Any suggestions for what to change are welcome. So far:

• Pruning set to furthest-back instead of oldest.
• Size limit instead of post number limit, maybe?
• I'll add thread closing to Kareha, but I was thinking of setting the default behaviour to never permasage or close threads.