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

Oh okay.

I agree, for Kareha at least.

Oh okay.

I agree, for Kareha at least.

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

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

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

> Is it intentional that thread links without a trailing slash

Uh, I was wondering the same thing. I'm not sure. I guess I should fix that.

>>148

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

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.

>2) Have the string to sage and fusianasan defined as a constant in config
>3) A specific string for ID:Heaven instead of anything in the email field

As I mentioned above, this would better work if they could be modified within each template in the list of string variable definitions.

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

I like this one, as far as saving name and e-mail inputs go. I occasionally browse 4-ch at school, and it'd be nice for just an option to clear cookies when you're done and don't want anyone else to use your name, e-mail, and deletion password.

What the hell is RENZOKU?

P.S. >>151 is RMS

The problem reported in >>143 is still present.

>>59-60

Details, please. Everything works for me.

>>154
Kami! Nice ID.

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

I've returned from the world of the dead, with old forgotten...suggestions! http://wakaba.c3.cx/sup/kareha.pl/1109447905/l50

>-Scaleable administration (ie, [variable permissions for different passwords])
>-Forcenick and/or force anon for [specified IPs]

Also, here's something that would be useful, but is a bit more work than I feel like doing right now:

A simple thumbnailing program, that has no external dependencies and can be compiled to a maximally compatible, statically linked executable, for those who have hosts that don't have any image processing software, and don't allow you to compile your own. Should be able to load GIF, JPEG and PNG images, and produce JPEG thumbnails. Should contain all the source code it needs without linking to external libraries (it's easy enough to just stuff libjpeg, libpng, and zlib into the distro).

If anyone is lacking a programming project, feel free to take up this one! If you do, I can provide some fairly fast and good-looking image scaling code (or just rip it out of mangariini yourself).

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

>>10
Exactly, but considering a lot of people can't make heads from tails in config.pl, how about a saner default?

>>11
That's true, but if least-popular threads are set to be deleted, instead of oldest-first, you don't have to guess.

> Wait, why should l50 links be indexed/cached?

Because the only way for the search engine to find the old threads is to go through the l50 links. I'm taking the advice of >>322 though.

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

You need to explain what you're talking about before I can do anything about that. What style, and what does "wrap the outer color border(s) around" mean?

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

It's there because freefloating unlabelled links look weird.

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

They're there, but only if you enable pruning by size.

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

No. I'm too lazy to figure what that's supposed to do, and I don't think anybody actually wants to use that in the first place.

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

There's no database to keep IP data in, and I'd prefer to keep the script completely agnostic to IP addresses.

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

No, because I don't know what you mean.

How come this is now the by far biggest thread on this board?

Maybe it's because I'm posting useless replies like this one!

Too late! Already released!

>>305

Shift-reload already! Also, most people are familiar with "More options..." links and know when and when not to click them. I might see about styling it, though.

test1

>>266

I told you to shift-reload!

>>161

>3) was about a string to trigger ID:Heaven, not a constant for the Heaven part (which is already configurable)

That's what I was referring to also in >>154 (S_NOID being the theoretical trigger string for ID:Heaven).

Concerning localization: there are certain compromises with input triggers that must be made in order to maintain interoperability with Japanese users coming from 2ch/Futaba. They're not going to care about a system where "sage" and "fusianasan" (in Roman too I'm guessing, can someone confirm this?) don't work in their respective fields. In effect, 2ch set a standard of usability that we need to follow if we want to build a bridge between both communities.

On the flipside, I think there should also be a secondary set of trigger strings that would be more coherent to Western users and universal to all Western boards. Making them configurable from site to site is really dumb, because it would create an unthinkable usability mess. With Shiichan's death, Kareha stands unrivaled, and setting these strings in stone would ingrain them in the culture like "sage" and "fusianasan" have been in Japan. Thinking very optimistically, if a Western BBS site should grow into something large enough for 2channers to strongly take notice of, they would pick up on these triggers and possibly make their own concessions to implement them in 0ch.

What they should be is yet to be determined. Unfortunately, they'll probably have to be pretty dull in comparison to the witty botanical references and word puns in 2ch and Futaba.

>>163

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

Then why not simply boil it all down to the comment field, with trigger strings for inputting the name, e-mail, sage, ID:Heaven, and fusianasan? You can get a lot more minimal with the current interface.

>Huh?

He meant saging a thread just because a part of the actual e-mail address contains the word "sage."

>>249 Then the default should be no markup.

Anyway, test with |

>>201

Yeah, no, maybe. Using secure trips for capcodes also adds extra protections against accidentially misspellingyour capcode and leaving it open to attack.