That doesn’t sound like any of the developers I know (myself included)
Ehh, I guess my experience in .NET kinda showed there, usually I tend to find a NuGet package that does what I want before I try to do it myself lol. Though, I suppose it depends on the environment and what you’re trying to accomplish.
I do think that there are some features that a Discord bot could do a lot better than a webhook can (which is what the chat integration plugin uses), like getting notified of PMs through a Discord DM, being able to turn certain things on/off per-user/in your preferences, etc. Just not super sure how many people would use that - though, I also said that about trust levels in Discord before I posted this thread - and look where we are now
I’m a .NET/TypeScript developer myself. Our gaming guild has needed something like what you’re doing for a while now and I started looking into doing something similar to this myself a couple days before your first post.
Then you apparently just read our minds and started implementing or planning all the features we want so I was able to go back to playing Oxygen Not Included
Heh - what are the chances? I’m a gamedev myself and I wanted to integrate my Discord guild with Discourse which is why I decided to implement it. I also wanted to dust off my Discord bot dev skills because I haven’t been able to really use them for anything practical until now.
Hey guys - just another small update.
-
I fixed an issue where the bot generates sso links that call back to a URL on a different port than port 80/443 when running behind a reverse proxy, thus causing a timeout.
-
We’re putting together a team to get this thing ported to a Discourse plugin. Should hopefully have an update on that in the next week or two.
Been a while, how goes the updating?
Project went a little dormant for a bit. I’ve been busy with school and also working on my game. My dual credit course is on a reading week this week though, so I have more time to work on things.
I am also waiting for that plugin, like a small chield waiting for his birthday gift
Update guys: we’re beginning work on the plugin. The base structure is there, we’re working on the primary features for the discord integration now.
Just checking, been a while, and making sure no developers were hit by the proverbial bus that we’re always talking about
I haven’t heard much but I know @Sudaraka is working on implementing the bot. He’ll fill us in once he’s got a working version, and we’ll keep you guys in the loop.
As much as I was looking forward to this, it’s been months since any progress was made and I’m assuming it’s dead
Does anyone know of any similar efforts being made?
It’s been only a month. @Wedgebert be patient, making integrations like this is not so easy. I’m also waiting for this to come, but I’ll expect it to take time.
Yeah, it’s still in progress. I remember the last time I heard from the rest of the team is we hit a snag where we were trying to get Discourse to map emails to Discord users. The discord API doesn’t support fetching user info by email so this isn’t super trivial. I don’t even think the user info returned by the API contains an email. So I think the current task is figuring out how to link accounts together.
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.