Updated Oct. 19

I've been trying to think of all of the features the perfect forum software would have, and this is what I've come up with so far. I'll eventually use the donated forum funds to pay someone to implement this. Please post your thoughts. I focused mainly on moderation, since that's the main area that I see SMF lacking in.

(This will be the text of a future thread aimed at bidders.)

[The future bidding 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.

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 500 BTC on hand, 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.

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.

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.

Database

PostgreSQL must be used. 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.

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. Use even fewer images than the current theme: no image buttons.

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

Optional: Web of trust

A trust system exactly like that of Freenet's FMS would be excellent. Bids including this will be greatly preferred.

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

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

OP = master troll.

(By the way, if there are still NSFW images around without a "NSFW" tag, report them.)

I like the idea.

Instead of reusing OP_CHECKSIG, I think it would be better to use OP_CHECKMULTISIG. OP_CHECKMULTISIG is defective and needs to be changed, anyway. OP_CHECKSIG can remain in use for "normal" transactions, which will keep sizes down. Using a different address version for these scripts will not be much of a burden on senders.

It should not be possible to use a mini-script that contains no public keys, as allowing this would make brute-forcing much easier. Instead of brute-forcing a key-creation operation and some hashing, the attacker would only have to do hashing.


Setting some fixed upgrade point and then not following through would be terrible because you'd still have some part of the network using the planned rules.

The server is configured to return 500 errors whenever there is any error, including 404s.

This is not reliable because orphan blocks are also stored there. My hash is different.

644. The oldest one has 107,362 confirmations.

You already have one! You just failed to use your own public key instead of Satoshi's key:
https://github.com/Lolcust/GeistGeld/blob/multimergemine2/src/main.h#L1578

Bitcoin will fix it by invalidating the broken block and all later blocks. Then it will redownload them all. I'd guess that a copy of the broken blocks and all later blocks would be appended, though I am not very familiar with Bitcoin's database. Try it and see what happens.

This kind of error is not very important. If corruption causes you to make a wrong network decision, then your client will detect that an invalid chain is longer than your chain and your client will go into safe mode.

I think it's just a Google quirk. Nothing related to that should have changed.

I believe that the error will be detected and fixed if you run Bitcoin with -checkblocks. Bitcoin only checks the last 2500 blocks by default.

This isn't possible. Even if all three bootstrap methods were shut down (which is probably itself nearly impossible), existing clients would still be able to connect easily using their address databases.

Third-party alert systems may be a good idea. These might also have faster responses than Bitcoin network alerts.

Here, I wrote a page about alerts:
https://en.bitcoin.it/wiki/Alerts

There's no documentation for this. Though it really would be a good idea for large services to check for alerts automatically.

Old versions of Bitcoin used to shut down RPC automatically when an alert was received. This should be brought back as an opt-in feature.

You can already do that by polling the getinfo "errors" field. It will fill with alert text when an alert is issued.

I've written some contingency plans for emergency network events:
https://en.bitcoin.it/wiki/Contingency_plans

Someone mentioned this months ago in another topic, and I thought it was a good idea. If plans and code are written before issues occur, then the response will be much quicker. I've not written any code for this yet, though I described the actions that should be taken after a few possible emergency events.

To get a transaction's sent value:
- Collect all prev_out structures for each "in" that is associated with one of your addresses
- For each prev_out that you have collected, find output number n in transaction with hash. The value of this output is the input's value. This transaction will exist either in your local transaction database (if you're using block hash stops), or earlier in the same mytransactions output.

The "in"s and "out"s that are not associated with your addresses can be ignored in your case.

The Tapatalk modification is a massive amount of code that is clearly messing with the security system. I don't have time to review all of this code, so I will not apply it.

Remember that the board doesn't verify email addresses.

