The forum's software has proven to be insufficient for our needs. In particular, the general architecture of the code is both insecure and difficult to modify, and the moderation facilities are limited. Therefore, the forum is accepting bids for the job of delivering software that meets the requirements listed below.
I don't care whether you build the software from scratch or just create a bunch of modifications for some already-existing software. There are benefits and drawbacks to both methods which will be considered in relation to the rest of your bid.
Bids should include at least this info:
- A description of the general architecture you plan
- A list of any of the optional features I mentioned that your software will have
- Additional features your software will have that I didn't mention
- Samples of your past code
- A price. If you want links or other "perks", include these as part of the price.
The forum has about
650 760 920 1120 1720 2267 3000 5500 BTC on hand at this moment, but you can bid more than that. If your bid is the best, I'll just wait until the forum has collected the required amount of money.
I will consider offers that only have ~95% of the "required features" listed below, as long as you're delivering a usable product. For example, you don't
need to use my preferred programming languages. It's also OK for you to deliver an incomplete (but working and stable) product quickly and then add onto the software after it's being used.
You can't bid on just one aspect such as design or programming. You need to deliver a complete product.
This thread is only for bids, questions from bidders about the specifications, and questions that I have for bidders. Other discussion about this process should go in a separate topic.
Requirements:
Overview of problems with SMFSMF is very good when viewed from the outside. I like the GUI's look, it has many useful features, and it's fast. However, the code is absolutely terrible. It was clearly written by people who don't have a good understanding of security or coding style. Examples:
- Many of the high-level functions like RemoveTopic can only be used in one place because of the assumptions they make, but the lower-level functions (removeTopics for RemoveTopic) omit important stuff like security checks. When doing anything complex with SMF, I often find myself copy/pasting high-level functions except for a few modified lines.
- Even the low-level functions sometimes misbehave when used outside of their intended area by, for example, printing errors. There's often no way of handling errors yourself without hacks.
- The coding style mostly sucks. The conditional operator is used too much. There's confusing stuff like
if(!empty($enabled)).
- A lot of data is cached, but it's difficult to know when cached data is available and where this data is located when it is available. The user's profile data might be in $context['user'], $user_info, elsewhere, or it might not be available yet.
- SMF does crazy stuff like scanning binary attachments for "suspicious strings" (like
<?php) in the name of "security".
- Many limits and security restrictions can be bypassed easily by exploiting quirks in the code. There are many easy denial-of-service attacks.
- Logic is tied very closely to presentation.
- Pretty much every SMF modification is buggy in some way or other because modification authors are usually amateurs and because SMF's code is so difficult to deal with.
- Database inconsistency can happen accidentally.
Ideally, what I'd like to get from this project is software very similar to SMF on the outside (similar features, fast, etc.), but with code that is clear and secure, plus a few extra features that SMF doesn't have (mostly moderation-related) listed below.
SMF featuresAll of the popular SMF features should be supported by your software. For example:
- Ignore user
- Ignore board
- Email notifications
- Print pages
- Profile pages
- BBCode
- Polls
- Multi-level subsections
- PMs
- Context search, simple search, and advanced search
- "Unread posts since last visit" and "new replies to your post"
- Forum and user stats
- Avatars
- Various user settings
- Good Unicode support
- JavaScript quick edit
The extensive admin interface is
not required, however.
CodeI prefer that the software be written in PHP, C++, or Java, as I have the most experience with these three languages. The code must be clean and easy to modify. I want to be able to make even complex changes in behavior without much trouble.
LicenseThe 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.
DatabasePostgreSQL is
greatly preferred. Queries should be well-optimized. I'm not a fan of database abstraction layers.
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.
SecuritySecurity is very important. Your code should have a "generally secure architecture": it should be very difficult for a programmer to mistakenly introduce security flaws.
Use the hashing scheme
described here. Passwords need to be automatically upgraded when CRYPT_PARAMS is changed. Legacy SHA-1 passwords ( sha1(password concatenated with lowercase username) ) also need to be upgraded.
No user group should be able to run arbitrary code. SMF and other forum software allow admins to run arbitrary PHP code via modifications or themes. This isn't OK; if you use such forum software as a base for your software, you'll need to disable this feature and replace it with some other method of updating modifications/themes/etc.
All actions must be done by POSTing the server. GET requests must not have side-effects.
UIThe 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.
The default theme must work well with all functionality and a reasonable page layout on text browsers without JavaScript. It should also work perfectly on browsers with unusually small browser dimensions. It should be at least somewhat usable (though maybe not pretty) on ancient and broken browsers like IE6.
Same color scheme as we have now: light with some blue.
There should be functionality for allowing users to choose from among several UIs. You only need to provide the default one, though.
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.
User classesSo that you know the sort of membergroup system that is needed, here are the currently-planned membergroups. All of these must be possible with your software. People can belong to more than one membergroup. These will certainly be tweaked a lot in the future, so don't hard-code the membergroup features/permissions.
- 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.
There should also be "poster ranking" groups based on weighted stats.
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".
Weighted statsThere 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.
LimitsAll 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.
RegistrationWhen 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.
OpenIDIt 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.
Mod profile viewMods will see this stuff on the front page of every user's profile:
- A log of everything the user has done in the last few weeks. Entries like "Reported post x", "Posted reply x", "Posted topic x", "Got post x deleted by mod y", "Got banned by mod y", etc.
- The user's recent deleted posts.
- Their last few topics and posts (in different lists)
- Links that will immediately carry out mod actions after a JavaScript prompt: ban, IP ban, whitelist, elevate
Mod actionsPost actions:
- Delete topics/replies
- Split topics
- Merge topics (admin only)
- Clone reply/topic (admin only -- maybe other groups later)
- Create redirect topic
- Move topic
- Edit post
- Lock topic
- Sticky topic
- Announce topic -- put it at the top of every topic index page (admin only)
Automatic poster actions:
- Ban -- automatically permaban poster
- IP ban -- permaban poster and ban for an admin-configurable number of days all IPs the poster has used. Stats should be available to admins about how many times certain IPs and IP ranges are banned in this way.
- Whitelist/unwhitelist -- put the poster in the whitelisted group
- Elevate/unelevate -- Put the poster at the top of the report queue and make all mods do an extra confirm step for any action against this poster. Intended for things that need admin review. This feature is optional.
- Comment -- private mod comments about posters. This feature is optional.
- Nuke -- Deletes all posts.
- Remove reports on the poster
Admins should also be able to create user/IP bans that expire after different amounts of time.
No bans will prevent people from reading posts.
There needs to be something like SMF's "quick moderation" interface on topic pages and user post histories.
All of a poster's deleted posts should be available to them for at least a month.
It should be very easy for admins to undo any damage caused by mods. In particular, it should be very easy to undelete topics/posts and restore them to their original states.
Optional: make it possible to perfectly undo every action of a particular mod since a specified point in time.
ReportsPeople can send reports by clicking "report" links next to posts and optionally filling in a report reason. This increases the report score on the post and the poster by the reporter's "reliability score". The reliability score starts at 1. For each correct report, it increases by 0.1. For each incorrect report, it decreases by 0.02. The reliability score maxes at 5, and it can't go below 0.
Mods who view the report queue will only see users they can deal with. It should be arranged like this:
Poster 1 -- score: 5 -- details/handled/incorrect links
post a -- score: 3 -- details/handled/incorrect links
post b -- score: 2 -- details/handled/incorrect links
Poster 2 -- score: 1 -- details/handled/incorrect links
post c -- score: 1 -- details/handled/incorrect links
The links work like this:
- Details: Lists the actual reports along with the reasons and sender of the reports
- Handled: Removes the reports and increases the reliability scores of all those who sent the reports
- Incorrect: Removes the reports and decreases the reliability scores of all those who sent the reports
Removed reports remain available to admins from a link on the sender and recipient profile pages forever.
Stock PMsWhenever a mod action is taken against a user, they should receive a stock PM informing them of this. It should be easy for me to customize the text for each PM.
Ban appealsPeople who have their user account banned (but not their IP) can use a special ban appeal feature. Each user can appeal once, and then they need to wait for the response.
The appeal queue will be available to admins. It will show the appeal and a link to the user's profile page. It'll have these action links: unban, reply, soft-deny (allow another ban appeal in 14 days), hard-deny (never allow future appeals for this user).
After any action is taken, the appeal is removed from the queue.
The banned user can reply once to each reply that an admin sends.
Proxy banningThere will exist a large list of proxies that are banned from posting except for whitelisted posters. The list should support IPs/hostnames with wildcards and ranges. Checking users against this list should be efficient. I will write code for automatically adding Tor exit nodes to this list, so it should be especially easy to add to this list.
When someone is prevented from posting something due to a proxy ban, the thing they tried to post should be added to a list visible to mods. Mods can then look through the list and whitelist people who tried to post something good.
Proxy-banned people should also be able to manually request whitelisting. The whitelist request queue should be visible to global mods, jr. mods, and admins.
WatchlistThe watchlist feature should be available.
No embedded imagesDue to problems with "cookie stuffing" and other attacks, let's just disallow embedded images all together. Transform old embedded images into links. Avatars will still be allowed, but they will always be hosted by the server.
Keep allowing img tags (transforming them into links), as they might be used later.
Other required features- Tags, as
described here. "Tag mashups" are required. A separate report feature for tags and "ignore topic" are optional.
- Whenever you click "preview" when composing a post or PM, a draft of your post should be saved. These drafts should be available for 7 days.
- Good SEO
- Combined mod action log
- Ability of admins to send PM/Email newsletters to different membergroups.
- A page listing all posts by non-established posters
- Post edit revisions visible to all users who can edit the post
- A way to view all of a user's topics
- The bidder needs to provide code or detailed instructions on how to move current database data to the new database.
- The software needs to be at least as fast and resource-light as SMF.
- I like how the SMF post composition page allows you to highlight text and then click a button to apply certain BBCode. This needs to be replicated.
- Post counts should not be shown on topic pages, but should be shown on profile pages.
Other optional features- A trust system exactly like that of Freenet's FMS would be excellent. Bids including this will be greatly preferred.
- Optional CAPTCHA-protected email addresses listed on profiles
- Nofollow on links in posts and profiles of non-established users
while they are non-established- In addition to normal BBCode, allow Wiki-syntax for bold/italic: ''=italic, '''=bold
- In "Replies to your posts", highlight posts where you're quoted and include posts where you're quoted even if you haven't posted in those topics.
- The ability to completely ignore a thread.
- A "thanks" feature on posts. All people who have thanked a post (up to a limit) are listed in small text near the post. Readers can hide this list in their options.
- An option that expands [img] tags into embedded images. This must not be the default.
- In addition to the default way of viewing topics, allow people to view topics: by purely chronological ordering, unaffected by bumps; by number of recent replies; and by some "hotness" criteria affected by views and replies.
- Allow people to maintain a list of users who are "friends". Highlight topics/posts by friends, topics posted in by friends, and topics/posts thanked by friends.
- An API