I enjoyed that. Thanks for recommending it! (It's available on the Internet Archive, BTW. Though, that's not how I read it: I hate creating unnecessary accounts, so I just found a copy of it on Anna's Archive.)

There are some thoughts in that story (mostly presented by "Jasper") that struck a chord with me, so I'll repeat some of them here:

Getting Merit Poker done in time for the April 1st deadline was tough (and explains my lack of availability leading up to and during March). I've been chilling/recovering at half power (no glove) for the last few weeks.

In all seriousness, I'm always watching Meta, and working on forum-related things, even when I'm not posting about it. For example, last week I noticed a discussion come up about the "Report to moderator" function and saw Xal0lex mention that the "Please note that your email address will be revealed to the moderators if you use this." part of the description is no longer accurate. Someone asked if that language might be putting people off, and Welsh said that he thought so (which is my feeling, too), so I put together a patch and sent it to theymos.

---

That's a very nice suggestion, Cyrus! I've started work on it.

---

It's a whole thing... I'll put together my thoughts on this soon and either post them here or send you a PM.

It's a little off-topic for this thread, but, just so you know:

Hey, everyone!

I just wanted to say that I hope you're all having fun!

(I actually had this idea back in 2023, soon after I did the FlappyCAPTCHA thing, but, I wasn't able to pull it off in time for last year's event.)

There are some chat commands that might be worth knowing:

/t+ makes the table bigger.
/t- makes the table smaller.
/t= makes the table the default size.
/c+ makes the controls bigger.
/c- makes the controls smaller.
/c= makes the controls the default size.
/q unseats you and puts you back in spectator mode. (This was from before I added the "Leave" button.)
/qj is the "quit join" command. You can use it to quickly be re-seated (it basically just selects a new table at random, without much intelligence, so you could end up back on the table you came from; if that keeps happening then there are likely only a few active tables).
/> rotates your position on the table (in case you prefer being seated somewhere other than the "south" chair).
/e is a (basically useless to anyone but me) command that does a console.log() on any recorded errors.

You can use the up and down arrow keys to navigate through the items that you've entered. If the chat input doesn't "accept" something you've typed in, then that's because you're either trying to enter an unrecognized chat command, or you're not seated, or you're trying to enter something that would take too many bytes when encoded in UTF-8 (like a long string of emojis, or something).

If anyone is interested in some programming details: With comments, and minus the custom build script, this project consists of just 1599 lines of code (168 lines of PHP, 576 lines of Python, and 855 lines of JavaScript, all according to cloc). It uses only the standard library from each language. While this project was mostly a solo effort, I certainly wouldn't have been able to complete it without help from both theymos (who helped with ideas and who did the database/SMF integration), and ibminer (who designed the table, the cards, and the chips, and who also helped with ideas).

One last thing: I added a cool little tribute/nod to o_e_l_e_o (who we all still miss very much around here). If the 5 "community" cards come up in a way that's suggestive of o_e_l_e_o's palindromic name (as in, something like 2-3-4-3-2, or J-5-A-5-J, etc. then the cards will display with a blueish glow, and everyone at that table gets a pMerit gift (and whatever is in the pot gets tripled).

Hmm...

Are you sure that you fully understood my last post? I know that the punchline looks like I'm suggesting option 3, but, I'm not. In fact, if you go over all of my thinking on this, you'll see that at both points in time (back in December, and now in March) I've basically been inclined to leave TalkImg's default BBCode without any dimension information at all. Back in December that's where I landed because I felt like we didn't know whether or not including just the height attribute would actually help to reduce layout shifts, which is why I said: "So, you should probably do nothing until someone tests that hypothesis.", and now in March that's where I land again (but this time, it's because of the issue that Loyce pointed out; that is, I suspect that it's actually the height attribute that sometimes interacts poorly with the forum's responsive down-sizing of images).

I know that I have a tendency to explain my thinking in kind of a tiresome way, so please don't feel bad if you did misunderstand me. (That is, I expect people to linearly digest each sentence, like I do when I'm reading someone else's thoughts on something, but, I realize that that's incompatible with the modern tendency to just quickly skim over things while pausing at the relevant-looking bits in the hopes of being able to pick up the gist of what someone is saying.)

Wasn't that basically what I ended up suggesting when we last spoke about this?


And then later:


I remember wondering at the time: "Why did he go for the option that I least recommended?"

The thing is, back then, we (you, me, and Loyce, I mean) were only really considering things in terms of hoping to reduce the probability of layout shifts by accepting a possible increase in the amount of users incorrectly adjusting [img] dimensions, but, the issue that Loyce just now reported is actually orthogonal to all of that, and would've presented even if you had gone with option 3 (at least, according to the quick test that I just did).

So, that kind of leaves you in a tricky spot, where the only thing that you can really do from TalkImg's end (to both reduce the problem of people making incorrect BBCode size adjustments, and the problem where an image with a height attribute will sometimes not have its aspect ratio maintained during responsive down-sizing) is to revert the change and go with option 1 (which puts you back where you started in terms of the layout shift problem).

Yup, me too.

I figured it was because people were taking the BBCode that comes from TalkImg and then sometimes messing up the aspect ratio by fiddling with the image dimensions...

But, it looks like what's mostly going on is that having non-automatic dimensions is interacting poorly with this:


I think it's going to be tricky to fix in a completely clean way.

I guess, a discussion-wise starting point might be:


(As in, I think that that would fix the specific problem you're talking about, but, not without producing some other consequences, too.)

---

To everyone that's recently left me a post (or sent me a PM): I'm sorry that I've been so unresponsive lately. I'll get back into my usual rhythm soon.

I think that the weirdness you're talking about is due to one (or both) of the following uBlock filters:


Both that XPath expression, and the CSS selector seem buggy to me (in different ways).

Anyway, I'm not sure what content blocker you're running, but I can get this post to display correctly for me by disabling "cosmetic filtering" in uBlock Origin:

While there definitely are members like that, I'm not sure that I'd try to pick them out using the monthly snapshots. For example, if you look a few posts above (at the stats for October 2024), I'm near the top of the list, but that doesn't really say anything useful about my merit-sending habits in general...

I've received 5573 merits in total, giving me 2786.5 sMerits, 2706 of which I've put back into the system (~97%). So if someone were to look at that one month of data and think "That damn PowerGlove guy, getting all those merits and then being a stingy bastard when it comes to giving them back out.", they'd be mistaken. (Honestly, I often wish that I had more sMerits to hand out, because it always feels really cheap to me when I leave just one merit on a post that deserves more, but, if I routinely spent my balance in bigger chunks, then I'd basically only get to merit a small handful of posts before I'd have to turn my attention back to earning merit so that I can top up my sMerit balance, and I can only do that at a fairly pedestrian pace; I mean, I know that my merit-to-post ratio is high, but, probably that's precisely due to me not posting at a rate much beyond the natural rate that I can add value at.)

Haha, yeah. I do. (To be clear, if what you used Google for was to retrieve the links to articles which you have previously read, enjoyed, and are now recommending to me, then I wouldn't be irritated by that. But if all you did was use Google to just now find some articles saying something, then, yeah, that's kind of irritating, isn't it? I mean, I could just do that myself.)

Are you talking about me or suchmoon?

If you're talking about me, then, I don't think that I'm "denying the obvious", am I? I'm just saying that I prefer to interact with people in ways that familiarize me with them rather than their assistants, and that I'm worried that people are going to eagerly embrace, at the great expense of their own skill development, this new low-effort way of "creating".

If you're talking about suchmoon, then, I think that they probably feel similarly, and that you're interpreting their post in a too-literal and ungenerous way. (As in, I don't think that their position is actually "AI isn't changing the world". Probably they just meant that, in their view, it's not something that deserves the positive connotations associated with language like "world changing".)

I'd personally (that is, if it were you and I talking rather than you and suchmoon) find a response consisting of a lightly-curated set of ChatGPT-sourced links to be pretty irritating...

When I'm chatting with someone, I'm interested in engaging with them (and enjoying their style of writing/talking/thinking, while considering their perspective on things, and maybe setting aside some time to digest the resources that they have recommended to me, etc.)

If someone feels that they must involve the output of an artificial intelligence model in their post (even if it's just to clean up their writing), then I'd personally prefer that that was made very clear (so that I know what not to consider when trying to evaluate them; beyond knowing what content I should ignore, I also don't want to, for example, think "Wow this person is very detail-oriented!" only to later find out that, when writing without assistance, they're actually the kind of person who frequently mixes up "its" and "it's").

One of the things that worries me about this new generative AI frontier is the difficult-to-appreciate damage that I think it's going to inflict on society as human activity shifts even further away from "comprehension", and further towards "productivity". That is, people seem to think that it's a good idea to be able to operate outside of the limits of their own understanding, and to, for example, write programs beyond their ability as a programmer, or make music beyond their ability as a musician, or paint scenes beyond their ability as an artist. While most people seem super excited about these new low-comprehension paths to productivity being opened up, I mostly just see paths that will inevitably lower the average value of things as it becomes less and less popular for people to invest the time it takes to build real expertise in something.

---

What follows is a personal anecdote that probably most people can't relate to, so feel free to skip it, but, when I was a kid, I was fascinated (to put it mildly) by computer games and wanted to know how to make one myself. Back then, the answer wasn't "That's easy, just pick between Unity and Unreal Engine!", it was "Computer games are just programs. Advanced computer games are advanced computer programs. If you're aiming to make high-quality computer games, then you'll need to become a highly competent computer programmer, first."

That put me on a learning path that went: Logo (via "turtle graphics"), then BASIC, then Pascal, and then C and x86 assembly. Looking back, I feel really fortunate that I was effectively forced (by the lack of easier alternatives) to go down that very difficult and very tedious path (which was honestly way too challenging for me at the age I started, but, I didn't know that at the time, and so I just did my best and kept trying and trying until things clicked). I'm grateful because, by the time I was 13 (and my friends were struggling with problems like how to style their hair, or how to get shoes with lights in them), I was happily programming little graphical demos and implementing things like Bresenham's line algorithm in x86 assembly and learning about things like perspective projection, and had somehow become a surprisingly well-rounded if very inexperienced programmer. I didn't know it at the time, but I now know (or at least, very strongly suspect) that minus that early high-difficulty foundation (or one similar to it) I'd be a much, much less capable person today (I mean, life knocked me off the path I started down, like it does to many people, and I never actually did get involved in commercial game development, but I did do a lot of dependency-free DOS-era gamedev in private, and that ended up forming the bedrock of my programming style).

From my perspective, the skill of programmers (on average) has been dropping for a long time now. Most programming these days seems to be about stitching together a set of not-fully-understood dependencies, and then hoping for the best while you endlessly push bugs around or turn them from one kind into another. Add a synthetic "programming assistant" to the mix and even the stitching becomes something that most people will decide not to do on their own (which means that they'll typically neither understand the components being bound together, nor understand the binding itself; writing code that appears to work correctly is easy, it's the full comprehension of it along with all of its dependencies that's the hard part).

I ran into a nice suggestion from a long time ago (~12 years):


Maybe newer members haven't encountered this particular issue before, but I know exactly what the above poster is complaining about, and I'm sure that many other people do, too.

Basically, if you (with some exceptions that aren't worth getting into) post an unbroken sequence of 80 or more letters, digits, underscores and/or periods, then it'll automatically get divided into chunks which are each 79 characters in length (or less, in the case of the final chunk).

So, for example, if you were to post the SHA-512 of the text "How would you like to suck my balls, Mr. Garrison?", then instead of it appearing like this:



It would appear like this:



(See that tiny space at around the two-thirds point? Between dbcc and 9e06?)

That "breaker" space will, among other things, cause problems with copy-pasting (because there's now a space in the content that the author didn't intend for there to be), and will also affect double-click selecting, like this:



So, what I've done is add a new kind of "breaker" to SMF (to go along with the three existing variations that are chosen between based on what browser the BBCode parser thinks it's producing markup for). This new breaker avoids the problems described above and is used by default (but, I've left the older breakers accessible by a context variable in case theymos wishes to selectively flip between the new and the old behavior).

Here's the diff:

---

When doing these sorts of fixes, I always hem and haw on whether or not it makes sense to keep using the older behavior on old posts, and only use the newer behavior on new posts...

I guess, I don't much like the idea of posts changing in ways that the author didn't account for (for example, I hate that one of my own posts was mangled by the wordfilter at some point after I authored it). I (mostly) lean toward wanting to keep old posts displaying as they did at the time they were authored. For example, in the post I quoted from above, mrb is demonstrating the problem he's describing, as in, if you try to copy-paste his example-sequence, then you'll get the result he's talking about: 79 characters, followed by a space, followed by 41 characters. But, after this fix is applied, if you then tried to copy-paste mrb's example, you'll find that you get 120 contiguous characters, so it'll look (from the perspective of someone reading that post cold) like mrb must have been confused or mistaken when he constructed that example.

I dunno, maybe I'm just overthinking things, but, in case theymos feels that the old behavior is worth preserving, here are two additional diffs that will make sure (at least, in the two places that are important, I think) that old posts won't be affected by this fix:

I'm always flipping through old-Meta, looking for forum-improvement discussions, and I recently bumped into the following post by BadBear:


There's something cleaner and more constructive-sounding [1] about "Trade Disputes" than "Scam Accusations", isn't there?

I mean, I can't see "Scam Accusations" being renamed, but, maybe there's a case to be made for "Trade Disputes" to be added? (As in, user-to-user trade-related issues could go there, instead of in "Scam Accusations" which sounds kind of goofy to my ear for that use-case. If I was having a contentious financial interaction with another user, I'd feel pretty stupid making a post about it in "Scam Accusations", and I'd also feel it wrong to post about it in "Reputation", but "Trade Disputes" would feel just right.)

Anyway, just leaving BadBear's idea here because I think it's worth pondering...

---

[1] Please don't think that I like the idea of "soft language". If you've got ~7 minutes, I recommend watching George Carlin's take on this. If you're anything like me, you'll find yourself smiling and nodding along to basically the whole thing. The way he delivers the following line always gets me: "They don't have a negative cash flow position... They're fuckin' broke!"

I actually meant (but then forgot) to stick up for dkbit98 about this...

There genuinely was a strange interaction (which I independently confirmed and then fixed) between the BPIP extension and the "Ignore threads" userscript by NLNico.

Here's my side of the conversation I had with dkbit98 about this:

Haha, yeah. You didn't seriously think that I'd expect users to have to do this all the time, did you?

At this "concept" stage all I'm really interested in is gathering feedback from the people in this thread that want to try it (for example, I didn't really put much thought into the key assignments; I just quickly roughed out some code to demonstrate what I was thinking about).

That "undefined" is expected, so it probably did work the first time (but you didn't immediately test it, because you got spooked by the scary-looking undefined). When you tried it again (after removing the parentheses you mentioned), you would have gotten something like function in response, which, while more comforting, wouldn't have actually accomplished anything. (In technical terms, initially you entered what's known as an IIFE, that is, an immediately invoked function expression, and on your second attempt you entered just the function expression part, which, besides evaluating to itself, did nothing.)

To confirm the above, try entering this into a console:


You should get something like !!! in response (along with an undefined).

Now, try entering the following (that is, make the same bracket-removing adjustment that you made to my code):


You should get something like function in response (but, notice that you didn't get back any !!!, that is, the function wasn't executed, it was just evaluated).

I know. I know. That "0" is a flippin' hazard, IMO.

I have a patch that removes the "0", and also adds mouse wheel support:


But, it's written in a new/different way compared to my other patches, and I'm still trying to figure out with theymos if he'll let me work in this new way.

(Concerning your specific suggestion of user-settable default values: I've got some ideas for that, but I'd first like to see the above-mentioned patch get accepted before pursuing more elaborate merit-sending tweaks.)

---

Yup, I know what you mean.

While it won't address your suggestion exactly as you've stated it, I am working on something that I think will help you with the problem you've described:

---

Hi.

It's probably been suggested before, if not in this thread then in some other Meta topic. (I don't mind repeated suggestions; if I notice that something has been suggested over and over, then I just think more and more about some way to implement it.)

I could see something like that being useful. (I write my posts in Sublime Text, so it wouldn't be very useful to me personally, but, I've noticed that I usually need to make changes to my posts after I've previewed them, and when doing that I tend to use the forum's BBCode editor.)

Hmm... I don't think I like the idea of overriding the browser's built-in keyboard shortcuts (for example, in Firefox, Ctrl+B normally toggles the bookmarks sidebar).

But, your suggestion does give me an idea: If you think about it, you could make single-key shortcuts work if they were only "in effect" while something was selected. That is, normally b just means "b", but you could make it mean something else in the context of a selection. As in, you would select some text and then just hit b to make it bold (and if the selection were preserved, you could then even hit it a second time to make it unbold).

It's tough to explain what I mean, so lemme do my warm-up stretches real quick (who farted?), crack my knuckles (not really), and then try to write some example code...

2 cappuccinos later:


You can try this by going to any Bitcointalk page that contains a BBCode editor, and then opening up the developer tools in your browser (Ctrl+Shift+I for me) and pasting the above code into the "Console" and then hitting Enter (probably it'll bug you to type in a confirmation phrase like "allow pasting" before permitting you to do so). That should then give you (temporarily; just for that tab) the following selection-shortcuts: b for bold, i for italicize, u for underline, s for strikethough, t for teletype, q for quote, c for code, g for gray (lowlight; Loyce knows what I mean), and y for yellow (highlight). Also [, ], and \ for left-align, right-align, and center-align, respectively.

I've got to say, it feels quite natural to me. With a mouse it feels natural for me to just double-click on a word and then hit b to make it bold, for example. And for people like Loyce who say that they prefer not to involve the mouse too much while writing posts, it's still quite pleasant to make selections with the keyboard (either character-by-character with Shift+Right/Shift+Left, or chunk-by-chunk with Ctrl+Shift+Right/Ctrl+Shift+Left, or by selecting stretches with Shift+End/Shift+Home). Also, even though it wasn't what I set out to do, I suspect that this might all work out pretty nicely on mobile, too.

---

Let me know how you find the single-key-shortcuts idea from above.

It does use a bit of JavaScript, but only what's emitted in the onclick attribute on the <button> element (and that JS is self-contained).

Nice catch. Factoring both you and Loyce into my thinking was part of the reason I settled on the approach that I did. That is, this feature should continue to work correctly in the context of HTML post scraping, without any special handling. (The only difference, and I find it to be a sensible one, will be in how the "Show" button itself is styled: on the forum proper it'll have the non-rounded and blue-tinted appearance that I think makes it look at-home in the context of a Bitcointalk post or PM, but on Ninjastic it'll just look like an unstyled button, I think, which would appear natural to me in the context of a post archive.)

Ha! I see you even proposed a button in the same location.

(I can't say whether or not I've previously seen that topic, but I'd guess not; that topic exists in the time-wise hole between Meta topics that are either recent enough for me to have bumped into them naturally, or old enough for me to have bumped into them while reverse-reading Meta.)

---

It's possible, but I'd prefer the need for that to become very apparent before doing so.

Yep. I put a tooltip in there originally. It started as "Click to reveal", but then I (reluctantly) changed it to "Click/tap to reveal" (or something similar; I don't remember exactly).

(I was in my early 20s when I unboxed my first iPhone, so you'd think that I'd be part of the mobile-first world, but, I'm not. I was blown away by the possibilities, sure, but, on the other hand, my mama didn't raise no fool, so it didn't take very long for me to get over the initial excitement and to recognize that much like with social media, this was something that, if I allowed it to, would just slowly chip away at a deeper kind of happiness in me, in exchange for an artificial and always-temporary boost to a much less satisfying kind of happiness. More and more, and for many years now, I go out of my way to avoid using my smartphone, to the point of placing it in a wooden box in one of my spare rooms and then just forgetting about the contemptible thing for weeks at a time, so, using it as infrequently as I do, and then anyway only as an actual telephone, I genuinely couldn't say with very much confidence what might sound "right" to a modern ear: Tap? Touch? Fingerbang?)

Anyway, I then changed it to "Interact to reveal". I left it that way for a month or two (while working on other stuff), and when I came back to it with fresh eyes it looked wrong to me, so I took it out.

I think maybe "Reveal hidden content" would work. It's a simple thing for theymos to add himself (it's just a title="Reveal hidden content" added to the <button> element within each of the two new 'before' => ... lines present in the second diff).

---

It does.

(You can even nest both [hide] and [hide-inline] tags to make content that can only be revealed once other content has been revealed; I'm hoping that not too many ding-dongs will estimate it funny to make irritating use of hide-nesting.)

Yep. In that case, theymos only has to consider the first two diffs. (Though, I do like the icon, both because it looks natural to me next to those other low-resolution, hard-alpha-channel icons, and because adding it is really very simple; that toolbar is one of the few things I've found in the SMF codebase that can be extended without too much thought.)

(I asked Poker Player to unlock this thread so that I could post in it. I drafted a reply that grew much larger than I meant for it to, and basically didn't want it to go to waste. Even though it's written in a way that suggests that I might be expecting a response to it, I'm not; I'm just sharing some long-winded thoughts, is all, in the hope that some of them might be found to be interesting.)

Hmm... Probably I expressed myself poorly which led to you misunderstanding me. The problem is, my thoughts on the trust system are scattered across more than a few posts (and probably even more PMs), and it's not really practical for me to try to share my complete perspective on it each time I write something concerning it.

A lot of my perspective on the trust system can be understood as an argument formed in terms of expected value. Judging by your handle, I'm guessing that you already understand that principle well, but, as a refresher for the people that don't understand it, let's ask ourselves whether or not it makes mathematical sense to accept a gambling offer like the following:

"Flip a fair coin 5 times. If all 5 flips come up as heads, then you win $100. If at least one of your flips comes up as tails, then you lose $5."

One way to analyze an offer like that is to multiply the probability of a successful outcome (which is: 0.5**5, or 3.125%) by the amount you will gain in that case ($100), and then subtract from that the probability of an unsuccessful outcome (which is: 1 - 0.5**5, or 96.875%) multiplied by the amount you will lose in that case ($5).

So, 0.03125 * 100 - 0.96875 * 5 = −1.71875. In other words, you'll lose ~$1.72 (that's a tilde, not a minus sign, BTW) each time you try that game. That's difficult for most people to see, because in concrete terms each attempt will either lose you $5, or gain you $100. But, in some abstract mathematical sense you're actually losing ~$1.72 every time you play the game, and the more you play the game, the more you should expect your concrete balance to mimic your abstract one (that is, if you play the game 100 times, then you should expect to lose ~$172, and if you play it 1000 times, then you should expect to lose ~$1720).

I've run into my fair share of people who aren't convinced by the concept of expected value, and think that it's some kind of neat idea that doesn't correlate with reality, so to drive the point home, here's a Python script that actually simulates what would happen to a starting balance of $0 if you played the above game 1 million times (you should expect to lose something in the neighborhood of 1.7 million dollars, so let's see if that actually bears out):


Running the above script gives me:


(If my [hide] tag were available, I'd have used it on the above aside.)

So, let's take "expected value" as a sensible idea, and, for ease of discussion, let's give the specific two-outcome formula from above some mnemonic terms, like this:

S * u - F * d (where S is the probability of success, u is the upside, F is the probability of failure, and d is the downside).

Let's also invent a new unit called assist and imagine that that made-up unit encapsulates the idea of Bitcointalk-related value (as in, when you do something that helps the forum, your action can be thought of as one that produces positive assist, and when you do something that harms the forum, your action can be thought of as one that produces negative assist).

Different trust-actions admit slightly different treatments, so let's (for the rest of this post) just focus on the following case: Leaving someone negative (or neutral-negative) feedback when you estimate that something warning-worthy is happening, has happened, or will happen. In this case, S is the chance that you're not mistaken in your judgment, and F is the chance that you are mistaken in your judgment. That takes care of S and F, but what about u and d? Let's assume that the upside (u) is 1 unit of "assist" (our made-up unit to encapsulate forum-related value), and that the downside (d) is also 1 unit of assist (that is, let's assume we contribute as much value to Bitcointalk by being correct in our judgment as we detract from it by being incorrect; I don't think that that's a fair assumption, especially for the kind of trust-actions we're talking about, but let's do it that way for now). Finally, let's say someone has an accuracy of 95% (as in, 95% of the time their judgment turns out to have been spot-on, and 5% of the time it turns out that they were mistaken).

So, 0.95 * 1 - 0.05 * 1 = 0.9. In other words, every time that our 95%-accurate speculative-feedback-leaver does their thing, they produce 0.9 units of assist. Nice! Let them do their thing 100 times and you can expect them to have produced 90 units of assist. They should be on DT, yeah?

The problem I have with the above calculation is to do with the ratio between u and d. I don't share the following view, but I would guess that most people feel that u should be bigger than d (or at the very least that they should be set equal to each other, as above), which is to say, I think most people feel that when their judgment-calls are correct then they've done something very good for Bitcointalk (like actually helped some other user to avoid being scammed), and that when they get things wrong and make mistakes then that's not really such a big deal (especially compared to all the good that they believe they're doing when they're not mistaken). Let's call this perspective (that u should be greater than or equal to d, and that getting it "right" is worth many instances of getting it "wrong") the "u>=d" perspective.

I have the opposite (and then some) view (let's call this one the "u<<d" perspective). My perspective is that even when you do get things right, you're producing a much smaller effect on other people's decision-making than you think you are (that is, you're not actually sparing other users pain and suffering on any non-negligible scale, you just like to believe that you are, or, even worse, you already suspect that you're not really helping anything or anyone, but your sense-of-justice compels you to do something, even if it makes little sense to do so). In my view, the upside when you're right is much, much smaller than the downside when you're wrong. When you're right, you think that your feedback will correctly help some other user to make a better/safer decision than they would have been able to make without you taking the action that you took (and in my view, that's mostly just wishful thinking that everyone wants to believe is true [1]). But when you're wrong, you're almost certainly causing definite harm (as in, tagging some innocent user and contributing to them losing their enthusiasm for the forum, for example).

So, I'd scale the value for u way, way down. Something like 0.01 makes more sense to me than 1 does. I mean, who can really say what the value should be set to, especially when we're dealing with a made-up unit, but, remember, all that that value relates to is how genuinely helpful to other people your accurate speculative feedback actually is, and what I'm saying is that (I think) people have been vastly overestimating that value (u), and that scaling it down (relative to d) by two factors of 10 would be my guesstimate to get it within realistic proximity of its "true" value. With that adjustment, the previous hypothetical user with an accuracy of 95% is actually producing -0.0405 units of assist per trust-action (of the kind we've limited our thinking to), and should therefore stop doing that. Even a user with 99% accuracy would produce small amounts of negative assist with each action that they take. If you look at things through that lens (like I do), then your view will be that this kind of feedback is just slowly making Bitcointalk worse and worse (in the same way that my example-game unavoidably loses you ~$1.72 each time you play it).

Look, I don't expect many will support my view (because of how counterintuitive and difficult-to-accept the conclusion is), but I hope that most people can at least appreciate the shape of my argument, and realize how easy it would be for someone to set out to do one thing (for example, to try to make the forum a nicer/safer place by taking it upon themselves to actively "police" it) and instead end up mostly accomplishing something else (like maybe succeeding in making things negligibly safer, but only at the greater expense of very non-negligibly contributing to the negative forum dynamics that make the whole environment less productive and much less hospitable than it could be for new users and new businesses).

---

[1] Since I think it's typically DT members that feel the need to leave the kind of feedback we've been talking about, here's an interesting thought experiment: Imagine Bitcointalk implemented a policy of dissolving DT for the first three months of every year. What do you predict the consequences of that would be? Personally, I find the "doomsday" prediction that during the first quarter of each year Bitcointalk would temporarily devolve into some kind of shitshow with people getting scammed left and right to be an extremely silly one.

I mentioned this one at the end of December:


Most of the above description still stands, but I've since done more reading/thinking and changed my mind about the SEO impact. So, instead of the feature working one way for guests and another way for non-guests, it now just works the same way for everyone.

Something that the above description skipped over is that it's actually a pair of tags that'll be added: a block-level tag called [hide], and an inline-level tag called [hide-inline]. (Don't worry too much about the difference, the block-level [hide] tag is almost always the one you want, with the [hide-inline] tag only really being useful in what I expect will be rare situations.)

Another thing that the above description didn't mention is that there's a new button added for the [hide] tag (next to the "Insert List" button, located at the bottom-right):



Here are the diffs for @theymos (in the order I recommend applying them):


(The above diff makes sense for my version of SMF, but in theymos' version the file that should be adjusted is inside the Themes/custom1 directory.)


(This diff is where most of the feature exists.)


(The above isn't a diff, but rather a command that can be executed to re-create the icon I made with Inkscape and GIMP. The 101-byte hide.gif file that the above command creates should be moved into the Themes/custom1/images/bbc directory.)


(This diff adds the new "Hide Content" button to the BBCode editor.)

I considered including diffs to update the help section on posting and the BBCode reference, but those diffs are a bit messy (and bigger than the above diffs combined). Perhaps I'll update that in some later patch (and maybe add the other tags that are missing from it, too).

---

(I often try to make these "patch" topics substantive beyond the code, and pitch everyone on the usefulness of a thing, and maybe explain some of the thinking and trial-and-error that went into it. But, I've been struggling to stay enthusiastic about the forum lately, and though I expect I'll bounce back and feel positive about the forum once again, for now I'm in kind of a matter-of-fact/humorless mood. I'm sorry about that. If there's some technical detail that interests you, or you'd like to know why I did or didn't do something in a certain way, send me a PM. It's time-wise very expensive for me to recall/unpack all of my thinking on something and to respond properly to questions/suggestions, and I often leave posts unanswered because I either can’t find the time to reply to them, or because I’ve forgotten about them by the time that I do have surplus bandwidth. If you send me a question that you've clearly put some thought into, I promise to at some point get back to you with an answer.)