> 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.

True, they're of limited usefulness, but people like admins might prefer to use them. And there are certain cases were you might use them temporarily for various purposes. I wrote the code already, so I might as well leave it in. It has some uses at least.

> 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.

I think I'm too lazy to do it. It's kind of hairy. Besides, as I said, you can remove a lot of the drawbacks of seprate installations by using symlinks.

>>209

>> More information on the all threads page, date of the last post? file size?

Well, I had already proposed the filesize indicator in >>208, but optimally I would actually prefer that subback resemble the one in 0ch (ie, same as the main page thread list, but without CSS).

And single-post links don't include the thread's first post anyway, so there's no need for >>n. Quoting an entire post is not wise either.

>>211

>Isn't this essentially the same as saying "Please don't talk so much?"

In a sense, yes. Just like the postcount limit could be interpreted as "Please don't talk so long".

>what

main page -- 161 Name：◆WAHa.06x36：2005/10/21(Fri) 14:44 ID:Heaven
subpage -- 4 ：◆WAHa.06x36：2005/10/21 14:44 ID:Heaven

Question: does Kareha have a 1001th post message like "Name: 1001:Over 1000 Thread" for when a thread exceeds its postcount limit?

>>123

Noted. I've been struggling with that same problem for naming things internally in the code, and obviously it distracted me from noticing the same problem in the GUI.

GDLib for thumbnails: http://wakaba.c3.cx/sup/kareha.pl/1113869490/5

>>244

Er, that's a feature, not a bug. That's how most GUIs act.

>>249
<a href> opens up the possibility of using inline links, and img tags allow bandwidth leeching from other sites (plus the fact that the image itself may be unsanitary).

>>360
Doesn't mean we can't have separate releases for special scripts. :)

That would be a bother too.

Wakaba:

• Better handling of the code that automatically inserts the >> links for quote-replies. Right now it inserts them numerous times if you go back and forth several times before actually hitting "submit".
• Reintroduction of "Marked for deletion (old)" (it's just handy to have that)
• Prune-limit mode that is defined by number of files or size sum of files on a board

> You mean requiring SQL software, or just making backwards-incompatible changes that would screw up old threads?

I mean, needing to alter the table that is already in the database. I don't want to try to do that any more than I have to, as it's pretty hard to get right in a database-independent manner.

> Are you only referring to flooding and spamming, or also trolls and flamewars?

Yes, only flooding and spamming. Trolling and flamewars are not a problem one should use banning to try and solve.

> Finally, out of curiosity: how much of the functionality in the .js file do you think could be properly implemented into a new or existing perl script?

Well, if you serve up dynamic pages, you can do the form-filling on the server, but that's about it. The rest is dynamic stuff.

Let's get to 1000 by "I want a pretty pony" only! ヽ(´ー｀)ノ

>>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...

WAHa, WAHa, it's a bug!

Pressed back after creating an error message in karaha (trying to reply to this thread, forgetting to type something in here), refresh does nothing!

>>> In the end, people actually enjoy the 0ch quirkiness. I know I do. I know about designing good interfaces, but there's something fun about an interface that is a little bit quirky, as long as it doesn't get in your way, and these things don't.

It does get in your way though, I enumerated cases where this is the case (albeit edge cases).

>>>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.

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).

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

You spelled it fusiansan once.

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.

http://wakaba.c3.cx/sup/kareha.pl/1127713568/l50 is also semi-relevant

How about listing what dmpk2k or you have done already?

1. Split threads and posts into separate tables. You're repeating the lasthit and parent column over and over.

I vote yes, but that is obvious isn't it?

Oh okay.

I agree, for Kareha at least.

> More information on the all threads page [...] file size?

If (optional) closing on filesize should be implemented, this would probably be a good idea.

>>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.

style:none plz!

> Another topic: since dynamic pages eat up CPU in order to rebuild pages according to URL parameters, what would be the likelihood of the current dynamic thread subpages having a significantly adverse effect in this aspect if a board were to grow to 2ch-sized proportions?

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

The "entire thread" link can easily be changes to link to the files in /res/ instead of going through the script, but that would make it somewhat less convenient when you want to consturct custom URLs, so I haven't done it.

> Also, let's put out a partition to kill secure tripcodes (unless they originated from 0ch/Futaba)

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.

> captcha (until we find a way to implement similar functionality without requiring it in the form of a GIF/PNG image)

That's even more non-sensical. Nobody on the entire internet has figured out a reasonable way to implement captcha except by using images, and the only boards that use them are image boards where you have to load images anyway. And finally, they aren't just there to annoy you, people do actually try to flood boards, and they are stopped by the captcha.

> And is there any practical way that Kareha can be modified to run multiple (even nested) boards in a single installation?

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

>> config.pl parameter to permasage after a certain thread filesize/total number of characters has been reached

> Isn't this essentially the same as saying "Please don't talk so much?"

I am not >>208 but the first who suggested this here (long ago). I think it may be vital for future, actually popular boards to limit the filesize of a thread so that the board won't get hammered by repeated loads of whole threads without having to limit the size of posts themselves something fierce.

The "Entire thread" link in the top navigation bar of the thread page is still broken.

All right, code updated again. This time, some experimenting! I've implemented a tentative system for changing markup types. This needs a bunch of testing, of course, so here's the test thread link once again: http://wakaba.c3.cx/sup/kareha.pl/1099697376/

Thoughts and comments are welcome. I'm still trying to figure out how exactly to do this.

There's a bunch of other changes and fixes too, so mention if anything breaks, as usual. Also, shift-reload!

> change the no-ID-on-email option to no-ID-on-sage
> multi-page links (1-, 101-, 201-, etc) at the top of subpages

Already implemented.

> config.pl parameter to permasage after a certain thread filesize/total number of characters has been reached

Isn't this essentially the same as saying "Please don't talk so much?"

> 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)

The choice of this string is so weird and arbitary, I feel better keeping it as an option so that I can disclaim responsibility!

> 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)
> red, bold thread filesize indicator near the bottom of subpages

Pretty useless. I'd rather not waste work and code on something that has no actual use. (Timezone offsets would be useful, but this is such an incredibly hairy issue to get right, I don't want to even try. Just handling Daylight Savings Time would make my head explode, and I can't just leave it out, because then either the admin has to keep changing the offset, or the time will be wrong half the year anyway.)

> non-bolded post numbers
> colons before dates
> colons before names (thread subpages only)

what

style:none plz!

>>123

Noted. I've been struggling with that same problem for naming things internally in the code, and obviously it distracted me from noticing the same problem in the GUI.

>>32

Your browser momentarily regressed to an old bug and then got better? Who can tell?

>>22

Running in pure perl would be ideal, portability-wise, but in practice implementing a JPEG loader and saver from scratch in Perl is both a lot more work than anyone wants to do, and the result will also be too slow.

As was already stated, making a statically linked executable lets you distribute pre-compiled binaries that people can just upload along with the script.

> Would it maybe make sense to make a separate thread creation page?

Considering that the ratio of users who start new threads to those who don't is pretty small on most message boards, I think it does.
A seperate page could also be used to put a more visible disclaimer/set of rules, as a seperate page with a different layout is likely to generate more attention from the user. Stuff that can be put there also wouldn't clutter up the frontpage.
I don't think this is an urgent matter, though.