Currently in our discourse, we’ve added a custom user field for discord account name that users must fill in on registration for reference purposes. That’s also how an Discord/PHPBB plugin worked that provided similar functionality.
It’s not the greatest solution (half our users don’t fill out the # part of their discord name), but it does work.
That’s not really what this topic relates to, the goal here is to keep discourse trust levels synced with discord. It relies on proving you are both users.
What’s to stop someone impersonating another discord user and inheriting their trust level if it’s a free text field?
How would you do that without having access to the other person’s account?
If I say my discord account is administrator#1234 instead of user#5678, I won’t get anything out of it because I can’t sign into discord as administrator#1234. Since Discourse is the authority and is pushing permissions to Discord, the worst that would happen is administrator#1234 would lose his rights in Discord until someone realizes what happened (and likely bans the user from Discourse).
Use our Discord Oauth2 Plugin for login.
It receives the correct, authenticated Discord user ID.
Check if it stores it, if not creat a PR to store it.
Then you have the Discord Data for every user to use during sync.
I think the best solution to be honest would be to map discourse users to discord users not by email or username, but by ID.
Or, rather, using Discord’s OAuth2 to have the user link their Discord user account to the Discourse, so now Discourse knows what user ID belongs to that user on the Discord side and thus can access the user via the API.
I believe this is what Patreon’s integration does - it links your Discord account to your Patreon account, then has a bot sit in the server and sync your pledge with Discord so you get the associated roles based on what tier you hit with your pledge.
We’re essentially trying to accomplish the same functionality, so a similar structure would make sense. Our “tiers” are the trust levels/user groups, and the only issue is that Patreon is a centralized platform while Discourse is not.
Edit: By Discourse not being centralized, I mean the fact that to create a Patreon campaign involves creating an account on Patreon’s site and that’s pretty much it. Everything is done in the one spot. Creating a Discourse community involves actually hosting your own instance of Discourse on your own server (or paying literatecomputing to set it up for you). However this would simply mean that, unlike Patreon, the admin of the community would have to create their own bot account and give their Discourse instance the keys to it.
This also completely eliminates any potential issue with having this be a free text box. You need to actually sign in to both accounts to link them, which is a pretty good way to prove you are both users.
Well yes, that’s the point.
I don’t think anyone who has been following this topic was under the impression that your bot was going to rely on the honor system to identify users. It was a given that the oauth2 flow would be used, because why wouldn’t you? If eliminates both user error and malice, streamlines sign-in and significantly reduces any support overhead.
I’m all for using oauth2 or any other means of eliminating user malice and/or error.
I was just proposing a quick and dirty solution to getting around the discord email look up problem.
The work to achieve that was done months ago by @featheredtoast and if that’s all you need you can install the plugin which @falco linked above.
As to the scope of this topic, building on that link to sync trust levels, if you can’t wait for @sudaraka to finish his work your other option is to post over on #marketplace. Include your proposed budget to see whether another developer would be willing to build this for you sooner.
Yes. This is correct as far as I can tell, being a user of both plugins.
Patreon requires log-in via Patreon, then syncs your account to your pledge tier.
Would be great to sync Discord roles via Discourse, since Discourse has the information via Patreon already once logged in.
I’d like to gauge interest for an Discourse plugin that does the following:
An administrative interface for an admin to connect their Discourse instance to a Discord instance via the Discord API. The authentication would be via OAuth 2.
Controls to associate Discourse Groups with Discord Roles, so that members of a group have a certain discord role and vice versa.
Note that this won’t involve or rely on Discord OAuth as a method of user account authentication. The goal is a have a solution that is agnostic about the way you let you users sign up / login.
In terms of identifying users across both platforms, this will be handled by associating ids as a first step, then by email if the relevant id is not available.
If you’re interested in sponsoring such a plugin, now’s your chance. I have time to work on it next week.
Just an update here, we’re going ahead with building this.
Further details here:
If you want to sync Discourse Groups and Discord Roles, we’d appreciate a contribution to the Paypal pool for this work here (currently one sponsor):
*Update
@Hanzo1 @Wedgebert @chagara Are you guys still interested in syncing Discourse and Discord Groups and Roles? If so, we’re in the process of building an integration and need a few more backers to hit our (relatively speaking) low target of $1000 USD. Any contributions > $100 welcome.
We’re interested, but I’ll have to talk to our treasurer about getting donation money together.
I just chipped in some, we’re almost at the target.
For anybody here who is lurking and considering it, I want to emphasize how incredibly reasonable of a funding goal this is for such useful functionality.
There’s one day left and we’re currently $300 short. If you’re even slightly interested in this, now’s your chance to make it happen. 
We’ll be donating as soon as the person with access to the PayPal account gets online and does it.
Hey guys, just wanted to say I’m still following the project. Though I’ve moved away from using a forum specifically for my community, (we moved to reddit), it’s really awesome to see my MacGyvered-together proof of concept turn into a reality. I haven’t been able to follow the project much due to highschool and other personal reasons, but things are really shaping up from what I can tell. Good luck, guys! 
Donation has been made
Perfect advice 
Heads up (and @featheredtoast) I’m working on a PR for this plugin to
Auth::ManagedAuthenticator to
user_associated_accounts)
UPDATE: Submitted
This is a really interesting idea! Looking forward to see where it can go from here.
Some significant further progress on integration … see if you can spot it 
(thanks to @falco for helping me clear an impediment)
=> Booting Puma
=> Rails 5.2.3 application starting in development
=> Run `rails server -h` for more startup options
Starting CSS change watcher
-------------------------------------
Bot spawned, say "Ping!" on Discord!
-------------------------------------
[INFO : websocket @ 2019-06-30 11:00:05.038] Discord using gateway protocol version: 6, requested: 6
Puma starting in single mode...
* Version 3.12.1 (ruby 2.6.1-p33), codename: Llamas in Pajamas
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
This bot is responding on Discord determined by the code running on my Discourse plugin.
NB this is just proof of concept so far, potentially a little way off Production ready!
I now have kicking on Discord working depending on Trust Level on Discourse.
If you so choose you can kick all users on your Discord server that haven’t yet attained a minimum Trust Level on your Discourse forum.
I have yet to package this up and launch the plugin … watch this space.
