[snip]

Okay, so now that we've established that you did indeed mean "basic", please provide answers to all of the following: - If a user has interacted with you before you blocked them, and then you block them, how should this affect the Clickback list of both the blocking user and the blocked user? - If a user has blocked another user, but then finds an Egg from the Shelter bred by the blocked user, should they be able to see it? Adopt it? What about its timeline? - If a user blocks another user, it is fairly trivial to prevent most interactions just by blocking access to the Profile and Summary pages. However, it would not be feasible to block forum posts (as doing so can lead to crucial loss of context in a thread). This means the [pkmnpanel] cannot be blocked, and so interactions would be possible through there. How would you resolve this, bearing in mind that Interactions are already the most server-stressful feature of the site and adding more checks onto them is a Bad Idea™? - Should a blocked user be able to buy items from the Marketboard put up for sale by the user who blocked them? Or vice versa? - Should Wonder Trades be able to randomly pair you up with a user you have blocked? If not, additional checks will need to be added that could potentially result in Wonder Trades remaining unmatched, or worse it keeps trying to match you with the blocked user and never resolves. Since Wonder Trades can't be cancelled either, there's no way out of such a loop. - Some users may want blocking to result in the blocked user effectively "disappearing" from their gameplay experience. How would you reconcile this with the fact that Tournaments have a leaderboard with a limited number of places? - Same question for Pokérus. How would you handle someone wanting to hunt for Pokérus, only to find that a person they blocked currently has it? Remember they can't interact with them if they've blocked them. I could go on, but these are the questions that must be answered before a block feature can be added to this multiplayer game.

I had to step away because I was getting... frustrated, I must admit. However, I think that was due to me not communicating my side of things well enough, so for that I must apologise to Mandibuzzard. I would like to try again and make things clearer. There are two issues at play here: 1. Site performance. As you may have noticed, the site already suffers from occasional lag spikes that refuse any attempt to diagnose or fix. It's something that's been a real thorn in my side. Or Lego brick under my foot. There are about 5k users who visited the site in the last 24 hours. That's a total of about 12.5 million possible inter-person links. Of those, I would estimate that maybe a few hundred to a thousand blocks would be made. After all, most people either get along just fine, or are content to ignore each other. Even if I generously round up the number of blocks, you're still looking at less than 0.01% of potential inter-person links being blocked. For such a tiny fraction, it is absolutely not reasonable to add extra database lookups to the Shelter page, for example. The Shelter is highly optimised to work the way it currently does, and adding a "block check" to that would slow it down by several orders of magnitude. All of that, for a less than 0.01% incidence. Similar logic applies to other parts. On the other hand, blocking the Profile page is super easy, barely an inconvenience. This is what I mean when I say it's about compromise. 2. Game mechanics. PFQ is a game where every user is massively inter-connected with every other user. Most features involve interaction with other players in some form. Every single one of them will need to be tweaked to account for possible blocks. Many of them can probably be "fixed" by just anonymising the blocked user's name. ***** can work quite well because that's what we already use for censoring inappropriate usernames, so technically you don't know if it's a blocked user on the Timeline, or just someone who named themselves something rude. That's a good idea. What I might be able to do is add a filter to the Clickback list, such that blocked users won't appear on it - but they can still interact with you. That way you can benefit from their interactions, without even being aware of it and without the need to reciprocate. However, this may need some kind of limitation on it to keep things reasonable performance-wise. There may need to be a cap on how many people you can block, just to ensure it doesn't become a performance issue again, but that cap should easily be higher than anything you'll actually need. In any case, my "push-back" here is really just to try and drill down and get at what people want from this feature. "A block feature would be nice," sure, but figuring out exactly what it'd be used for will help with implementation details later. EDIT: To add an example of why a limit would be needed to prevent performance issues. There was a person who accidentally crashed the site every time they logged on. Eventually I figured out that they were subscribed to over 1,000 threads and had been offline for a long time, so there were many, many new posts and the system was trying to notify them of it. But that involved loading the usernames of the people who had posted. That was too much, and the server ground to a halt. That's why your forum subscriptions are limited now.

re: lag Blocking won't have as much of an impact on the site as you think, D33R, specifically because we are likely not going to add the most lag-inducing aspects such as Shelter filtering (re: making sure you don't encounter eggs bred by a blocked user). Asking Sally to check all 40 eggs for their OTs every time you refresh would just be too much especially given that the Shelter is an already resource-intensive feature. This has pretty much been deemed too lag-inducing for not enough benefit to be practical. There's already less than a 1% chance you'll run into an egg hatched by someone you've blocked simply due to the sheer number of eggs in the Shelter. That's why "but the lag" is largely a non-point -- it's simply unlikely that this or other major lag-causers would be added to the block feature due to this exact concern. Those features would need to provide a benefit that is applicable to enough people and/or in enough instances to be worth it vs the server system's resources used or otherwise occupied by those processes. So, please do not use lag as a reason to not support this. Niet can make things work and will do whatever is possible to minimize the impact it has on the site in terms of lag. Don't worry about the implementation of it, and just stick to the pros and cons of the block feature itself and the features that you would like to see accompanying it.