SHlFT
Original username: Ezio
66.87.97.168, 107.29.108.104, 107.29.74.71, 107.29.92.252, 108.103.210.228, 108.116.107.92, 173.130.182.167, 173.130.62.126, 173.149.185.128, 173.96.255.163, 173.96.66.112, 184.207.25.127, 184.219.9.39, 66.87.96.215, 66.87.97.181, 66.87.97.184, 66.87.97.222, 66.87.97.230, 66.87.97.232, 66.87.97.90, 66.87.98.133, 66.87.98.151, 66.87.98.180, 66.87.98.247, 66.87.98.72, 66.87.99.20, 71.21.81.140, 72.56.215.231, 72.56.247.91
Email: auditore.sales@gmail.com
Secret question: ooi

Pearikay
Original username: zztop
66.87.96.209, 107.42.18.207, 173.106.62.117, 173.147.200.70, 66.87.96.13, 66.87.96.23, 66.87.96.254, 66.87.96.89, 66.87.96.96, 66.87.97.138, 66.87.97.168, 66.87.97.88, 66.87.98.240, 66.87.98.92, 66.87.98.96, 66.87.99.172, 66.87.99.255
Email: Alex@teleworm.com

Hollie
Original username: Darkness
184.171.168.202, 108.116.212.19, 108.116.28.128, 173.135.103.122, 173.149.144.123, 173.96.31.42, 184.209.248.98, 184.209.33.8, 184.231.206.17, 209.184.116.69, 64.134.157.255, 66.87.66.40, 66.87.96.11, 66.87.96.183, 66.87.96.195, 66.87.96.235, 66.87.96.236, 66.87.96.247, 66.87.97.136, 66.87.97.168, 66.87.97.192, 66.87.97.195, 66.87.97.212, 66.87.97.248, 66.87.98.115, 66.87.98.116, 66.87.98.151, 66.87.98.199, 66.87.98.239, 66.87.98.246, 66.87.98.47, 66.87.98.72, 70.3.226.211, 71.21.81.140, 99.200.197.89, 99.200.30.168
Email: jameslovecock@live.com

Darkness
66.87.97.248
Email: xninja.llc@gmail.com

Stefanie Andrea
107.28.115.141, 107.28.115.39, 107.28.137.251, 107.28.157.204, 107.28.189.208, 107.28.236.187, 107.28.244.20, 107.28.4.167, 107.28.98.107, 107.33.133.10, 107.33.136.196, 107.33.137.168, 107.33.139.187, 107.33.142.242, 107.33.145.229, 107.33.151.27, 107.33.168.5, 107.33.21.220, 107.33.210.140, 107.33.227.97, 107.33.251.103, 107.33.36.31, 107.33.96.37, 107.42.106.33, 107.42.155.238, 107.42.165.200, 107.42.188.172, 107.42.57.45, 107.42.92.3, 108.103.118.133, 108.125.66.189, 173.106.109.70, 173.106.119.219, 173.106.224.91, 173.106.230.69, 173.106.238.80, 173.106.40.46, 173.106.62.182, 173.115.145.46, 173.115.170.26, 173.115.212.240, 173.115.231.4, 173.115.25.75, 173.115.40.218, 173.115.55.132, 173.115.83.235, 173.147.109.202, 173.147.109.52, 173.147.112.202, 173.147.144.157, 173.147.193.37, 173.147.48.31, 173.147.72.239, 173.147.92.189, 173.147.92.235, 173.147.99.80, 173.7.104.162, 173.7.163.60, 173.7.17.165, 173.7.186.176, 173.7.205.9, 173.7.38.118, 173.7.47.95, 173.96.25.55, 209.184.116.42, 209.184.116.69, 66.87.96.113, 66.87.96.17, 66.87.96.173, 66.87.96.183, 66.87.96.209, 66.87.97.1, 66.87.97.138, 66.87.97.192, 66.87.97.248, 66.87.97.47, 66.87.97.64, 66.87.98.227, 66.87.98.228, 66.87.98.47, 66.87.99.114, 66.87.99.78, 68.241.102.227, 68.241.186.220, 72.56.144.250
Email: InfamousKraken@gmail.com

I just don't think there would be enough topics for a security section. If I saw like 30 active security topics, I would consider it.


Two of those wouldn't belong in a security section.

I already do!