No Link For You! (anti-spam)

[Master_Cylinder]

In your proposal, it's true that there would be no need for a new group, but you would need to go type the number of posts required to post links into the groups you wanted to limit. (Presumably it would default to zero, meaning anybody could do it.)

Certain groups, I would assume, would default to 0 (which would mean never allow) and most groups would leave the field blank (optionally a check box with "always allowed to post links"), which would mean always allow. What it looks like isn't important, radio buttons, check boxes, drop down or just the text field; the options needed are "always allow," "always deny" or "allow after X."

On a stock forum, with my proposed defaults, if you wanted to change the number of posts before posting URLS you would only need to change 1 group, "Registered users." If the RU group defaults to "blank" then the ability to post links would be exactly as it is now on a stock .12 install. If the RU group defaulted to 1 then only the first post couldn't have links which also seems reasonable for a less spammy phpBB default.

Now consider that another user wants a new feature -- the ability to not allow PMing for a number of posts (phpBB.com actually has this limit, I believe, set to 5). That means another counter in the Group wide settings section, changing the ACP to accommodate that counter and changing the code to check for it.

Now suppose that another user wants ability to limit linking to images for a number of posts. That means another counter in the Group wide settings section, changing the ACP to accommodate that counter and changing the code to check for it.

Now suppose that another user wants ability to limit posting Flash for a number of posts. That means another counter in the Group wide settings section, changing the ACP to accommodate that counter and changing the code to check for it.

Do you see where this is going?

Of course I do but this isn't an Auto Groups RFC, I get that you want auto groups for the flexibility to change *many* things based on post count but that doesn't mean that swapping users in and out of groups for *every* option is the right way to do it. Some things, like post character limits, pm folder sizes, self-editing/deleting times, anti-spam URL post limits, etc might be better served with a group wide setting than swapping users in and out of a special group based on post count. Maybe I'm wrong but I think that more user/group settings in the ACP would be far better than a ton of groups and the extra load *that* would entail.

