Well, I think he's smoking something but in the meantime let's analyse the comments.
The software must be written in PHP or C++, as these are the only two languages I am very familiar with. The code must be extremely easy to modify. I want to be able to make even complex changes in behavior without much trouble.
Not really possible. Every complex change will cause trouble in whatever you do.
The software can be under any license as long as I have complete access to the code forever, I can modify the code, and I will not be required to publish private modifications I make to the code (no AGPL). It can be based on paid software if the cost of the license is reflected in your price.
It would be fine for you to sell your software after you make it for this forum.
I firmly agree on the no AGPL part. That licence is even worse than GPL.
PostgreSQL is greatly preferred. Queries should be well-optimized. Do not use a database abstraction layer.
That assumes, of course, that everything else is going to be reworked for PostgreSQL. SMF and Wedge's structure will still require massive overhauls.
It also depends on what you call an 'abstraction layer'. What SMF has is an abstraction layer. What Wedge has is less of an abstraction layer but still by definition an abstraction layer.
Database queries should wherever possible be done using prepared statements, something like pg_query_params, or some other method that doesn't require the programmer to manually escape things inline.
Well, SMF 2.0 and Wedge do this.
Security is very important. Your code should have a "generally secure architecture": it should be very difficult for a programmer to mistakenly introduce security flaws.
I'd argue that SMF and Wedge's general structure is generally secure. But I won't argue with the premise that the way input handling is done is somewhat insecure.
Use salted multi-iteration hashing for passwords using one of the SHA-2 algorithms. Passwords in the existing SHA-1 format need to be automatically upgraded once the user logs in again.
As I've said before I'm not entirely convinced that multi-iteration hashing is entirely necessary, especially as it weakens entropy. But the password upgrading is easy to do in SMF/Wedge.
No user group should be able to run arbitrary PHP code.
That lets out running a portal mod, then, heh. But neither SMF nor Wedge allow this.
All actions must be done by POSTing the server. GET requests must not have side-effects.
Marking things read will be interesting then as will a few other trivialities.
The default theme should be minimalistic like the current theme. Nothing that looks "web 2.0": no speech bubbles, no significant space between posts, no significant hover effects, and few rounded corners.
I guess that's why he hasn't updated to SMF 2.0.
Admin settings that are not changed very often can be made changeable from files instead of from a web interface, though changing the settings from the files should be easy. The web interface must not allow admins to add/edit UIs, execute arbitrary code/SQL, or tamper with logging.
I can agree with this, actually. I've never been much of a fan of certain admin interfaces.
- Admins, with all powers. Only group capable of seeing IP addresses. It must be possible for admins to make certain groups, certain posts, and certain topics immune to certain types of moderation.
- Global mods, capable of doing everything with posts and posters.
- Local mods, capable of doing everything with posts and posters in their sections. Posters banned by a local mod are only banned in the sections that the local mod has jurisdiction over.
- Jr. mods, who can only moderate posters that are not established.
- Established posters: all posters who have met some easily-configurable criteria. To start with, the criteria will be 8 weighted hours online (see below for info on weighted stats).
- Categorizers: Can move all topics
- Whitelisted: immune from proxy bans, and maybe other restrictions later
- VIP donator: capable of accessing the donator section, able to change his name, and able to assign himself a custom title
- Donator+: capable of accessing the donator section and able to change his name
- Donator: capable of accessing the donator section
- Scammer: Unable to delete or modify his own profile or messages. Has his posts and PMs marked specially.
A lot of that is straight permissions. The rest is mostly general housekeeping that is not a significant amount of work.
These user groups will be hidden and not listed in a user's profile or next to his posts:
- Local mods (when outside of their sections)
- Jr. Mods
- Established posters
- Categorizers
- Whitelisted
- Donator
In addition to the pips ("stars") that most forums have, small image and text "badges" associated with some membergroups should be possible.
Certain groups (including some poster ranks) imply "whitelisted".
Easy enough group configuration.
There needs to be "weighted time online" and "weighted post count" in addition to the raw values. It should not be possible for a user to increase one of the weighted values by too much without increasing the other value. If you post 200 posts in 1 hour, your weighted post count should be 1. If you post 1 post in 200 hours, your weighted time online should 6 hours. These numbers should be configurable and should apply retroactively when changed (where possible).
Time online should not increase if you're simply refreshing a page, and it should increase more slowly if you seem to be a bot.
That won't work well whatever you're doing.
All actions that write to the database should have at least one associated configurable limit. Like "can post x topics per y seconds". There should also be a limit that prevents users from posting too soon after being stopped by another limit. It should also be easily possible for admins to ban certain regex expressions in posts, titles, and usernames (separate ban lists) from the web interface.
The limits may be modified based on membergroup. The actual limits may be relaxed, and the result of exceeding the limit may also change. Exceeding limits can do nothing, reject the action ("you may not post this topic because you just posted one 5 minutes ago!"), or automatically ban the user.
SMF already has internal handling for this, however it will have to be improved for what they're after.
When a guest tries to post a reply, he will be asked for the necessary account creation info (username and password) on the same page where he can enter his reply.
Email addresses will not be required on registration. However, the board will not send email to the user until an email address is provided and verified.
A user's very first post must not be a new topic.
The email handling is a lot more complex than what SMF normally asks for though it is certainly possible to do. To me, though, it implies that there is a risk attached to that software, in keeping with why I steer well clear of Bitcoins generally. (I mean, what good is a currency you can generate by burning CPU cycles and little more and that it's easier to steal than a conventional bank account is to break.)
It should be possible to use OpenID authentication instead of a password. The main login method should not be OpenID, though. Maybe entering an OpenID URL into the username or password field will trigger OpenID authentication.
OpenID URLs should not be used as real usernames.
Well, SMF 2.0 has that.
...bah, too bored to read any more. Lots of talk about forum specific tweaks that are probably not as effective as he thinks they will be. I won't disagree that the way SMF and Wedge handle GET/POST data is not ideal but I'm not yet sure what I want to do that's better.
