The user trust system is a fundamental cornerstone of Discourse. Trust levels are a way of…

• Sandboxing new users in your community so that they cannot accidentally hurt themselves, or other users while they are learning what to do.
• Granting experienced users more rights over time, so that they can help everyone maintain and moderate the community they generously contribute so much of their time to.

As documented in Community Building on the Web, there is a natural progression for participants in any community.

This seemed like a great starting point for our user trust system. Thus, Discourse offers five user trust levels. Your current trust level is visible on your user page, and a summary of all trust levels within your community is presented on your dashboard.

Trust Level 0 — New

By default, all new users start out at trust level 0, meaning trust has yet to be earned. These are visitors who just created an account, and are still learning the community norms and the way your community works. New users’ abilities are restricted for safety – both theirs and yours.

(We also want to hide any “advanced” functionality from new users to make the UI less confusing for them as they gain more experience.)

Users at trust level 0 cannot …

• Send personal messages to other users
• “Reply as new topic” via Link button (UI removed)
• Flag posts
• Post more than 1 image
• Post any attachments
• Post more than 2 hyperlinks in a post
• Have actual links in the ‘about me’ field of their profile (will be silently and temporarily converted to plain text)
• Mention more than 2 users in a post
• Post more than 3 topics in the first 24 hours after creating their first post
• Post more than 10 replies in the first 24 hours after creating their first post

Admins can change these limitations by searching for newuser and first_day in site settings.

Trust Level 1 — Basic

At Discourse, we believe reading is the most fundamental and healthy action in any community. If a new user is willing to spend a little time reading, they will quickly be promoted to the first trust level.

Get to trust level 1 by…

• entering at least 5 topics
• reading at least 30 posts
• spend a total of 10 minutes reading posts

Users at trust level 1 can…

• use all core Discourse functions; all new user restrictions are removed
• Send PMs
• Upload images and attachments if enabled
• Edit wiki posts
• Flag posts

Admins can change these thresholds by searching for tl1 in site settings.

Trust Level 2 — Member

Members keep coming back to your community over a series of weeks; they have not only read, but actively participated long and consistently enough to be trusted with full citizenship.

Get to trust level 2 by…

• visiting at least 15 days, not sequentially
• casting at least 1 like
• receiving at least 1 like
• replying to at least 3 different topics
• entering at least 20 topics
• reading at least 100 posts
• spend a total of 60 minutes reading posts

Users at trust level 2 can…

• Use the “Invite others to this topic” button for one-click onboarding of new users to participate in topics
• Invite outside users to PMs making a group PM
• Daily like limit increased by 1.5×

Admins can change these thresholds by searching for tl2 in site settings.

Trust Level 3 — Regular

Regulars are the backbone of your community, the most active readers and reliable contributors over a period of months, even years. Because they’re always around, they can be further trusted to help tidy up and organize the community.

To get to trust level 3, in the last 100 days…

• must have visited at least 50% of days
• must have replied to at least 10 different topics
  of topics created in the last 100 days, must have viewed 25% (capped at 500)
• of posts created in the last 100 days, must have read 25% (capped at 20k)
• must have received 20 likes, and given 30 likes.*
• must not have received more than 5 spam or offensive flags (with unique posts and unique users for each, confirmed by a moderator)
• must not have been suspended

* These likes must be across a minimum number of different users (1/5 the number), across a minimum number of different days (1/4 the number). Likes cannot be from PMs.

All of the above criteria must be true to achieve trust level 3. Furthermore, unlike other trust levels, you can lose trust level 3 status. If you dip below these requirements in the last 100 days, you will be demoted back to Member. However, in order to avoid constant promotion/demotion situations, there is a 2-week grace period immediately after gaining Trust Level 3 during which you will not be demoted.

Users at trust level 3 can…

• recategorize and rename topics
• access a secure category only visible to users at trust level 3 and higher
• have all their links followed (we remove automatic nofollow)
• TL3 spam flags cast on TL0 user posts immediately hide the post
• TL3 flags cast on TL0 user posts in sufficient diversity will auto-silence the user and hide all their posts
• make their own posts wiki (that is, editable by any TL1+ users)
• Daily like limit increased by 2×

Admins can change these thresholds by searching for TL3 in site settings.

Trust Level 4 — Leader

Leaders are regulars who have been around forever and seen everything. They set a positive example for the community through their actions and their posts. If you need advice, these are the folks you turn to first, and they’ve earned the highest level of community trust, such that they are almost moderators within the community already.

Get to trust level 4 by…

• Manual promotion by staff only
• (Possibly via a to-be-developed election system in the future)

Users at trust level 4 can…