With Auto Groups, you'd have two new Group wide settings counters -- Posts required to join group and Posts required to exit group -- and you'd create the group using existing permissions. Newly Registered Users would be 0 and whatever you set now. Most other groups would probably be the limit that you wanted to enter and zero to exit (meaning you don't exit).

Doesn't that sound simpler in the long run?

I use auto groups (wish I didn't need to), that's basically how it works in the MOD; min/max/0=not auto.

If *you're* looking for a one size fits all solution it might be simpler in the long run but, as I said above, swapping users in and out of special groups might not the be best way to handle every option.

It's "one size fits all" in the sense that you're only handling the problem for one limit. Auto Groups makes it easy to limit the number of posts for any permissions that the admin chooses, not just the specific one that you may want right now.

Like above, auto groups is the one size fits all solution but I don't think swapping every member in and out of a special group for each variable is the right way. Sounds heavy.

Remember that it's not necessarily about what's easier to implement for one specific request; it's also about making things extensible for the future. As I hope I've demonstrated, Auto Groups is more extensible.

How is all of the group swapping and possible additional conflicting permissions better than a simple group wide setting? No need for a new group, no database writes for each group and each member. You're probably only going to change this anti-spam setting for one group unless you add a lot of custom groups for other things anyway and the default to blank or 0 (whichever makes you feel better) should cover custom groups until you can tweak those.

If it makes you feel better, I supported an auto groups based idea in the community forum but I don't think it's the right way to go for *every* option...and not this one. I think group wide settings/options would be better for many variables.

[Pony99CA]

In your proposal, it's true that there would be no need for a new group, but you would need to go type the number of posts required to post links into the groups you wanted to limit. (Presumably it would default to zero, meaning anybody could do it.)

Certain groups, I would assume, would default to 0 (which would mean never allow) and most groups would leave the field blank (optionally a check box with "always allowed to post links"), which would mean always allow. What it looks like isn't important, radio buttons, check boxes, drop down or just the text field; the options needed are "always allow," "always deny" or "allow after X."

Are you going to have a Can post URLs permission? If so, you don't need "Always allow", "Always deny" and "Allow after X". Always Allow would Yes for the Can post URLs permission and zero for the number of posts (you can start using URLs immediately); Always Deny would be Never for the Can post URLs permission, and Allow After X would be Yes for Can post URLs permission and X for the post count.

Now consider that another user wants a new feature -- the ability to not allow PMing for a number of posts (phpBB.com actually has this limit, I believe, set to 5). That means another counter in the Group wide settings section, changing the ACP to accommodate that counter and changing the code to check for it.

Now suppose that another user wants ability to limit linking to images for a number of posts. That means another counter in the Group wide settings section, changing the ACP to accommodate that counter and changing the code to check for it.

Now suppose that another user wants ability to limit posting Flash for a number of posts. That means another counter in the Group wide settings section, changing the ACP to accommodate that counter and changing the code to check for it.

Do you see where this is going?

Of course I do but this isn't an Auto Groups RFC, I get that you want auto groups for the flexibility to change *many* things based on post count but that doesn't mean that swapping users in and out of groups for *every* option is the right way to do it. Some things, like post character limits, pm folder sizes, self-editing/deleting times, anti-spam URL post limits, etc might be better served with a group wide setting than swapping users in and out of a special group based on post count. Maybe I'm wrong but I think that more user/group settings in the ACP would be far better than a ton of groups and the extra load *that* would entail.

First, it doesn't matter if this is an Auto Groups RFC or not. It's for proposing methods for preventing users from posting links. Your proposal does this, my proposal does this. Mine is just more extensible and supports many other possibilities beyond posting links.

Second, both methods allow specifying post counts for things. Yours is more explicit about what the post count controls, mine controls what groups the user is in based on post count and uses the phpBB permission system to decide what people in that group can do or not do. The problem with yours is that every time somebody wants a new post-count-based permission, the developers have to add it to the core or somebody has to write an extension to support it. With Auto Groups, once that's written, you're done!

Third, I agree that times, sizes, character coutns, etc. wouldn't work for Auto Groups, and are better suited for Group wide settings, but that's because they aren't really meant to be dynamic. Things like post counts and days since joining the board would be perfect for Auto Groups. And, with Auto Groups, getting "promoted" to a new group based on a good criterion could allow posts with more characters or more PMs in a folder. (But, again, I'm not promoting Auto Groups for the sake of having them; I think they allow for a much more flexible and and extensible solution to this problem than your proposal does.)

Finally, you have a fair point about load -- while the user doesn't have to swap people in and out of groups, the system has to check which groups a user belongs based on post count, which could create more load. That's a question for the developers.

With Auto Groups, you'd have two new Group wide settings counters -- Posts required to join group and Posts required to exit group -- and you'd create the group using existing permissions. Newly Registered Users would be 0 and whatever you set now. Most other groups would probably be the limit that you wanted to enter and zero to exit (meaning you don't exit).

Doesn't that sound simpler in the long run?

I use auto groups (wish I didn't need to), that's basically how it works in the MOD; min/max/0=not auto.

If *you're* looking for a one size fits all solution it might be simpler in the long run but, as I said above, swapping users in and out of special groups might not the be best way to handle every option.

It's perfect for handling standard phpBB permisson-based options (Yes/No/Never), though. One size truly does it all here.

It's "one size fits all" in the sense that you're only handling the problem for one limit. Auto Groups makes it easy to limit the number of posts for any permissions that the admin chooses, not just the specific one that you may want right now.

Like above, auto groups is the one size fits all solution but I don't think swapping every member in and out of a special group for each variable is the right way. Sounds heavy.

Let's not use "swapping", which sounds like the Admin has to do it (which he doesn't -- that's the point of Auto Groups). Determining which groups the user is in is done at run-time more in my proposal, hence my agreeing that load might be an issue.

However, you may not have to have a separate group for each "variable" (or option). If you want several features to turn on with one post, you only need one group (you can use the Newly Registered Users group for now). If you want several other features to turn on after more posts, you can just define one group for that. You'd only need one group per option in my proposal if each option had a different post count from all of the other options.

In your method, you'd need one Group wide settings counter for each item regardless of whether or not the post counts were the same or different. That can get heavy, too, I'd think.

One more thing. You mentioned conflicting permissions. I agree that your proposal would probably be easier for new users to understand. Mine requires a decent knowledge of how phpBB permissions work, which can confuse new users. However, once they get permissions, mine will be much more flexible in the long run.

Steve

[Master_Cylinder]

In your proposal, it's true that there would be no need for a new group, but you would need to go type the number of posts required to post links into the groups you wanted to limit. (Presumably it would default to zero, meaning anybody could do it.)

Certain groups, I would assume, would default to 0 (which would mean never allow) and most groups would leave the field blank (optionally a check box with "always allowed to post links"), which would mean always allow. What it looks like isn't important, radio buttons, check boxes, drop down or just the text field; the options needed are "always allow," "always deny" or "allow after X."

Are you going to have a Can post URLs permission? If so, you don't need "Always allow", "Always deny" and "Allow after X". Always Allow would Yes for the Can post URLs permission and zero for the number of posts (you can start using URLs immediately); Always Deny would be Never for the Can post URLs permission, and Allow After X would be Yes for Can post URLs permission and X for the post count.

You *could* use a yes/no/never permission too but it's not needed since you'd still need a place to type a number, you could handle the whole thing in the group wide settings (see my earlier screenshot) instead. So, if you have to use the group wide setting block anyway, then skip the yes/no/never group and use radio buttons, check boxes, drop downs or even just the text field and use blank/0/1-9999 or whatever. Like I said, I don't care what it looks like, whatever would fit in the current design scheme.

First, it doesn't matter if this is an Auto Groups RFC or not. It's for proposing methods for preventing users from posting links. Your proposal does this, my proposal does this. Mine is just more extensible and supports many other possibilities beyond posting links.

Second, both methods allow specifying post counts for things. Yours is more explicit about what the post count controls, mine controls what groups the user is in based on post count and uses the phpBB permission system to decide what people in that group can do or not do. The problem with yours is that every time somebody wants a new post-count-based permission, the developers have to add it to the core or somebody has to write an extension to support it. With Auto Groups, once that's written, you're done!

Third, I agree that times, sizes, character coutns, etc. wouldn't work for Auto Groups, and are better suited for Group wide settings, but that's because they aren't really meant to be dynamic. Things like post counts and days since joining the board would be perfect for Auto Groups. And, with Auto Groups, getting "promoted" to a new group based on a good criterion could allow posts with more characters or more PMs in a folder. (But, again, I'm not promoting Auto Groups for the sake of having them; I think they allow for a much more flexible and and extensible solution to this problem than your proposal does.)

Finally, you have a fair point about load -- while the user doesn't have to swap people in and out of groups, the system has to check which groups a user belongs based on post count, which could create more load. That's a question for the developers.

First, it does matter since we don't even know if auto groups is going to be in the core. My proposal works without it, with a simple field added to the group wide settings. Let's not torpedo my idea by requiring another piece (AG) that may *not* get approved in order for my idea to work.

Second, yes, and with AG you also have to swap people in and out of groups which could get pretty extensive and expensive.

Third, while this is post count related, there is still no need to swap people in and out of a group to achieve it. The lighter solution should be used for this anti-spam issue.

Finally, load is *not* a small issue with using AG and, yes, when a member hits a certain post count he can be removed from one group and added to another, and again when the next post goal is reached. Swapping in and out of groups seems accurate although I guess some admins might stack groups and have members in 1000 different groups, which is again, more load. Load is why a setting for this is better than a special group.

It's perfect for handling standard phpBB permisson-based options (Yes/No/Never), though. One size truly does it all here.

Not everything is solved with yes/no/never and, as above, we don't even need those for this to work.

Let's not use "swapping", which sounds like the Admin has to do it (which he doesn't -- that's the point of Auto Groups). Determining which groups the user is in is done at run-time more in my proposal, hence my agreeing that load might be an issue.

Swapping is accurate since members are moved in and out of groups based on post counts. That it's done by cron or during checks at post time/login time just adds to the load and, again, that's why it's not good for every option. Why a group for this? So they can have different ranks and avatars for x posts? C'mon, a group for this is a waste.

However, you may not have to have a separate group for each "variable" (or option). If you want several features to turn on with one post, you only need one group (you can use the Newly Registered Users group for now). If you want several other features to turn on after more posts, you can just define one group for that. You'd only need one group per option in my proposal if each option had a different post count from all of the other options.

In your method, you'd need one Group wide settings counter for each item regardless of whether or not the post counts were the same or different. That can get heavy, too, I'd think.

I doubt there's much weight for GWS options other than the few bits it takes up in php file to display them compared to the load from all of the db writes from changing groups more often. Some things make sense with y/n/N, some things make sense for auto groups and something make sense for GWS. I think this one should be GWS.

One more thing. You mentioned conflicting permissions. I agree that your proposal would probably be easier for new users to understand. Mine requires a decent knowledge of how phpBB permissions work, which can confuse new users. However, once they get permissions, mine will be much more flexible in the long run.

Perhaps...but at the cost of bloat and load. I'd rather have pages and pages of options in the ACP than the cost on the server.

[Pony99CA]

First, it doesn't matter if this is an Auto Groups RFC or not. It's for proposing methods for preventing users from posting links. Your proposal does this, my proposal does this. Mine is just more extensible and supports many other possibilities beyond posting links.

First, it does matter since we don't even know if auto groups is going to be in the core. My proposal works without it, with a simple field added to the group wide settings. Let's not torpedo my idea by requiring another piece (AG) that may *not* get approved in order for my idea to work.

Auto Groups could be implemented as part of this RFC, not as a dependency. That's a call for the developers to make. RFCs generally present a functional view of how things will work, not a development spec. So, in that respect, it doesn't matter.

Second, both methods allow specifying post counts for things. Yours is more explicit about what the post count controls, mine controls what groups the user is in based on post count and uses the phpBB permission system to decide what people in that group can do or not do. The problem with yours is that every time somebody wants a new post-count-based permission, the developers have to add it to the core or somebody has to write an extension to support it. With Auto Groups, once that's written, you're done!

Second, yes, and with AG you also have to swap people in and out of groups which could get pretty extensive and expensive.

That's why I don't like the term "swap" here (or at least the way that you use it). You (the Admin) don't have to swap people in and out of groups. You set the post counts for group membership and the code determines which group the user is in.

Also, any swapping is only done when the user hits a post count limit (although every post will require those limits to be checked, of course, even if no swapping is done).

But that already happens today with the Newly Registered Users group. In fact, the NRU group is really just a kludgy subset of Auto Groups. I wish the developers had implemented Auto Groups back then as a way of implementing the NRU group, which would have also given us the capability to do exactly what I'm asking for. If they had generalized the solution back then, you may not have even needed to start this RFC....

Third, I agree that times, sizes, character coutns, etc. wouldn't work for Auto Groups, and are better suited for Group wide settings, but that's because they aren't really meant to be dynamic. Things like post counts and days since joining the board would be perfect for Auto Groups. And, with Auto Groups, getting "promoted" to a new group based on a good criterion could allow posts with more characters or more PMs in a folder. (But, again, I'm not promoting Auto Groups for the sake of having them; I think they allow for a much more flexible and and extensible solution to this problem than your proposal does.)

Third, while this is post count related, there is still no need to swap people in and out of a group to achieve it. The lighter solution should be used for this anti-spam issue.

We disagree. As I said, it's a developer's call whether Auto Groups would be too heavy.

If you don't want more load, though, you should probably stick to phpBB 3.0; phpBB 3.1 is already adding lots of load from the posts that I've seen.

Finally, you have a fair point about load -- while the user doesn't have to swap people in and out of groups, the system has to check which groups a user belongs based on post count, which could create more load. That's a question for the developers.

Finally, load is *not* a small issue with using AG[....]

I didn't say that it was a "small issue", so why the emphasis? Did you benchmark a solution with and without Auto Groups and you're using the emphasis to show that Auto Groups is very expensive? If you have, let's see the numbers; otherwise please don't make that claim.

It's perfect for handling standard phpBB permisson-based options (Yes/No/Never), though. One size truly does it all here.

Not everything is solved with yes/no/never and, as above, we don't even need those for this to work.

Not for your suggestion to work. We do need it for mine.

And what happens when somebody wants to make an existing permission (like Can use Flash) based on post-count? Then you'd have two places for that permission. I suppose that you could set the permission to Yes and then the Group Wide Setting to the post count, but that's not very elegant.

Let's not use "swapping", which sounds like the Admin has to do it (which he doesn't -- that's the point of Auto Groups). Determining which groups the user is in is done at run-time more in my proposal, hence my agreeing that load might be an issue.

Swapping is accurate since members are moved in and out of groups based on post counts. That it's done by cron or during checks at post time/login time just adds to the load and, again, that's why it's not good for every option. Why a group for this? So they can have different ranks and avatars for x posts? C'mon, a group for this is a waste.

I could argue that a Group Wide Setting is a waste in many cases. If we had a Can use links permission, that could be set to Never for the Newly Registered Users group and Yes for the Registered Users group. Then the post count to exit the NRU group would allow people to post links. With that "solution", no Group Wide Setting is needed nor is any new group needed. And that may be sufficient for most users.

The only time that doesn't work is if the Admin wants different post counts for the NRU group and the ability to post links. Then we're back to this discussion.

However, you may not have to have a separate group for each "variable" (or option). If you want several features to turn on with one post, you only need one group (you can use the Newly Registered Users group for now). If you want several other features to turn on after more posts, you can just define one group for that. You'd only need one group per option in my proposal if each option had a different post count from all of the other options.

In your method, you'd need one Group wide settings counter for each item regardless of whether or not the post counts were the same or different. That can get heavy, too, I'd think.

I doubt there's much weight for GWS options other than the few bits it takes up in php file to display them compared to the load from all of the db writes from changing groups more often. Some things make sense with y/n/N, some things make sense for auto groups and something make sense for GWS. I think this one should be GWS.

Every time the user wants to post a link, there will have to be a database read of the Group Wide Settings value (unless that's cached). That's load.

Oh, and what happens in the case when the Admin sets Group A to have a link post count of 10 and Group B to have a link post count of 20 and then assigns a user to both Group A and Group B? What post count applies then -- the maximum, the minimum or the value on the user's default group? (That's a rhetoric question, but you can see that it could be confusing. It must already be addressed for things like the Group private message limit per folder Group Wide Setting, but I wonder if the correct answer would match what you expect.)

One more thing. You mentioned conflicting permissions. I agree that your proposal would probably be easier for new users to understand. Mine requires a decent knowledge of how phpBB permissions work, which can confuse new users. However, once they get permissions, mine will be much more flexible in the long run.

Perhaps...but at the cost of bloat and load. I'd rather have pages and pages of options in the ACP than the cost on the server.

People already complain about the complexity of the ACP, and you want potentially pages of more options rather than even a little (and I'm not saying that Auto Groups would only be a little, mind you) extra load? I may potentially be bloating the run-time load, but you're potentially bloating the user interface. Servers get faster every year, memory gets cheaper every year, so heavy load this year may not be heavy next year. User's don't get much smarter every year.

Plus, you still haven't addressed the development cost of adding new post-count-based permissions. With Auto Groups, they come along for free. With your suggestion, somebody has to implement each one, either a developer in core code or a MODder as an extension. That means an Admin who wants a specific post-count-based permission has to either develop it himself or wait for somebody else to do it. In my opinion, the flexibility and extensibility of Auto Groups justifies at least some load. How much is a developer's call, of course.

Anyway, I don't think that I'll convince you of the rightness of my solution and you obviously haven't convinced me of the benefits of yours, so how about we agree to disagree and see what other users prefer? Maybe a developer could even chime in with their opinions on load and development time.

Steve

[Master_Cylinder]

Auto Groups could be implemented as part of this RFC, not as a dependency. That's a call for the developers to make. RFCs generally present a functional view of how things will work, not a development spec. So, in that respect, it doesn't matter.

OK, let's leave the auto group vs ACP setting/option decision to those that have to approve it and maintain it. If others come up with other options or "tweaks" they can post those but we're going nowhere on the AG vs GWS debate for this idea.

That's why I don't like the term "swap" here (or at least the way that you use it). You (the Admin) don't have to swap people in and out of groups. You set the post counts for group membership and the code determines which group the user is in.

Also, any swapping is only done when the user hits a post count limit (although every post will require those limits to be checked, of course, even if no swapping is done).

But that already happens today with the Newly Registered Users group. In fact, the NRU group is really just a kludgy subset of Auto Groups. I wish the developers had implemented Auto Groups back then as a way of implementing the NRU group, which would have also given us the capability to do exactly what I'm asking for. If they had generalized the solution back then, you may not have even needed to start this RFC....

Like it or not, it does swap users out of the group(s). You = your server.

I can imagine the abuse of auto groups as some admins create thousands of groups all with conflicting permissions.

We disagree. As I said, it's a developer's call whether Auto Groups would be too heavy.

Why is it a dev call when you want it to be and not when you don't?

If you don't want more load, though, you should probably stick to phpBB 3.0; phpBB 3.1 is already adding lots of load from the posts that I've seen.

Really? If I prefer a lighter solution for *this* so my server can't "hang" with the next version? Is that where we're going now?

I didn't say that it was a "small issue", so why the emphasis? Did you benchmark a solution with and without Auto Groups and you're using the emphasis to show that Auto Groups is very expensive? If you have, let's see the numbers; otherwise please don't make that claim.

I emphasized it because it's important. C'mon... Every member, in and out of at least one (at least 2 if using the NRU) group, with all of the extra load vs a setting in the ACP with decent defaults? I think that will *probably* be lighter, don't you? Is this one that were leaving to the devs? If they want to bench it both ways, so be it, but I can guess.

And what happens when somebody wants to make an existing permission (like Can use Flash) based on post-count? Then you'd have two places for that permission. I suppose that you could set the permission to Yes and then the Group Wide Setting to the post count, but that's not very elegant.

I thought we were leaving that up to the devs? As you said, it's less confusing, the ACP has never been very elegant. Perhaps a more elegant "anti-spam" block for all of the new anti-spam settings to go into?

I could argue that a Group Wide Setting is a waste in many cases. If we had a Can use links permission, that could be set to Never for the Newly Registered Users group and Yes for the Registered Users group. Then the post count to exit the NRU group would allow people to post links. With that "solution", no Group Wide Setting is needed nor is any new group needed. And that may be sufficient for most users.

The only time that doesn't work is if the Admin wants different post counts for the NRU group and the ability to post links. Then we're back to this discussion.

Of course many will want a different post count for the NRU group than the Registered users group, especially if NRU is set to never. NRU defaults to 3, are you going to change the NRU group so users have to be moderated for 10-50 posts to keep them from posting links? Of course not. If you have RU set to "yes" then after 3 posts the member would be able to post links and that's what we have, right now, without AG or without GWS. The RU group would be the only one changed much, aside from custom groups added later and most of those will default to either never or always, instead of a number.

Every time the user wants to post a link, there will have to be a database read of the Group Wide Settings value (unless that's cached). That's load.

Oh, and what happens in the case when the Admin sets Group A to have a link post count of 10 and Group B to have a link post count of 20 and then assigns a user to both Group A and Group B? What post count applies then -- the maximum, the minimum or the value on the user's default group? (That's a rhetoric question, but you can see that it could be confusing. It must already be addressed for things like the Group private message limit per folder Group Wide Setting, but I wonder if the correct answer would match what you expect.)

Reads are lighter than writes.

That can happen with AG too...let me guess. We'll leave that to the devs too?
I did think of an example where AG+another anti-spam MOD would be lighter on the server than than MOD itself but that's going to another RFC. This one I think should be a group wide setting.

People already complain about the complexity of the ACP, and you want potentially pages of more options rather than even a little (and I'm not saying that Auto Groups would only be a little, mind you) extra load? I may potentially be bloating the run-time load, but you're potentially bloating the user interface. Servers get faster every year, memory gets cheaper every year, so heavy load this year may not be heavy next year. User's don't get much smarter every year.

Plus, you still haven't addressed the development cost of adding new post-count-based permissions. With Auto Groups, they come along for free. With your suggestion, somebody has to implement each one, either a developer in core code or a MODder as an extension. That means an Admin who wants a specific post-count-based permission has to either develop it himself or wait for somebody else to do it. In my opinion, the flexibility and extensibility of Auto Groups justifies at least some load. How much is a developer's call, of course.

Anyway, I don't think that I'll convince you of the rightness of my solution and you obviously haven't convinced me of the benefits of yours, so how about we agree to disagree and see what other users prefer? Maybe a developer could even chime in with their opinions on load and development time.

It would be far more complex dealing with ALL of the settings for multiple groups than it would be to set one setting in the GWS for each group, imho. I know, we're leaving it to the devs.

What's the cost of adding an option in the ACP? Less than AG.

Yeah, like I said on top; we're going nowhere. You'll not convince me nor me you, so perhaps we can agree that it should be done and let the devs decides how that would be done best, based on load and every other option they have to consider.

I wish the devs would chime in though.

[EXreaction]

These are extremely long discussions; more people are likely to comment to something shorter and simpler. Just for fun, at the default settings, I see printing this single page in this topic for me would result in 16 pages worth of paper. In the amount of time it would take to read and respond to this topic, I could probably merge several pull requests and fix a bug or two.

[MattF]

I had a super busy forum on a super popular website (hundreds of thousands of posts, tens of thousands of members, 10 years running). The issue proposed by this thread never was an issue for me. Maybe once a year, somebody would join for the sole purpose of posting spam links.

Easy solution: Make an extension that offers the functionality requested here.

[Danielx64]

These are extremely long discussions; more people are likely to comment to something shorter and simpler. Just for fun, at the default settings, I see printing this single page in this topic for me would result in 16 pages worth of paper. In the amount of time it would take to read and respond to this topic, I could probably merge several pull requests and fix a bug or two.

What about some of the other topics that are longer?

[DavidIQ]

To me the whole "Auto Groups" discussion sure sounds like the events system proposed some time ago, I believe by Pony...

[Mess]

What about some of the other topics that are longer?

The same applies?

These are extremely long discussions; more people are likely to comment to something shorter and simpler.