Not editing this into my previous post since I want it to push a notif to anyone subbed. I'd really appreciate it if y'all took the time to read this! As a foreword, some things I'm going to say here are going to be in response to specific users and other things will be points I'm just bringing up because they need attention. I'm not quoting those users because this post is already long enough as it is and I believe I managed to make the point well enough without needing the context of those posts. Please let me know if that's not the case and I'll figure out... something.

---

There seems to be a widespread assumption that this is a simple thing that can just be done. As someone who's sat in call and watched Niet code in real time, he is better at this especially in the present day than he's given due credit for. While I said don't worry too much about things like lag, there are still things we have to keep in mind, also in regards to lag itself. Don't allow "lag" to be a prohibitive point that causes you to oppose this suggestion. Just remember that the features of the site stack on top of each other, intersect at different places, and branch off in other ways. This is true of a lot of complex coding projects. It's not even really a tree anymore, it's a straight up spiderweb simply due to the extent of it, where different parts rejoin and branch off again somewhere else down the line. Now, in terms of adding a block feature to this spiderweb, it's like adding roadblocks. You find a point in the spiderweb where you're like "I want this to no longer be an option for people who are blocked," but then you have to consider the likely many ways they can get around that via other paths in the web. This ties back to something I said previously that I would like to clarify. Any process Sally does will cause some amount of "lag" in that it simply takes some measure of time in order to complete. Whether that amount of time is efficient, negligible enough to be acceptable, and/or worth it for the benefit that is gained determines whether or not it's particularly "laggy" for the server or just par for the course, even if that time is measured in fractions of a second or even fractions of a millisecond. They add up quickly and become several seconds in total, enough to be noticeable, when Sally has to do a lot of searches and cross-referencing, such as for keeping track of which part of the spiderweb you're at, whether or not there is a roadblock, and the conditions that that roadblock imposes. This is in addition to everything Sally already does. The main intent of staff joining in this thread and trying to help it along was to request specific assistance in figuring out the conditions the roadblocks should have, trying to find a compromise between the "hard block where the blocked person(s) don't exist in my user experience at all" ideal and the reality of the situation where Sally can't take that amount of stress and we have to aim for a "soft block where the blocked person(s) still exist but where certain restrictions are imposed." There's also still ongoing evaluation on whether or not this is at all possible given what PFQ is and whether or not this is a feature that would have to be put exclusively on "PFNew" (affectionate nickname). If at all, mind. We're trying to meet with you guys somewhere in the middle but we want help finding where that point is. To that end, I'd like to request that we refocus on the suggestion itself and especially in answering Niet's concerns in his two posts starting here. I understand that some discussion has occurred on these points, but ultimately this is where the focus is further needed. If you understand the concerns Niet posed here, what are your own ideas for solutions to it? Given that a block is not a report, then either blocks need to be accompanied by a report through the block function itself or via the usual reporting process. This has basically been established, and the mock-up for this looked pretty nice. There's some questions, though. At what points should the initial block be allowed to go through fully automated and at what points should the block require Moderator attention? Should Moderators have to fully review every block request as we review and act on reports or approve Clans to ensure people aren't being nasty, or should we only review for certain reasons/causes? Are you opposed to the suggestion entirely for reasons not yet stated? If so, why? You do actually already have the autonomy and power to "block" users if you wish. You can use the features of browsers such as Google Chrome in order to "block" users by preventing the page from loading if it is a specific URL, such as a specific user page or specific PM conversation. This would not block the user on multi-profile or click lists, and the other user would still be visible in the forums, but this option is available to anyone who seeks these specific options. I'd also like to point on that blocking someone actually doesn't do really anything to de-escalate the situation (except perhaps in cases where that is your only point of contact), and in fact often serves to exacerbate the issue by allowing it to move off-site. This isn't victim-blaming, mind, it's just the truth about how some particularly nasty folks on the receiving end of a block may choose to act. It's also the reason why we would prefer, for example, child predator concerns be reported as early as possible - it's less so "it's your fault if they move on to harass someone else," and more so "we would prefer to stop this as soon as possible so that doing this to someone else is not an option that the offender has." We want there to be less victims of child predators, harassment, bullying, thefts, and so on, so we request that you report any concerning instances immediately. It has been noted that DNI for "Do Not Interact" seems to be a popular acronym in this thread and I've seen it on Trainer Cards in the recent past, but I would like to firmly request everyone discontinue the use of this acronym and instead use DNC for "Do Not Contact." As a Moderator who has had to enforce DNCs and had to tell people that I cannot enforce DNIs, I'll explain why. Due to the in-game mechanic of clicking being called "making interactions" and the fact there is an entire page of the site called the Interactions page (or "Today's Interactions" if you go by the header of the page), the concept of DNI itself becomes unclear. Are you asking for them not to contact you in any way (PMs, trade threads, etc.), or are you just asking them not to click your Pokemon? Given that Site Rule 2A says that people can click however they want and due to the unclearness of DNI as a concept for the aforementioned reason, I cannot enforce a DNI given that not everyone will understand this caveat. I know it seems a bit pedantic but please, please say DNC instead. As an addendum to this, non-personal DNCs such as in TCs are unenforceable because there's no guarantee someone will see it - please use the PM function to make Do Not Contact requests. Remember to keep them polite. Moving on from that, someone brought up the laws on discrimination. To clarify on these laws, in both in America as well as in the UK, you cannot deny service based on discriminatory reasons (race, sex, sexual orientation, religion or beliefs even including political beliefs

eg. you can't bar them because they're a conservative, liberal, democrat, tory, etc.

, etc.). If you have a non-discriminatory reason, you can deny service. If you wish to deny service and provide no reasoning for it, you can do so. However, if your reason comes to light and it's discriminatory, you can be sued and held liable in the UK. Anyone remember the gay Colorado couple who just wanted to order a cake and got refused service? That's illegal in Colorado, much like it would have been illegal if it had happened in the UK. We operate fairly similarly on PFQ since we go by UK law - it's not exactly the same though. You can refuse service in your Trade Shops and threads to whomever you like and for whatever reason you like, just keep the reasoning to yourself or at least address it respectfully in private. DNCs aren't much different. You can request that someone never contact you again in any way and not provide a reason. They are obligated to comply, else they face consequences per the rules on general respect (Rule 2B). Anyone breaking a DNC should be reported - the only response you should ever receive to a DNC is the other person's acknowledgement that they see and/or accept it. Nothing else.