• edit all posts
• pin/unpin topic
• close topics
• archive topics
• make topics unlisted
• Split and merge topics
• Daily like limit increased by 3×

We believe this trust system has been a success so far, as it leads to stronger, more sustainable communities by carefully empowering members, regulars, and leaders to curate and lead their own communities. But like everything else in Discourse, the trust system is evolving over time as we gain more experience with more communities. We’ll continue to update this post with any changes.

We released Discourse 2.0 on May 31st, building on Discourse 1.9 from January.

New Admin Dashboard

We’ve completely redesigned the admin dashboard to show off your most relevant and essential community health metrics right at the top, as well as trending searches.

Shared Drafts

Staff can designate a category for shared drafts, and pre-compose topics that only other staff can see for review prior to posting. After posting, all logged edits are removed so the history is clean, and the timestamp is reset, too.

Reply mode toggle

While composing a reply, you can now click or tap the reply arrow to quickly toggle between replying as a new topic, replying to the overall topic, replying to an individual post, replying as a personal message, or even replying as a staff whisper.

Two Factor Authentication

We’re proud to now offer fully integrated Two Factor Authentication as a standard Discourse feature! Enable it in your user preferences, and take advantage of the free Android or iOS authenticator apps on your smartphone for enhanced account security.

Login via Email Link

To make logging in a little more convenient for your community, you can enable logging in via an emailed link in your site settings.

Local Dates

Coordinating meetings or events in Discourse is now easier — insert a local date that will automatically appear localized to the reader’s correct time zone, so nobody gets confused about when to show up.

Tag PMs and Required Tags

Tags are a great lightweight complement to categories, and now to make them even more useful they can be mandatory on topics, per category.

In order to better organize incoming messages, staff can now tag PMs to group them, too.

Categories and Top Layout

There’s a new homepage layout style that combines the best of both worlds — a list of categories, as well as a list of top posts in the selected time interval, side by side. You can select this layout as your site default via your setup wizard.

Theme settings

Discourse themes can now have settings of their own.

Merging Users and Granting Badges

Looking to give your community members a little extra encouragement? Staff can now grant arbitrary badges to users via the admin wrench action on any post.

And, via the command line, merge duplicate users, too.

Improved Full Page Search

We’ve improved the wide search page layout for tablets, laptops, and desktop to make better use of larger screens. We’ve also dramatically improved search relevancy for direct title matches, and added a highly requested “search only in topic titles” option.

GDPR Enhancements

Discourse has offered download of all user content and a user anonymization facility since version 1.0. In this release, we’ve improved these features to make them even more reliable and easy to use, as well as removed a number of places where we were storing IP addresses internally that we didn’t need to be.

Discourse has always prioritized empowering communities, and we’ll continue to improve in this area to give your users the control they deserve over their online footprint.

And More!

These are just highlights of 2.0 — there are literally hundreds of other tiny improvements, refinements, and bugfixes in the full release notes.

Easy One Click Upgrade

We launched a public exploit bounty program at Hacker One as a part of our security policy one year ago. We strive to be secure by default, even in the case of sophisticated social engineering attacks, and we always follow up on any security concerns. There are several important security fixes in 2.0, so we urge everyone to upgrade to it as soon as possible.

If you are on our hosting, you’re already upgraded. Otherwise, upgrading is as easy as clicking the Update button in our built in one click updater linked right from your dashboard:

In some upgrade scenarios, you may need to SSH in to update your server. It’s just 3 commands:

cd /var/discourse
git pull
./launcher rebuild app

If you don’t have a Discourse to upgrade, why not? Install it yourself in under 30 minutes, or get a free 14 day hosting trial!

Thank You

Let’s first thank our customers for their direct financial support, without which there would be no Discourse project at all.

Any open source project is only as good as its code contributions. Thanks for the pull request contributions in this release from:

We had a remarkable number of translators in 2018 who contributed their time and effort translating Discourse into dozens of languages. It’s because of you that so many people around the world can benefit from great free, open source discussion software, and we appreciate your hard work.

Thanks to the greater Discourse community for posting support / bug request / feedback topics on meta.discourse. All your suggestions make Discourse better, not only for your community, but all of us.

It’s hard to believe that version 1.0 was released less than four years ago, and we’ve delivered ten major releases since then! We don’t plan to slow down, either. Check out the releases category to see what’s next in Discourse 2.1 — and beyond.

Here at Discourse World HQ, we’re firm believers in the value of security. We fund a public bug bounty program, and we document our security policy and procedures right in the repo. Securing traffic between a forum’s server and its users is important, too, and we’ve had first-class support for integrating Let’s Encrypt into a self-hosted Discourse server since virtually day one of their being generally available.

