You could add entire thread links to either the "num" or "posts" column in subback.
Plus if you were to allow those tags in HTML, you should do the same for WakabaMark (which actually takes its cue from Markdown, so I don't see why it has a different name).
How about listing what dmpk2k or you have done already?
Tell me more about these pre-compiled binaries. I thought that was impractical...I mean, instruction set differences and so on.
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]
>>236
I mean, thread titles in <h2> and post headers in <h3>.
Well, there are some issues to consider here:
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.
>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.
>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.
A 1001th post would be a bother.
Gah, I am totally confused about what to do about the admin interface. Separate script? Built-in? Javascript? How do I display the data? I have no idea!
>>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.
About the etyomology of "fusianasan":
http://4-ch.net/nihongo/kareha.pl/1102656968/224-
I hate that blue link next to the reply box! It looks ugly!
Also, there's no "Less options..."
Can't this be somewhere else but the post form?
>>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.
Also, for multiple board installations, use symlinks to allow you to keep just one installation of the main code files.
> 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.
You could add entire thread links to either the "num" or "posts" column in subback.
>>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).
> Maybe the thread title should be an l50 link?
That's what I've been saying in >>3!
> If anything, the role of capcodes should be minimized or altogether eradicated, in favor of ninja moderation.
It's up to the administration of the site how to use them. I am advocating that if they are used at all (and yes, there are useful instances for this and yes, these are and should be rare) then it would be helpful to be able to differentiate between site owner/admin/supermod/mod/maid/etc
>considering the default prune behaviour of imgboards
One of the parameters Kareha uses to determine pruning is MAX_POSTS, so even if you sage a thread under this new condition, you still add to the board's total postcount and speed up the process for pruning that thread, regardless of MAX_RES. The only flew is this assumes pruning is based on thread creation date, not popularity (because someone could easily bump a shitty thread and save it from deletion).
I also agree that enabling this functionality would further make threads vulnerable to intentional bumping by trolls. I was sorta envisioning it being used in a mature community where trolling is minimal and quickly weeded out by regulars.
Here's a new idea: how about trying this in reverse? Only "sage" posts are counted in MAX_RES, in which case saging can again be used either in protest or as a courtesy to others. The only problem is that people can then freely bump threads without consequence.
Copyright only applies to the literal code, not to features, ideas, or algorithm. Patents do, to some extent, but that's not the issue here. Since I'm not going to write the exact same code, there's little they can do.
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.
> Does the CSS selector -really- get in your way?
> Is having the More options thing really ruining your experience,
Yes and yes and I already stated why.
I am sure you know this but text markup takes place on a whole different level than identification/bumping issues. Your comment about pgp signatures is very funny but I will not honour it with a comment.
I almost forgot this:
For thread-closing, it would be nice if Kareha would post a last post, telling the thread is now over and closed (with some default message that can be customized for each board), akin to the 0ch 1001th post behaviour.
> Making them configurable from site to site is really dumb, because it would create an unthinkable usability mess.
Why? Let people figure out things themselves, if they are so keen on changing their keywords. They can get together in their own webmaster threads and figure this out. I don't see why this should be solved here.
Of course I think this is a dumb idea in the first place. Nobody needs to know what fusianasan and sage are. Write a FAQ with two sentences about it and/or let your oldtime users tell newbies. Two frickin' words, and you people talk about it as if it were something like making up a new system of romanization!
> 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.
That's a bit too much. You want to talk about sage and fusianasan in the comment field, not trigger it with it.
I suspect you are joking here, though. Design is about what you can take away and still remain optimal conveniency/efficiency on the user part, not about taking as much away as you are technically capable of.