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