All of this is to explain why we’re so very proud to be able to announce that every new hosted Discourse instance now comes with HTTPS configured (and enforced via HSTS policy) by default, and the majority of our existing customers have been transparently migrated to enforced HTTPS. Some of our customers can’t be automatically HTTPS enforced; if you see your site is still loading over HTTP, please contact our support team so we can walk you through the changes that need to be made.

The Story So Far

HTTPS has always been supported by our hosting, but for a long time it wasn’t feasible to automatically roll it out to everyone. Back in the Dark Times (up to 2015 or so), SSL was a headache to do at scale, unless you were big enough to be able to wangle a special deal with a CA. Sure, certificates cost money, but that wasn’t the biggest hassle. The thing that stopped us, honestly, was the painful story around automation. Basically, there wasn’t any – not end-to-end, anyway.

It’s fun to track the evolution of our SSL procedures by looking at the titles of our runbooks over time. In the Dark Times, we went through several iterations – there was “How to install a customer’s SSL certificate”, then “Customer SSL workflow (Manual Edition)”, “Semi-Automated Customer SSL workflow”, and finally, “Customer SSL workflow (99.5% Automated Edition)”. Whilst we tried very hard to automate as much of the process as we could, getting an SSL certificate always seemed to involve a human in the loop somewhere, and when you provide automated trial signups, you can’t put a human in the middle of that process without making everything terrible.

Thankfully, Let’s Encrypt came along to bring us into the age of certificate Enlightenment. We’ve been big supporters of Let’s Encrypt for a long time; we’ve been donating the hosting for the Let’s Encrypt community forums practically since the initial public announcement, and we donate what we would have otherwise spent on certificates in cash, as well. When Let’s Encrypt became generally available, we re-implemented our SSL certificate issuance pipeline on top of that, and everything was reasonably peachy.

Reality Ensues

So, Let’s Encrypt made it easy for us to fully-automate getting SSL certificates for our customers, as they asked for it. Except, there’s a big difference between requesting a certificate for a running site, when a customer asks for it, and making sure you’re getting a certificate issued as soon as the site’s DNS is configured. Even detecting that DNS is correctly configured, given the wide variety of, shall we say, “interesting” configuration choices some people make, can be a challenge. This took a lot more time and ingenuity than getting issuance working. Requesting a certificate from Let’s Encrypt and dealing with validation is about 10 lines of Ruby (with the help of the acme-client gem) and a bit of HAProxy magic. Dealing with all the special cases and exceptions in people’s DNS and proxy setups is quite a bit more code.

As an added challenge, a large part of our team has been hard at work since mid last year building out a completely custom, hyper-scale AWS-based hosting environment for a large game company. That work, which has now borne fruit, diverted time and attention away from building out universal SSL as quickly as we would have liked.

The Final Hurdle

The final hurdle is the problem of migration. We want all our existing customers to automatically have the benefits of our SSL labours. There’s a few things that get in the way of just flicking the switch for customers who have been with us for some time.

First off, forcing everyone to use HTTPS, via redirects and HSTS config, breaks some things. The biggest issue is the lack of a universally-supported way to say to a HTTP client, “transparently make this exact request again, but to this other URL”. There are newly-standardised HTTP response codes for “redirect with the same HTTP verb”, but they’re not supported by all browsers and HTTP libraries, and they sometimes prompt “do you want to do this again?”, which isn’t what you want for a smooth transition.

External authentication providers get in the way, too. They often whitelist the return URLs they’ll accept. When you call out to an authentication service, you typically send along a link which the browser should be redirected back to after authentication is complete. Sending an HTTPS link, when the authentication provider expects an HTTP one, results in authentication errors. Very not cool. We can’t fix this ourselves, either – we don’t have access to our customers’ Google, Facebook, and Twitter applications to update the whitelisted URL.

Finally, there’s the age-old problem of mixed-content warnings, which pretty much everyone who has stood up a HTTPS site has dealt with at one time or another. Thankfully, the vast majority of those we can fix on our customers’ behalf, by making sure the site being linked to supports HTTPS, and modifying the site config to add a strategically-placed “s”.

Security is no longer optional

Our deployment of HTTPS by default is coming at just the right time. Popular browsers such as Chrome and Firefox are in the process of rolling out changes to mark HTTP-only sites as “Not Secure”, like so:

It’s reasonable to assume that this trend will continue, with other browsers following suit, and the warnings getting more and more scary over time. So, regardless of where you’re hosted, now would be a good time to start making sure all your web properties are being served over HTTPS.

Full of win

It has been a bit of a journey, but in the end, we’ve gotten to where we want to be: new customers get HTTPS enforced by default, most existing customers have HTTPS enforced by default without their even noticing, and for the remainder, we know exactly what they need to do to complete the upgrade.