>>66-67

Noted and fixed in development version.

Thanks for the links at the top. Previously, I had to search for those threads over and over again if I wanted to find them.

Oh, and the navigation bar on the error page should probably look like the one on the thread page.

>>236

mode_image copies the Futaba/Futallaby HTML style and uses the same CSS, so yeah, it should be, and no, it won't be.

>>238

This would need writing to yet another file, and it also makes it less obvious how to get the same secret on several boards.

...and admin posts that override all board/thread restrictions (ie, bumping a permasaged thread and possibly even posting in closed threads).

> statically linked executable

I have to disagree with this. It should run in perl too.

• If you're running wakaba, obviously perl must be there
• Most hosts that library-poor don't provide compilers (or shell) either

I meant Remote host adress instead of IP.

durr hurr

>>18
Firefox 1.0.7, WindowsXP Pro.

Forgot this one:
The general functions of imageboards do not seem to be clear to most people that eventually come around, the influx of total newbies is still big. Many neither know what sage is, how to properly reply to threads, what tripcodes are, etc.
Because of that, I believe it would be good to include a default link at the bottom of the unordered list at the bottom of the new thread form that links to http://wakaba.c3.cx/docs/docs.html#UsersGuide

Relevant:
http://dis.iichan.net/idc/kareha.pl/1128824710/12-

>>48-50
First of all, I don't believe it would make bumps more valuable in any way. People bump threads all the time with worthless replies since most don't even know what "sage" is or means or what it is good for. They will simply continue to do this, no matter whether the sage function is changed in this way.

Even at this stage, years after its introduction to a major western userbase, people are still clueless about the main basic functions of image- and discussionboards in the Futaba/0ch style. There are some signs of improvement, but they are rare.
I doubt people would be willing or eager to learn a new, different behaviour at this point in time.

The only real change is what >>50 points out (though I want to mention that even that point is mostly misunderstood: if people want to protest against a certain thread, they should post as many sage posts as it needs to get permasaged (although it's arguably counterproductive, considering the default prune behaviour of imgboards). If threads are still bumpable and trolls find that they have been flamed with a sage, they will just bump it once more). And I don't think that's enough to justify a pretty major function change.

You could add entire thread links to either the "num" or "posts" column in subback.

Additionally, I'd like WakabaMark to be fixed somehow.
I don't know how, though. You know my resentments.

Finally, thanks for your fine work throughout all this time.
It is appreciated!

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

>>182
That's not what I meant. What I meant was: If people want to change keywords to something, let them figure out at appropriate places what this something should be. Whether it should be "down", "stay_down" or "stay_put" is not really a discussion belongs here, not at this point anyway.

>>123
signed

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

>>174

>Let people figure out things themselves, if they are so keen on changing their keywords.

If you really want to use your own custom trigger strings, you can easily search kareha.pl for instances where "sage" and "fusianasan" are used in that context and either replace them with those custom strings or append them as secondary strings. It's not something that warrants additional config.pl parameters.

> forced fusianasan

that seems kind of evil.

This is the obligatory encoding test ... in <code>

 ㋋㏡
 ゔ〲〰 ゔ〲〲〰〰 ゔ〲〰 ゔ〲〰 ゔ〲〰ゔ 〲〰ゔ 〲〰ゔ〲〲〰ゔゔ
〳〵ヷヷヷヷ〰〰〰〳〵ヷヷヷヷ〰〰〰〳〵ヷヷヷヷ〰〰〰
(♛ฺД)(*゜∀゜)～♡ℳฺℴฺℯฺ❤ℒฺℴฺνℯฺ..._〆(゜▽゜*)㌰㌰ ㍉㍍㌧㌔㌶㍊㌣㌦
㌀㌁㌂㌃㌄㌅㌆㌇㌈㌉㌊㌋㌌☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ
☼♭♬♫♨♩♧♦♥♤♣♢♠♡♐ฺ♑ฺ♒ฺ♓ฺ ♔ฺ♕ฺ ♖

ฺ ♗ฺ♘ฺ♙ฺ♚ฺ♛ฺ♜ฺ♝(･∀･)/ヾ~~╋┓!㋦㋸㋭°

|壁|」゜ρ゜)」　ノ ヽ``～ 力㋦㋸㋭°
 　 　 ／ ⌒ヽ  
　 　/　´_ゝ`） I am sorry、 the β α κ α kopipe couldn't be carried out・・・
　　|　  　　/
 　　| /| 　|
　 //　|  |
　Ｕ 　 .Ｕ  

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

/-100 shows the first post two times.

>>191

Thanks for reminding me that I need to fix the CSS for the captcha!

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

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

　　　∧∧
　　（　 ･ω･） 　 　It's late
　 ＿|　⊃／(＿＿_
／　└-(＿＿＿_／

　　　∧∧
　　（ ･ω･ ） 　 　Good night!
　 ＿|　⊃／(＿＿_
／　└-(＿＿＿_／

　 ＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／
￣￣