The problem reported in >>143 is still present.

>Most admins probably don't get point of the secret string anyway, and asking them to put in several is just too annoying. In retrospect, I'd like to add a second layer of hashing to these, but that'd mean breaking secure trips AGAIN.

You could take the route that MrVB (I think?) did and generate the strings on first run? openssl, /dev/random, perl's random as last resort. In almost every case you are going to get a better random string than most people will supply, and if they want to change it they can. Or only have them generated if they are not supplied.

Honestly, when people care so much about anonymity they can put up with the changes required to ensure it.

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

> 3) A specific string for ID:Heaven instead of anything in the email field

Isn't that already an option in the config?

> 5) Seperation of sage et al from the email field to something else...

Strong oppose! I am of the (strong! lol) opinion that the current situation is the one working the best and also that it is widely accepted on almost all similiar board scripts (save for Shiichan and one obscure Japanese discussion board script that I once stumbled upon).

Previous discussion of this can be found here:
http://wakaba.c3.cx/sup/kareha.pl/1102984488/

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

>>86

>Why should it?

Because it's one of the two requirements for creating a new thread, and it's a lot more important to have a well-defined topic than to fill in your name.

>It's more convenient if you want to start a new thread, but for those who don't it's one more form to have to scroll by.

Good point.

>Any idea why?

I dunno. I guess it's just another one of Futaba's countless layout quirks.

>>153

http://en.wikipedia.org/wiki/Public_Domain

It means anyone can do whatever they want with it. They can't claim copyright, though, since they didn't create it in the first place. 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.

> This is kinda what I had pushed for earlier in >>52. I think that separating the sage (aka, "don't bump"), fusianasan (aka, "show IP"), and ID:Heaven (aka, "no ID") functions from any particular post elements in the main scripts would be ideal for implementing Kareha in systems where inputting a certain string to trigger these functions is not intuitive (ie, every board outside of the 2ch/Futaba family). These trigger strings (S_DONTBUMP, S_SHOWIP, S_NOID) and their assignment to a certain form field input could be instead implemented individually in each template.

There's no obvious way to do this, since there has to be code that specifically checks a field and takes certain actions long before the template comes into play. It'd take some sort of plugin system to implement it, and I don't think that's quite called for.

Also >>154 is Kami.

Oh okay.

I agree, for Kareha at least.

>>324
I've heard they use it on a per-IP basis for troublesome posters on 2ch. It could also discourage people from being jisakujien (supposing ID is disabled) or posting in a certain thread unless they're totally willing to have their host revealed.

> 2channel does not do this either by default. It can make browsing a bit more convenient (and I suspect dedicated 2channel browsers to insert & read these in some kind of standardized way) but I don't think that's reason enough to impose it on users by default.

whoops, I misread "postcount" as "posticon". Nevermind!

>>48

That is an interesting idea, and one that deserves some more thought.

>>19

I can't reproduce this on Firefox 1.0.4 nor Safari on the Mac, but that ancient Firebird had a similar problem (but even worse).

Anyone else? Try post with a | in your name.

> 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

> It would eliminate the concept of sageing as a protest entirely.

Except that nobody knows what's going on back-end.

I like the idea though.

>>18
Firefox 1.0.7, WindowsXP Pro.

> forced fusianasan

that seems kind of evil.

>>66-67

Noted and fixed in development version.

>>110
Happened to me, too, sometimes it goes black, sometimes it goes white. Screen reappears if you just scroll up a bit but it's still strange.

>>170
But my good man, sage means down.

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

These are temporary problems because the webmasters of both sites are too stubborn to upgrade.

0ch-PHP had this nifty feature where if it was a certain "high bandwidth" time of day, then you couldn't view the whole thread.

Hm... that is kind of useless on a worldwide forum, huh?

But there should still be an option to keep people from viewing more than 100-200 posts, as an emergency way of saving bandwidth.

>>259

Fixed.

>>260-261

The test script doesn't try to handle charsets at all at the moment.

>>220
I meant only using the extra post for autoclose situations where the thread has exceeded the defined postcount limit in config.pl. As for the implementation, couldn't you just have Kareha use post_stuff() and (somehow) replace the timestamp with "Over XXXX Thread"?

I don't know if this is a bug or not, but could you change the Futaba template so that hovering over/clicking on a post header doesn't count as doing the same to the deletion checkbox next to it? Same goes for the "[File Only]" area at the bottom with its checkbox.

A 1001th post would be a bother.

>>249 Then the default should be no markup.

I had a number of good old threads from this board bookmarked so I could read them later and wrap my head around their ideas, but then I lost them all in a hard drive crash (strike two, Western Digital!). I also had a number of Japanese BBS's linked from this board bookmarked so I could take a look at their software's functionality and get some other ideas.

Anyway, these are all non-template suggestions:

• Topical category metadata in new thread creation so only one instance is necessary per site (further fine-grained behavior with PATH_INFO would let you nest one category inside another and view multiple categories of threads at once).

• Thorough search functionality a-la notchan, using PATH_INFO. This might not be possible without implementing a per-post metadata system though.

• Elaborating on the above, per-post metadata for "sage" status, for future-proofing in case someone wants to remove the functionality from the e-mail field (onto a checkbox, for example).

• config.pl parameter for a generic image that takes the place of a deleted image (ie, Hello Kitty)

• Fine-grained banning options that let you choose whether or not the user is blocked from reading a board, posting to a board, or both. Another parameter defines the duration of his ban ('0' for permaban), and another defines a reason/message displayed when the user tries to access a board.

• Replace HTML error pages with dialog box equivalents using JavaScript.

• Kill user deletion. I can't see any case for when it'd have constructive uses.

• Conversion to mod_perl?

I also have an early idea swimming around in my head about only bumping threads a few positions up, instead of to the top. Another idea is actively bumping threads down, either by a few positions or to the bottom. I'm not exactly sure yet what good it'd be for.

Also...

>* I'll add thread closing to Kareha, but I was thinking of setting the default behaviour to never permasage or close threads.

I think this is ideal for the time, until we have enough statistical data to derive thorough auto-permasage and auto-delete/archive algorithms. Just add the functionality for mods to manually set these statuses, but remove the "permasage at 1000" behavior.

The standalone thumbnailer project is a great idea too. As a suggestion, how about adding functionality to also read and thumbnail document files like TXT, PDF, and DOC?

> That's what I thought, but then why is it in the Reply pages?

Er, that's a bug I guess.

> 1) rename the RENZOKU constants to something that makes sense

I dunno, they're pretty useless anyway, as has been pointed out, so I don't know if I care enough to change them.

> 2) Have the string to sage and fusianasan defined as a constant in config

I dunno, if different boards use different strings, that will only make for immense confusion.

> 3) A specific string for ID:Heaven instead of anything in the email field

Well, the only string that makes sense is sage, but yes, I should implement the Heaven-on-sage behaviour.

> 4) Cookie preferences such as "Don't use expanding textarea" which leaves it small or big.. or another option for that choice as well; an option to not save Name/Email automatically; anything else that is useful?

Maybe, but I'm not sure it's worth the effort (I'd have to implement a preferences page for it, too).