Web Forum Custom Development

SERIOUS OFFERS ONLY

All offers must include:

- 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.

Exact requirements are shown below in "detailed description". Do not bid on this unless you have read, understand, and can deliver based on detailed descriptions.

## Deliverables

Requirements:

SMF features

All 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.

Code

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.

I now have some experience with SMF, so I will consider software built on SMF to be more readable/modifiable than I would otherwise. (The architecture is a mess and would require extensive modifications to fully meet this and the security criteria, though.)

License

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.

Database

PostgreSQL is greatly preferred. Queries should be well-optimized. Do not use a database 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.

Security

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.

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.

No user group should be able to run arbitrary PHP code.

All actions must be done by POSTing the server. GET requests must not have side-effects.

UI

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.

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 classes

So 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 stats

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.

Limits

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.

Registration

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.

OpenID

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.

Mod profile view

Mods 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 actions

Post 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.

Reports

People 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 PMs

Whenever 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 appeals

People 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 banning

There 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.

Watchlist

There should be a feature like the current "Show new replies to your posts", but it should only apply to topics that the user has explicitly added to his watchlist by clicking an "add to watchlist" link in topics.

No embedded images

Due 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

- 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

- For admins, creating boards and moving them around should be easy.

- 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 or a NNTP interface.

Amazon Web Services Ingeniørvitenskap PHP Prosjektledelse Programvarearkitektur Testing av programvare Web Hosting Ledelse av nettside Testing av nettsider

Prosjekt-ID: #2702977

Om prosjektet