Lol @ "got the hump". Makes me chuckle.

I feel the same way you do about how rule #32 violations are handled.

Not that it helps you now, but, I made something a while ago (which was never added) that I think might have prevented your confusion:

I don't like most approaches that are based directly on ratios (even though I've suggested them myself before), because those ratios are sometimes way off (for an example of this, consider Symmetrick, who now has a jaw-slackening merit-to-post ratio of ~23:1 over 516 posts, but, before much of their stuff was self-deleted, their ratio was closer to ~0.77:1; still good, but, ~30 times less so). Also, if you read the rest of this post, I think you'll see that I'm advocating for something that wouldn't continually force any particular "time frame" on anyone (neither in terms of real time, nor in terms of "time" that only advances by one unit when you make a post).

---

Agreed. But, that's not what I'm proposing. When I say, "In effect, you'll need to earn at least 1 merit for every 10 posts you write (on average) if you wish to prevent your account from slowly drifting toward a lower rank.", what I mean is, "A system that charges you 0.1 merits for each post you make has the practical effect of establishing a rank-wise equilibrium requirement of 1 merit for every 10 posts.", but, there's nothing in what I'm proposing that can even notice when you've made 10 posts, so, really, it's all about how things go over the long term for any poster (as in, it's fine if someone makes 100 posts without receiving any merits at all, and then suddenly writes a banger that gets 10 merits [1]).

[1] The only issue around this, which I'm reluctant to get into because it's not important, is that some back-and-forth bouncing will sometimes occur when someone is near to a rank boundary.

---

It's clear to me (from some of the responses I've read) that I've done a poor job with explaining this idea. So, I'll take another shot at it, by way of analogy: Imagine that there's a service/website/app called Thoughts4Berries where you can submit very short pieces of original writing (as many and as often as you like) on any of a wide range of topics, and for each submission of yours that's deemed worthy (according to an algorithm that nobody seems to be able to fully figure out) you receive a prize of at least 10 berries (but you might also receive 50, 100, 250, 500, or even 1000+ berries if your submission is truly outstanding). Thoughts4Berries guarantees you that every submission received is always exposed to some chance of winning a prize (either now or in the future). So, basically, if you want berries, write something good and send it to Thoughts4Berries. You'll either get no berries for that attempt, or at least 10 berries for it. If you take the two possible outcomes and combine them with the previously-mentioned "greater-than-zero probability" guarantee, then you'll see that there's something very naive about this whole setup: the expected value is always positive. So, no matter what you submit, your berry balance will increase (not your actual balance, but the expected balance that your actual balance will tend toward over many attempts). Given the fact that the expected value of any submission is always positive, many people figure out that it's possible to farm berries by submitting lots and lots of attempts, but, if your submissions are terrible then the low chance of reward makes that a very slow process, so, a better strategy would be to submit many bad-but-not-terrible attempts. Of course, the best strategy (for everyone involved) would be to only make actually-worthwhile submissions, but, who has the time to do things sensibly, amirite? Now, let's say Thoughts4Berries comes to realize that most of what they get sent is low-effort junk that's barely worth reading. What can/should they do about that? There's a frustrated (and good-looking, too) dude working at Thoughts4Berries that goes by the name of, uh, MaxLegroom. MaxLegroom thinks that it's worth exploring the following idea: What if we extended an infinite line of "berry" credit to every user (to be offset against any prizes they might win), and then used that credit facility to charge 1 berry per submission? MaxLegroom sees that as an obvious way to reduce the amount of junk submissions by establishing a submission-wise "noise floor" that's too expensive for any rational user to keep operating entirely beneath. The only real question in ML's mind is where that cut-off should be placed (which is determined by the per-submission cost; maybe 1 berry is too much, he thinks).

OK. So. What does it look like when something like the above is applied to Bitcointalk's ranking system?

Instead of the "rank requirements" table looking like this:

Rank	Required activity	Required merit
Brand new	0	0
Newbie	1	0
Jr. Member	30	1
Member	60	10
Full Member	120	100
Sr. Member	240	250
Hero Member	480	500
Legendary	775-1030 (random)	1000

It would look like this:

Rank	Required activity	Required merit (less carry)
Brand new	0	0
Newbie	1	0
Jr. Member	30	1
Member	60	10
Full Member	120	100
Sr. Member	240	250
Hero Member	480	500
Legendary	775-1030 (random)	1000

Notice that I've changed nothing except for the description of the third column, because that's really all I'm proposing. I'm saying that the rank requirements should stay the same, but, instead of the third column referring to the required amount of merit, I think it would encourage better posting behavior if that column referred to the required amount of after-carry merit (where "carry" is something that slowly builds up as you post).

---