---

I'll leave the thread locked while I sleep tonight to give folks time to read this so it doesn't get flooded out, and then I'll unlock the thread in the morning. Edit: Apologies for the late unlock; today got a bit hectic. Please feel free to continue the discussion. Be kind to each other. 🙂

Hello everyone! Now that we're unlocked, let's refocus back on what we want out of a block feature. Since it's tentatively confirmed that the block feature is going through, let's not worry ourselves too much with who wants and who doesn't want a block feature. Let's just work together to make sure this feature fits everyone's needs best. You are still welcome to voice your opinion if you do not want a block feature, but I'd request that we keep the discussion away from these things and just leave posts about not wanting a block feature alone.

---

---

As a reminder, here are some of the main points that the mods asked us to focus on and discuss. ( + Cele's post about lag, since it's still relevant to the conversation.) You can see all the important mod posts in the first post of this thread, as there are more.

---

---

And now, this is the part where I have questions! These are directed towards staff -- please do not answer these questions for staff. 1.) Is this feature actually confirmed? We've had two instances of mentioning that the staff "doesn't need convincing" of this feature, but no offical statements about this feature going in. 1a.) If this feature is confirmed, could we be moved to the approved features section? 1b.) If this feature is confirmed, would it be possible for us to get a link to this thread somewhere in the news? I know this is asking a lot (and potentially inviting more discourse), but I feel like it's worth it to get more opinions from members who typically do not check the suggestions, or wouldn't otherwise be aware of this feature coming into existence. 2.) As far as I can tell, all of the talking points in Niet & Cele's posts have been answered at least two or three times. Do you want more discussion from other players on these points, or do you have other points for us to talk about? I suppose that wasn't as many questions as I thought I had, but hopefully these questions being answered will provide me & other members some peace of mind & clarity.

I just want to drop in and say that we did have an approved version of a block feature before but we couldn't figure out how to implement it - aside from some interactive issues (which we can now deal with) there was the question of exactly what it is we want a block to do - but moreover that a block feature of any kind should NOT function as a disconnect for reports. But it's also not a report. It's... Complicated. We have a generic idea but for the most part those are our issues. We don't want it to lead to no reports so we can actually deal with things (such as the fellow that we learned was placed on probation for his actions). I will say that our active role in this is probably the most important thing... We've been so active in dealing with these things but I wish I could say the same for the police and even the FBI. We were so adamant to report such issues that at one point we were given Interpol's phone number. Interpol is NOT a number civilians are supposed to have! That's a number for international police forces to talk to one another and we're... Well, not police. And we were told as much when they asked us to identify ourselves. That was admittedly a little bit scary. Honestly the fact we got that number is a little bit alarming - either someone screwed up and just did the wrong thing or they plain and simple didn't know what to do... My point with that being that if they won't, or can't for whatever reason, do something - we definitely have to. This is why we can't have that disconnect. If we can resolve that problem then a block feature is no longer an issue and can be implemented post-haste.