I do get what you're saying. The first issue I have with that approach is that it's subjective and therefore would be unevenly applied (different mods have different views concerning what makes something low-value; if I were a mod, for example, I'd probably leave many reports in an "unhandled" state because my anti-censorship inclination is much stronger than my dislike for junk posts). My second issue with that approach is that it applies pressure to a building block of the forum that's much more crucial than "ranking up": the forum's free-speech orientation should be preserved as much as possible, IMO, and placing it under unnecessary strain is unwise, I think. The right to post is paramount, the right to rank up... not so much. My third issue with that approach is that it's inefficient compared to a systemic disincentive that attenuates the creation of junk posts. (There's a software engineering idea that goes something like: "the fastest code is the code that's never executed", or, in the context of debugging: "the easiest code to debug is the code that isn't there". Applying that sentiment to moderation would go something like: "the easiest posts to moderate are the posts that were never written".)

I once tried to explain this whole "carry" concept in a PM, and I'll quote a small piece of that because it adds to the above:


Maybe. But, it doesn't make sense to me for the forum to "outsource" something so fundamental.

---

Let me express my interpretation of your point, as: "If the ranking-up mechanism is largely subjective, then I think it's a mistake for the ranking-down mechanism to be objective".

As in, it's unfair when the thing that lifts you up is hit-or-miss, but the thing that pushes you down always hits. I get that. It sounds very unfair. But, that conclusion depends on:

(1) How unreliable is the first thing?

(2) How strong is the second thing compared to the first thing?

To answer (1): I don't think the merit system is very unreliable. I can imagine that the whole apparatus must seem very unfair/rigged/cliquey to anyone that's struggling to earn merit, but, my own experience here has been that it's impossible not to get merited when you're actually trying to add value to conversations and you're avoiding conversations where you don't believe that you have anything valuable to say. Sure, maybe some of your really good posts will go unnoticed, but, if you keep hitting the "value" nail instead of the "quota" nail (or the "agenda" nail, or the "vendetta" nail, the list goes on), then, trust me, you'll stand out, and you'll eventually get enough merit that "activity" might become your ranking-up bottleneck (obviously, I'm not talking about you; you're already a stand-out member). I realize that I haven't answered any of your concerns around uneven merit distribution across the forum's different sections, but, I view that as an issue that would take me many posts to unpack, and one that's orthogonal to the adjustment I'm proposing.

To answer (2): I've purposely tried to make the ranking-down force weak compared to the ranking-up force (partially to address the perfectly-enforced vs. imperfectly-enforced mismatch). I don't believe it's possible to make the ranking-up force perfect without also making it unmeritocratic. But, I also don't believe that that means that the ranking-down force has to be imperfect, too. It just means that the ranking-down force has to be tuned to compensate.

---

There's more that I'd like to say, but, I'm in a pretty annoyed mood at the moment, and I don't think that a massive wall of text is anything that anyone wants to parse, anyway. (I've also noticed that I tend to write posts and PMs in a way where the things I've said in one part are comprehension-wise affected by the things I've said in earlier or later parts. As in, I often try to explain things conversationally, like I'm talking to a peer, rather than expositionally, like I'm talking to a student. So, the longer I make a post, or the more posts about something that I make, the more opportunity there is for unsatisfying discussion around not-meant-to-be-isolated parts of what I'm saying.)

I've gotta say, I'm slightly surprised (in a good way). I mean, I figured people would just point out flaws and "boo" this one into oblivion (and while that's mostly what is happening, it's not to the extent that I imagined it would be).

Here are a few more thoughts (after digesting the responses and doing some thinking of my own):

(*) I think 0.1 is somewhere in the ballpark of a merit-to-post ratio that should be exceeded if someone's trying to grow their rank. I mean, I realize that not everyone can contribute at the same level, and so, I'm trying to find a ratio that I think most every person can hit without giving themselves a hernia (so to speak). If all I wanted was to drive up the forum's signal-to-noise ratio while not really considering where this might leave people who depend on the forum for some amount of their income, then I'd be tempted to set it much higher (like 1.5, which while 15 times greater than 0.1 and completely unrealistic-seeming to most, is still ~6 times lower than my own merit-to-post ratio). The problem with setting it too low (like 0.01, or something) is that we would then have complexified things in exchange for no real improvement to anything. If 1000 posts can be produced while only risking a backslide of 10 merits, then I predict very little will change by implementing this "carry" thing. But if writing 1000 unappreciated posts can end up costing you 100 merits, then that's genuinely behavior-affecting, IMO. As with everything Bitcoin(talk), I'm pro-freedom. As in, if you want to make 1000 posts that the community is effectively "telling you" (by not leaving you any merit) that they don't appreciate, then that's fine, and you should feel free to keep doing that. But, if for some reason that's the posting pattern that you've fallen into and you're still very concerned with maintaining or increasing your "rank", then something like what I'm proposing will encourage you to find a more community-appreciated way to spend your time on the forum. (And when you think about it, what kind of BS user is that, anyway? Someone who's at once saying "I have little to offer" and "I wish to be highly regarded"?)

(*) There would need to be some exemptions, I think. ChartBuddy should be able to post without building up "carry" (though, like LV said, probably the WO crowd would have been happy to keep CB fed with merits). Also, people should be able to post redirection topics without worrying about "carry". Maybe the "Serious discussion" and "Ivory Tower" boards should be exempted. That kind of thing. Because the "carry" database table would be event-style in the same sense that the "merit" database table is (as in, balances in either case are derived by summing over an adjustable record of events, rather than just being stored opaquely), I don't think it's very important to ahead-of-time think of every piece of special casing. Over time, cases can be made for specific things to be exempted (like maybe some of LV's data-dumping threads, for example), and even if those cases are only discovered after they've already caused unwarranted accumulation of "carry", it would be very easy to after-the-fact fix that with retroactive exemptions. (In general, though, if I were making the decisions, which I won't be, I'd lean toward "no" for most exemption requests. There's something very natural to me about letting merit decide whether or not the community appreciates something, and I struggle to think of clear examples of things that definitely should keep happening despite the fact that they don't/can't carry their own weight in terms of receiving merit.)

(*) It's natural for me to consider things in very abstract ways and to keep my mental "wavefunction" from collapsing around concrete details that aren't central to the "shape" of whatever it is that I'm thinking about. But, I know that that's not how everyone thinks, and some people prefer a style of thinking where concrete details dominate their analysis of something. In my experience, it's very frustrating trying to transmit ideas across an abstract-thinking vs. concrete-thinking "impedance mismatch". With the particular proposal in the OP, I've tried to "project" an abstract idea down onto the "concrete plane" so that it can be easily discussed. But, it's important to remember that many such "projections" exist, and there's no real value in picking apart just one of them (it's only really valuable when you've found a problem that would exist in every concrete projection of an abstract idea). Basically, what I'm saying is, I'm not very attached to any given detail in the OP, and I only really have a sense that something like what I've suggested could be made to work. For example, maybe it should instead work like: If you've received any amount of merit during the previous 14-day "activity" window, then all the posts you make in the current 14-day window won't attract any "carry" (all that that changes is the specific logic driving when the system does and doesn't generate a "carry transaction", but the scaffolding remains: a subtractive term in the rank calculation that's kept track of with an event-style database table).

(*) Back when rank used to be post-count-only, and things were adjusted to be based on "activity" (in June of 2013), many posters were all like "Why change this? FFS, I liked how it was before!". Then, when an additional term was introduced (in January of 2018), again, many posters were all like "Why change this? FFS, I liked how it was before!". So, it's inevitable, IMO, that any rank-hardening adjustment made at this point, even one that manages to "thread the needle" just so and long-term improve the forum's signal-to-noise ratio without causing too many casualties in that pursuit, will, at the time of its proposal or implementation, be met with some amount of, wait for it... "Why change this? FFS, I liked how it was before!"

So, back in the old days, "rank" ("Sr. Member", "Hero Member", etc.) used to be determined by your post count. To write that out in some symbolic form (that I'll iterate on as we go):


Using the "Hero Member" rank as an example, all you had to do in order to reach that rank was make 501 posts (posts that survive moderation and don't get deleted, that is). People could max out their rank in just a few days back then...

Spammers be like:

---

Then, the first major intervention took place, and rank determination became:


If you back-read Meta, you'll see that people really struggled at the time to understand what this "activity" thing was.

A precise definition of "activity" isn't important for this post, what's important is to understand it conceptually: It's a way to slow down the ranking-up process. To reach "Hero Member", you now need to write 480 posts spread out over 480 days. For the purpose of increasing your rank, there's no real point in posting more than once a day; technically, there's more to it than that, and you can make just a single post in a given 14-day "window" and then make 27 (14+13) posts in the next 14-day window and have your "activity" jump up accordingly, but, that's an implementation detail and shouldn't distract you from the central idea of an effective rank-wise 1-post-per-day speed limit.

Spammers be like:

---

Then, the second major intervention took place, and rank determination became:


Now things get really tricky for spammers, because even making 480 posts spread out over 480 days isn't sufficient to reach "Hero Member". You'll also need to accumulate roughly the same amount of "merit". The idea here is that some of your readership will award your substantive/appreciated contributions by marking those posts with "merit". In this "new era", you can't just rely on patience in order to rank up, you also have to try to post things that might be appreciated: If nobody finds value in what you have to say, then you'll never rank up...

Spammers be like:

---

We're now up-to-date, and I'd like to propose a third "intervention":


The idea here is that there's a new term called "carry" that will slowly de-rank you if you keep posting/doing things that nobody appreciates. That is, you can't just apply yourself to the task of achieving a given rank, you also have to apply yourself to the task of maintaining it. Just like your "merit" is a >=0 balance based on logged events, your "carry" is also a >=0 balance based on logged events. There's a more general version of this idea where different forum actions attract different amounts of "carry", but, the simple version that I think should be experimented with initially is just one where there's a single type of system-generated "carry transaction": Whenever you make a new post, your balance goes up by 0.1. In effect, you'll need to earn at least 1 merit for every 10 posts you write (on average) if you wish to prevent your account from slowly drifting toward a lower rank. And you'll need to get beyond a 0.1 merit-to-post ratio if you're aiming to increase your rank.

Spammers be like:

---

I think this would help with a few things (without impacting any even halfway-decent posters):

(*) It would slowly decay "airdropped" merits that either belong to accounts that have now changed hands or that were awarded in the first place to users that would have been unable to earn those merits organically. Basically, I'm thinking of accounts like mich (that account has only managed to earn 36 merits over thousands of posts, but it has the rank of "Legendary" and wears a paid signature). If an adjustment like what I'm proposing were put in place, then the person behind that account would have to re-think their whole approach to the forum (if they wanted to keep spamming their signature, that is).

(*) It would make it harder to buy/sell accounts. As in, sure, you could buy a "Legendary" account, but if you're going to just post mindlessly with it to make money, then eventually the "merit" that came with the account will be undone by the "carry" that accumulates each time you make a post. (And then, hopefully, the account will be considered worthless and can stop being traded.)

(*) It would make it harder to buy/sell merit. As in, sure, you could cheat by buying some, but, you'll likely have to do that repeatedly, because, as with the previous point, if you're just going to post mindlessly, then eventually the "merit" you bought will be undone by the "carry" that accumulates each time you make a post.

(*) It would encourage more mindful posting in general, I think. A small "cost" risked by the poster each time they submit something encourages them to ask "Do I really need to be posting this? Do I really think that people might appreciate it? Or is this likely to be a post that only contributes to me losing rank?".

I was previously against this sort of thing:


I guess, my view on this has changed over time, and I now think that the right amount of de-ranking "drift" can raise the forum's signal-to-noise ratio while only really frustrating accounts that nobody would miss. If you think about it, rank adjustments like the one I'm proposing shouldn't affect organic usage of the forum. As in, why would someone coming to Bitcointalk so that they can ask a question or post a scam accusation, for example, be put off by the idea of a subtractive term in the rank calculation? They wouldn't care one way or the other, IMO. I think the only users that might feel something like "No. This will ruin Bitcointalk!" are the users that view the forum as some kind of weird "writing job". (And while it'll always be the case that some amount of the user base will only ever be interested in what they can get rather than what they can give, at least with the proposed adjustment in place it'll also be the case that their chickens will eventually come home to roost unless they also throw in a merit-worthy post once in a while.)

Two final thoughts:

(*) I can't really say that I'm happy with the name "carry". Maybe someone else will have better luck than me with finding a good name for a subtractive term in the rank calculation.

(*) I don't think "carry" (or whatever it ends up being called) should be something that's displayed independently. In my mind, it'll affect the display of your merit balance. As in, if you have 100 merit and 5 carry, then your merit balance will appear as 95. (I guess, for display purposes, your merit balance should then be clamped to prevent it going negative. Otherwise, it'll be kind of demotivating for most new users to see their merit balance as "-1" after making their first 10 posts.)

(I haven't managed to state things exactly how I would have liked, but, my wife is shouting at me from across the house to come and eat, so, I'm going to stop fussing this post now and go get some chow.)

The WO thread is its own cool little universe. I don't know if there's a good way to balance (1) trying to control the volume of merit getting thrown around all willy-nilly, against (2) trying not to disturb the WO's whole "Fuck you! We do what we want!" thing...

One thought that must have come up over and over (I see DPD mentioned it a few posts up, but, I'm pretty sure that I've encountered it several times before) is to separate ordinary merit from "WO merit". I really like that idea, but, having a bunch of extra logic and presentation-wise stuff in place for just one thread seems like something that theymos wouldn't seriously consider doing. (I guess, a more general version of this idea would be to have board/topic based "merit weights". As in, if it's particularly easy to earn merit on Meta, for example, then merit earned there should be scaled down by some factor during balance calculation. Because all merit transactions are stored in the database individually, this idea could be applied retroactively, and I think I see a way for it to be done pretty efficiently, too.)

Another idea that I've been rolling around for a while now is to allow 0-merit sends. Sending someone "0" merits could be thought of as sending them a "like" (and, for example, instead of it displaying above a post as "LoyceV (0)", it could appear as "LoyceV (L)" or "LoyceV (+)", or something). I could see a "like system" based on 0-merit sends being very straightforward to implement (with maybe a one-click "+Like" button next to the "+Merit" button to make the whole thing feel more natural). I mean, that idea is worth pursuing all on its own, IMO, but, connecting it back to what we're talking about now: I wonder if the WO regulars would be very against the idea of their thread being made "like-only"? (If that's too heavy-handed, then maybe something that still allows for them to merit other regulars, but limits them to just 0-merit "likes" for new arrivals that haven't yet made 100 WO posts, or something. That way, WO regulars can form a substantial impression of someone before they dump actual merit on them. And, in the course of a merit-seeking spammer trying to cross that threshold, they'll hopefully end up on a few important ignore lists.)

There are a bunch of other "soft spots" on the forum that account farmers seem to rely on. It would be nice if it became a convention for certain kinds of threads to be marked by the creator as "like-only". In my view, you shouldn't be able to formulaically rank-up an account by carving a pumpkin, baking a pie, making a shitty pizza, and then repeating agreeable things on the WO. Off-topic, but, one thing I really miss is how selective DarkStar_ was when it came to assigning slots for the ChipMixer campaign. That campaign was pretty much the reason I joined Bitcointalk to begin with (in fact, I only fell into the whole SMF-patching thing because I was trying to get my merit-to-post ratio high enough for it to make sense for DarkStar_ to admit me as soon as I hit "Sr. Member"). Looking at Bitcointalk now, I don't think I'd join today... I used to get strong cypherpunk vibes from this place (even correcting for my naive view of the forum at the time). Now it feels like some kind of weird third-world school where the passing grade has been lowered over and over and all the "graduates" are idiots (I mean, I realize that that statement doesn't make much sense when you look back further and consider that rank used to depend only on post count, and then only on activity, before depending on merit, too. I'm just talking about the decline I've noticed during the 3 years that I've been paying attention).

Personally, I don't see a problem with what OP posted...

In my view, you shouldn't delete someone's opinion because it's "inflammatory" or "reads like a troll attempt".

I think that a troll-post should be defined as one which is trying to provoke conflict (compared to one which maybe succeeds in creating conflict but that wasn't written for conflict's sake). As in, it's not trolling when you're saying upsetting things (even often or habitually) that you believe to be true. It's only trolling when you're saying things that you don't believe to be true (while secretly hoping that saying those things will greatly annoy some person/group/demographic). The rule against trolling is about as difficult to enforce in a mistake-free way as a rule against scamming would be (they both amount to often requiring clairvoyance on the part of the moderators).

If OP wants to tell the members of his local board that he thinks they're being greedy, he should be allowed to do that (and while it's always nice when someone manages to frame their perspective in a respectful way, it shouldn't be a requirement).

This sort of moderation gets too close IMO to a modern controlled-speech community where the freedom to share your viewpoint only exists when you haven't tripped over any of a long list of subjective rules meant to attenuate anything that anyone might find offensive.

One last thought: I guess, there's also a class of troll-like behavior where you do believe that what you're saying is true, but you also know that none of it is really germane to anything, and the primary reason you're bringing it up is because you're working some kind of agenda/angle/vendetta. But, to me, that falls into the (more general) category of "ax-grinding", and not the (more specific) category of "trolling". Hmm... I just looked up a definition for "ax-grinding", and according to Merriam-Webster it's "working for an ulterior purpose or toward a selfish end". I can't say that I completely agree with that definition, and this isn't the point that I set out to make, but, I'll be a monkey's uncle if that entry doesn't describe just about all human activity.

When OP says "BITCOIN DOES NOT EVEN HAVE A MINING ALGORITHM THAT IS DESIGNED TO ADVANCE SCIENCE", I think what they mean is that they think it's a pity that the definition of Bitcoin's PoW scheme missed an opportunity to embed a niche computer engineering problem. They're saying that if the PoW scheme had been defined in just the right way, then it would have effectively caused any advancements in Bitcoin mining to also have been advancements in reversible computing. (OP even attempted such a thing here.)

I've gotta say, when I carefully read through OP's old posts, I get kind of emotional...

One of the (unrelated-seeming, but, bear with me) stories from recent memory that affected me most (as in, even now, ~7 years later, I get a lump in my throat just thinking about it) is the story of Terry A. Davis:



That dude was a programming legend. In fact, I don't think I've ever crossed paths with someone that I'm fully convinced can even understand just how talented he was (I mean, programmers, as a rule, tend to all think that they're something special, but, when measured on a scale that tops out with what Terry managed to pull off on his own, it's like he's turning out perfectly-set chocolate soufflés while most everyone else is stuck trying to microwave their turds, or something). Solo-programming complicated things (like, for example, a software-rasterized 3D engine) using only dependencies/libraries that you wrote yourself, to run on an operating system that you wrote yourself, all using a compiler that you wrote yourself for a C-like programming language that you designed yourself, is a feat that puts him in a group so small that anyone that figures they belong in that same group is almost certainly mistaken and very probably thinks that getting something like a homebrew Forth or Lisp environment to run on bare metal and then host a small VGA game is just about the size of it (it isn't).

The thing is, you'd never be able to see or say that about him if you graded what he did at face value. His work (TempleOS, I mean) was very difficult to take seriously and looked childishly stupid in many ways. What gave it the patina of amateurism was the fact that he had serious mental health issues (starting from around age 27 and eventually leading to him being homeless and then taking his own life at age 48). He came to believe that he was in direct communication with God (who gave him instructions, like never to implement SVGA, and to stick to a 16-color 640x480 video mode), and when he wasn't programming what he believed to be the Third Temple prophesied in the Bible, he was having manic episodes that would leave him in situations like having driven hundreds of miles to escape capture by the CIA before throwing his keys into the desert and dismantling his vehicle to look for tracking devices. That kind of thing. Toward the end, and for a long time leading up to it, it was impossible to follow WTF he was even talking about most of the time, but, if you engaged him in anything programming-related, he'd be completely lucid.

Anyway, I have no idea what's going on with OP. Maybe he's a troll, or maybe he really is who he says he is. I can't grade his work (I'm not a mathematician), and so I can't say where he might sit on the scale of giftedness. I also can't speak to his seemingly-obvious mental health issues (I'm not a psychiatrist), and so I can't say where he might sit on the scale of craziness. But, I do get some Terry-vibes from his posts (the religious/divine-justice stuff, the phrase-fixation, the repetitive incoherent nonsense, the lucid technical thoughts). With that in mind, my advice to everyone would be to pick between ignoring him or showing him kindness (I mean, that's good advice in general, I think, even though I often fail to apply it myself, and while I know it's difficult to do that when someone is being especially disruptive or saying unhinged things, in my experience, kindness goes a very long way, and there really is no point in trying to argue with someone who cannot perceive that they're playing chess with checkers pieces, so to speak).

Thanks for that, TSC. Gave me a good giggle. I've always enjoyed your turn of phrase.

I don't doubt it (both your talent for funny flame-crafting, and your desire for the forum to be more colorful personality-wise).

What makes me really appreciate your angrier posts is that I know you're a fundamentally kind and good-natured dude. I hope you don't mind me sharing the following anecdote about you, but, it's something that got me smiling heavily the other day: I remember you and I having a few conversations (maybe in 2023) and (for context: I'm quite pranky IRL and it's normal for me to goof around with the people I like) at some point I thought I spotted a good opportunity to tell you (in a completely deadpan way) that this song was the "power ballad" masterpiece that had gotten me through some tough times (I think I even asked you to listen to it carefully and keep an ear out for the wisdom it contains). Lol. Anyway, I remember being mightily impressed that you replied to that with a very kind-hearted response and managed to avoid saying anything at all negative about the song (but, be honest now, you had to be thinking: "Holy shit that's a terrible song, and to rate it so highly... PowerGlove must be a few fries short of a Happy Meal.")

Exactly. But, my fear (after watching my own family members and friends) is that people aren't really prepared to deal with much (or even any) inconvenience, and they'll continue to use whatever it is that they're already familiar with or that can otherwise get them where they're going without requiring too much thought on their end. I've basically stopped trying to convert friends and family because I've had very little success with it over the years (I've gotten pretty close once or twice with getting family members to turn their backs on Microsoft, Apple, Google, etc. but, it never seems to actually take). If I get one more call from friends or family asking me to unbork something for them after they've systematically ignored years and years of my advice, Imma say: "Yeah, well... That's the way she goes, buddy. The fuckin' way she goes."

Having said all that, it is getting seriously hard to find a sane computing environment, or to have anything even approaching real digital privacy, and here's a piece of a conversation I had about this a few months ago:

So much this.

Sorry to keep quoting things from the same source (in 3 of my last 4 posts; I'll give it a rest now), but your thought reminded me of the 77th footnote in that essay:

Yeah, but, that setting affects reception, not transmission. As in, if you disable e-mailed PM notifications, then the PMs you receive won't be duplicated over SMTP, but the PMs you send can still be.

Yup. That's kind of my point: If very few people have a genuine need (or at least, a deep appreciation) for the ability to be out-of-band sent HTML-stripped versions of the PMs they receive, then, I think the forum should take the message content itself out of any e-mailed PM notifications (for all the reasons I mentioned).

If it were up to me, I'd take out the subject, the sender, and the instant-reply link, too, but, I can't see getting a change like that past theymos.

Agreed. And it's something that I've considered doing more than once...

There are three stumbling blocks (that I can see):

(*) It would involve JavaScript and move Bitcointalk even further toward a state of not being able to work without scripting. (This doesn't bother me any, but, I'm aware that there are some no-JS folks out there that really bristle at being forced to enable browser scripting. I don't find their stance to be realistic, but, I can't say that I blame them for feeling the way that they do: Most programmers, and especially web developers, seem to have no problem with relying on a mutating nest of dependencies that they could never have written on their own, and therefore can't fully understand. You shouldn't accept a vouch from someone when it's about something that they don't understand. If you can't program a given thing from scratch, then you don't understand it.)

(*) It would break PM search. (But, I don't see this as a huge problem. When I originally made this topic, I was working on a filter-by-user patch for PMs. That patch slipped through the cracks and I forgot about it, but, I left it in a close-to-finished state, and if I finish it now and manage to convince theymos to merge it, then, I could see a lack of server-side PM search being much less annoying. Eventually, I could implement client-side search based on server-side user-filtering, but, its first-use/uncached bandwidth usage would depend on how many PMs you've sent to or received from that particular user. I've also got some ideas around re-basing the whole PM system on top of a rank-dependent amount of per-user API-accessible storage, and I could make something like that work really efficiently, but, those ideas are too involved to unpack here.)

(*) I forget the third point I was going to make. It was prolly good, though.

Anyway, when something gets complicated enough that I either can't see a way to very safely splice it into the existing software design, or I can see a way to do that but I expect it to be a huge uphill battle to get it merged, then, my energy wanes and I try to turn my attention back to very small improvements that don't leave much room for argument.

I think what a lot of people don't really understand about me is that I'm in a very particular "mode" when I'm on Bitcointalk: I very rarely suggest (or code) the things that I personally want, because I realize that the things I want are radical, and I don't have the energy to argue for them in what I perceive to be a very change-resistant environment (I don't only mean the user base; I'm also referring to theymos, because, ultimately, things come down to, or are at least very affected by, what he personally likes and dislikes). I don't begrudge theymos his iron grip on Bitcointalk, because I understand it, and my own grip would be at least as tight if I were in his position, but, it leaves me in a situation where I know that I'm not going to be able to get things over a certain complexity-limit or even with a certain flavor past him. Unfortunately, I also know that I'm not really built for the kind of work that I get to do for the forum, and so I'm almost certainly going to run out of interest at some point and move on to things that I actually find stimulating (or at least ideologically satisfying). So, I'm stuck with the problem of how to intelligently ration out my dwindling supply of energy so that I can get the most amount of "good" done while I'm still around to affect things (not only that, but, I also have to make my decisions as smartly as I can in the presence of a tech lead that seems to lean very heavily toward inaction, and a community that sometimes makes either the mistake of engaging in far too much wishful thinking given the status quo, or the mistake of encouraging inaction by discussing things to death, instead of just saying: "Yeah, that would be an improvement. +1").

Yup. That's the basis of that argument (not being signed-in). Like you, I have no need to read PMs without also being signed-in to Bitcointalk, but, like I said, I'm playing devil's advocate with all three of my arguments against implementing this change.

Yup. That came up in a private conversation I had a while ago about this. Like most of the diffs I share on the forum, my expectation is that theymos will re-imagine them in terms of his own source tree (as in, I can't see anything besides 1.1.19, so it's often the case that my diffs are "wrong", but, he knows that, and can account for it).

The first part of your proposal makes sense to me...

I'm struggling to follow your "reversed" idea, though. Maybe try giving me the ELI5 version.

Thanks, Chi.

---

Changing the subject abruptly, I may as well use this post to ask (the forum) a question that's been on my mind for a while now: Is anyone else bothered by SMF externalizing PMs? As in, does anyone else find it odd that, on the one hand, the highest bug bounty ($60K, currently) on Bitcointalk relates to PM privacy, but, on the other hand, and in the name of convenience, the PMs you send are likely being re-sent to some outside server that you almost always have no dependable details on? (As in, who is the PM recipient's mailbox provider? Are you OK with that provider's data-handling policy? Are you OK with their level of programming/security competence, along with their stance on privacy to begin with? Is it Microsoft? Is it Google? Are you OK with the contents of your correspondence, either now or in the future, being used to improve their services and train their models? And so on.)

I've been on-and-off thinking about this for a long time, but, what reminded me of it recently was reading the following (from a wonderful essay I bumped into while going over the WabiSabi paper):


I see three arguments against caring too much about this problem (all of which I can poke holes in, but, I'm playing devil's advocate here):

(a1) The forum is already man-in-the-middled (courtesy of Cloudflare, which is an obvious intelligence-gathering nexus), so, chances are good that the forum's PMs are being collected anyway.

(a2) People should be encrypting sensitive correspondence.

(a3) It's very convenient to be able to entirely read incoming PMs without having to be signed-in to Bitcointalk.

I guess, my counter-arguments go:

(c1) That's true, but, in my heart of hearts, I hope that theymos will eventually either find the energy himself, or develop enough trust in another networking-savvy programmer, to move the forum back to an in-house anti-DDoS system.

(c2) That's true, and it's what I do myself when something is really sensitive, but, I have a really hard time believing that most forum users know how to correctly do this and are disciplined enough to actually make themselves do it (especially for typical PM conversations, where no individual thing you're discussing is especially sensitive, but, taken as a whole, you'd still prefer the conversation to remain just between the communicating parties).

(c3) Is it, though? If you still received a notification by e-mail (with just the sender and subject of the PM, but without the actual message), would it really be so inconvenient if you couldn't read the whole PM right from your mailbox? (I mean, you'll have to use Bitcointalk anyway in order to reply to the message, so, what have you really gained by being able to quickly pre-read the PM? Isn't knowing who sent the message, and what it concerns, enough for you to go on until the next time you're signed-in?)

There's a really simple SMF patch that would prevent personal messages from being routinely transmitted outside of Bitcointalk's own system boundary:


Basically, e-mailed PM notifications would remain as-is, except that the "The message they sent you was:" part would no longer be included.

Is it only me, or, does it make sense to you, too, to take a convenience (experienced by some subset of PM-receiving users), and swap it for a very probable increase in privacy (experienced by basically every PM-sending user)?

Nicely put.

Allow me to quote from the 48-page essay that Phillip Rogaway wrote to accompany his 2015 IACR Distinguished Lecture:


The whole essay is really worth reading, IMO. (I recommend printing it out and setting aside enough time to sit down and consume it slowly, carefully, and contemplatively; I only say that because there's a tendency these days for people to blast through things as quickly as they're able to, and while that's OK when you're consuming hastily-produced or otherwise low-effort content, it's a real shame when you "save time" by only superficially digesting something that was put together with much care/thought.)

Yup.

No easy way, I'm afraid.

As I understand it, theymos disabled all but the default theme both as a security-related decision (to reduce the amount of attack surface), and as a maintenance-related decision (to reduce the number of files that need to be touched when fixing bugs and implementing new features). Given SMF's code architecture, I would have done exactly the same thing. It's hard to explain to the uninitiated, but, SMF's conception and implementation of "theming" is very backwards (to my way of thinking).

If I were designing things from scratch, I'd probably use many of the ideas I bumped into back when I was doing a lot of C++ GUI programming (in Qt, wxWidgets, and the like). Qt, as a toolkit, was really nice back in the day and contained a lot of good ideas (back when it was still being developed by a very small and very skilled team with a very clear vision; I'd say that that era started to end for them around the transition from Qt 3 to Qt 4, and things really started turning to mush after Nokia acquired Trolltech).

Anyway, long story short: I don't see a sensible (to me) way to do a theme/style system on SMF (as in, one that wouldn't involve a serious restructuring of the code). I forget who suggested it (maybe Cyrus), but, I guess a carefully-designed feature to let the user replace/extend the forum's CSS could be implemented (though, I have more than a few reservations about doing that, including that the markup isn't really optimized for it, and I've noticed that most people aren't nearly as concerned as I am about running browser extensions, so, they may as well then just install a style-management or user-scripting extension and adjust the forum's frontend that way).

I can't recall where my thinking trailed off the last time I considered this, but, I reckon it was with a hunch that 90% of the problem (from the perspective of users) could be solved by implementing a palette system rather than a full-blown theme system (as in, in Qt's terminology, thinking in terms of QPalette rather than QStyle). That's a much easier lift, and would manifest as a new section under "Look and Layout Preferences" where you could individually pick/adjust semantically-named color entries (and choose between a few completed presets to use either as-is or as a starting point for tweaking). Unfortunately, even something like a simplified palette system would be pretty awkward to successfully retrofit onto the forum's version of SMF (which is already near breaking point, and is a quagmire of sloppy code, half-developed ideas, abandoned disciplines, and difficult-to-reason-about cross-cutting concerns/effects).

This PM from last year still captures most of my position on working within the constraints set by SMF:

I'm not insinuating that anything like that was the motivation. I'm simply saying "Thanks" to the people I mentioned (I should have included TryNinja), and I'm pointing out that I often don't merit posts that I personally really appreciate.

---

@Cyrus: I'm still stop-and-start working on your nice link-sharing suggestion from a few pages back, and I have a suggestion of my own for your bta.lk project.

This ended up being a bit of a back-and-forth with theymos (who added some nice ideas), but, instead of re-hashing the whole thought process that we went through, I'll just share the summary:

Basically, using your suggestion post as an example, with your existing approach, its URL would be shortened to: bta.lk/t/5503118.msg65275936#msg65275936. But, by taking advantage of the asterisk-topic-ID patch I did in 2023, and by using a Base58-encoded message ID (plus a bit of arithmetic that I'll justify later), you could implement an approach that would allow it to be shortened to: bta.lk/CY7XN. (I mean, that's pretty cool, right? 12 characters instead of 40.)

How it would work is that you take the message ID (in this case: 65275936), then multiply it by 2 and add 1 (resulting in: 130551873). Then you encode that integer using Base58 (resulting in: CY7XN). Then, on your end, you set things up so that your server responds to URLs of the form: bta.lk/CY7XN, by first Base58-decoding the CY7XN part back into 130551873, and then checking that it's numerically odd before floor-dividing it by 2, which gets you all the way back to 65275936. Finally, you use that recovered message ID to do a 301 redirect to: https://bitcointalk.org/index.php?topic=*.msg65275936#msg65275936. (The multiplying/dividing by 2, and the adding/subtracting of 1 are details that have to do with keeping the scheme amenable to extension. In code, those steps don't appear in their arithmetical form, and are bitwise operations that are there to make sure that the least significant bit is set to 1 for message IDs. The least significant bit being unset is reserved for future use.)

To get this working on your end, the first step would be to add this PHP file to your document root:


I noticed this in your server's response:


I wrote and tested the above code on PHP 8.2 (but, I think it would run on 7.4, too). To get the above code working on PHP 5.6, you could try the below version (I haven't tested it, but, if you can't upgrade your PHP interpreter for some reason, then, you should try it and let me know if it doesn't work):


You'll know that you've got this step working when you can navigate to: https://bta.lk/link.php?id=CY7XN, and be redirected to: https://bitcointalk.org/index.php?topic=*.msg65275936#msg65275936.

The next and final step is to hide the link.php?id= part behind some URL rewriting.

I mocked this up a few different ways in my test environment...

On nginx, I got it working by adding the following line to the server section of the config:


On apache2, I got it working (after enabling mod_rewrite) by adding the following line to the VirtualHost section of the config:


I'm not sure what you'd have to do for LiteSpeed, which is what I see you're running, but, hopefully the above is enough for you to figure it out. (I'd take everything I've said about this URL-rewriting step with a large grain of salt: DYOR and all that; I can't remember the last time I put a web server into production that I didn't write myself, and I don't have the temperament to learn configuration syntax and struggle with an off-the-shelf tool when it's easier for me to just write an application-specific server in C++ and do everything in code. Basically, what I'm saying is: I don't employ this style of problem-solving when I can help it, so, probably someone more versed in HTTP server configuration can find fault with or otherwise add value to my URL-rewriting snippets.)

Anyway, in case it isn't clear, the whole idea here is that when I get around to finishing the link-sharing patch, this new kind of really compact shortlink is what I'd like to generate in addition to a normal Bitcointalk link. (And, in the meantime, I guess people could make use of it early by manually taking any message ID, multiplying it by 2 and adding 1, then using an online Base58 encoder to derive a working shortlink.)

"at least a little bit sad"? Wow. I didn't realize I was having that magnitude of effect on Bitcointalk. Haha. Nah, I know what you mean, and, the feeling is definitely mutual: I'd miss you, too.

---

@joker_josue, @Sandra_hakeem, @Cricktor, @nutildah, @Obim34: Thanks for the encouragement (and for bumping the patch thread). Please don't take me not leaving merit on your posts to mean that I don't appreciate them.

---

Yup, I saw that. It cheers me up. (And now my blood pressure can stop spiking when I see someone complaining about something that I've already fixed. At least, for this particular issue.)

---

@LoyceV: I'm sorry that this affected some of your data projects. Fix A wouldn't have (but, that would've caused old posts to render differently). I don't think it's possible (as in, CSS isn't powerful enough) to repair this bug in a history-preserving way without making some kind of change to the markup. Anyway, I hope I didn't create too much extra work for you. (Longer term, the forum really needs an API. It's very backwards that the frontend has to be disturbed as little as possible because of all the third-party projects built against it.)

I think you've run into the bug that this patch would fix.

(Hmm... I'm not sure what to think/feel about an obviously useful patch with 3 different approaches for theymos to pick from just sitting there and collecting dust for ~11 months. It hurts me a little, I guess. I have a lot of pent-up frustrations around what it's been like for me to work on these little forum improvements. I don't know... I keep circling the thought that I'm not a good fit for Bitcointalk, and that I'm clearly swimming against the current, and I should take the hint and find a more productive endeavor.)

Nice one. I'll likely work on that (at some point).

What's going on there is that Symmetrick edited the subject into the Unicode character U+3164 ("Hangul Filler"). I quickly parsed the UCD XML file (for Unicode 16.0.0) and found ~406 other characters that will cause that same kind of (browser dependent) nothing-to-click problem. This is more of a note to myself than to you, but, to prevent that kind of "blank" subject from being possible in the first place, I suppose I should write a stripInvisible function (to filter out those ~407 "default ignorable" characters) along with a beefed-up trim function (to gobble up all ~25 kinds of whitespace from both ends of a string). That way, blank-but-not-empty subjects won't sneak past the minimum-length check. Probably, almost all of the ~65 Unicode control characters have no business being in subjects, either. I'm not sure about the ~170 formatting characters (though, I think ~138 of those would be caught anyway by the hypothetical stripInvisible function).

Hmm... I just tired myself out thinking about how I'm going to shoehorn all of that (or its whitelist inverse) into SMF's strange and inconsistent text-handling story; Imma rest my eyes for just a minute, m'kay?

---

About the interesting discussion on the previous page: I have thoughts, but, as usual, they're complicated, and it will take time for me to try to distill them into something readable...

I guess, one thought that I'm ready to share now is that I don't see how someone could be for self-moderated threads but against merit-restricted threads. As in, if you resent the idea that the thread-starter should have the power to limit merit-sending, then you should really resent the idea that the thread-starter should have the power to limit discussion.

I recently found this post by OgNasty (who I think is just about the biggest plonker that I've ever bumped into, but, even grade-A dingleberries occasionally have good thoughts):


If it were up to me, I think I'd get rid of the self-moderation feature completely, but, failing that, I think something like what OgNasty is suggesting makes a lot of sense...

I think what I'd do is adjust the self-moderation notice from currently looking like this (and only being at the top of the page):



To looking like this (and being at the bottom of the page, too):



(The important change is that the "44 posts" part is now a link which will take you to a view of the deleted posts.)

There's also this idea from suchmoon:


I agree with that... I too can't think of a good reason to allow a self-moderating topic-starter to delete another user's posts a long time after they were written. (Unless, maybe, the topic-starter has returned after a long break from the forum, or something. I guess, accounting for that would be simple enough, but, it's the kind of band-aid-on-band-aid logic that quickly leads me back around to thinking that the whole self-moderation feature should never have been implemented in the first place. In fact, if it didn't currently exist, and it only now came up as a new suggestion in this thread, I'm pretty sure that almost everyone would hiss at the idea.)

Don't be like that, dude. It's all good...

Probably you only meant to say "Thanks" to the people that voted for you, but, try to see things from a zoomed-out point of view. Imagine if every participant (in this competition and others) got into the habit of sending merit as a "Thanks" to the people that voted for them. I mean, that would get out of hand pretty quickly, no? People that really struggle to rank-up by making high-quality contributions would make sure to vote in every competition that they could find...

Also, it's kind of unsportsmanlike, isn't it? I would never want to win anything by encouraging people to vote for me. I'd want to win "clean" (even if all my competitors were trying everything that they could think of to tip the scales in their favor).

(Having said all that, one thing where I myself am pretty unsportsmanlike, at least according to others, is with deathmatch first-person shooters: I basically stopped playing them because everyone else thinks it's bullshit that I sometimes "camp" and feel comfortable staying out of view for long periods of time. Most people can't have fun like that, and resent the fact that I can outwait them, and I've myself gotten into heated arguments about how it's not against the rules, but, yeah... I don't like irritating people, even when I think that I'm in the right, so I changed my playstyle, and still lit them up nine ways to Sunday, haha, but, I really, really don't enjoy being in overly-prescriptive environments, so, I just stopped playing, except occasionally with close friends.)

Maybe this one isn't as not-known as I think (I've only ever seen it used on a handful of old posts), but, if you post while in ;wap2 mode (or ;imode, too, I think) then you'll get a different "message icon" than any of the 12 that you can ordinarily [1] pick from (I posted this message in that way, so, you should see the "wireless.gif" icon to the left of this post's subject and date/time).

[1] I'm aware of "moved.gif" and "recycled.gif", and I'm aware that there are some extra message icons on the "Important Announcements" board. I'm just referring to the 12 that you typically get to pick from.

Yeah, that one's easy to forget about. It's worth noting that (with the right delimiter) you can get PHP code-coloring with [code][/code] tags, too:


BTW, here's a (I think) complete list of the 59 BBCode tags that the parser recognizes (it's an alphabetical arrangement of the 57 tag names that I found within SMF 1.1.19's parse_bbc function, plus the [btc] tag which came from theymos, and the [nbsp] tag which came from me):


(From the above list, I think only flash, html, and move are disabled: they are recognized, but, they emit inert stand-ins.)

(Adding new BBCode tags isn't as difficult as it might seem, so if anyone has any good ideas for useful ones, feel free to leave them in my thread.)

That's the numeric entity reference for a non-breaking space. I don't know why entity references (and other inconsistencies) show up sometimes during preview. Between theymos' version of SMF being different to mine, and either version being approximately the same bug-harboring contraption, I probably wouldn't be able to get to the bottom of it without sinking something stupid like 2 or 3 days into figuring it out.

Hmm... I've never noticed that before, but, it makes sense to me now that I consider it (what's happening is that the undo history of the textarea is being cleared/reset each time its contents are changed programmatically: when you insert something into a post/PM by using the toolbar, then either an SMF-provided JavaScript function named replaceText or one named surroundText is invoked, and, in either case, the textarea gets modified in such a way that the undo history is wiped; though, strictly speaking, I'm only considering the non-IE paths, and so maybe undo/redo did actually work correctly back in the day on Internet Explorer, but, that's neither here nor there).
 
I can.




(Between the three different ways that I can think of to fix this, I think the above way makes the most sense in the context of the existing code. It's not perfect, but, it's much lighter than trying to spoof input events or maintain a non-native undo history, and, if the deprecated interface that it relies on does actually get removed at some point, then the logic will just more-or-less return to the state that it's currently in.)

(I'm not going to bug theymos with a PM about this one, so, hopefully he bumps into this post naturally. I didn't test this change very carefully, because that's always the most time-consuming part of the process, and it doesn't make much sense for me to allocate a huge block of time to doing cross-browser testing for a proposed change that theymos might never even see, let alone merge. If he merges it and it turns out that I've overlooked something, like maybe selection-preservation not working exactly how it used to, then the change can be undone and I'll attempt to revise/improve it at that point.)