This forum post is a submission for the Discourse Ethereum authentication bounty.
My solution was to implement Sign-In With Ethereums OpenID Connect Provider for use by the Tornado Cash (TC) community, similar to running TC community managed IPFS gateway. Please start by reading the introduction section of this repo for a full description of the service, what it is, why it exists, how it works, etc. By using this method it not only allows TC to integrate Ethereum wallet account authentication for Discourse, it makes it relatively simple to implement across all existing infrastructure using the commonly supported standard called OpenID Connect, an extension of OAuth2.
From the bounty description:
Integrate the possbility of registering and signing into an account on a Discourse instance by connecting an Ethereum wallet, and signing a message. Display the user’s verified address on their forum profile.
My submission matches the above with the following caveat. A user’s verified address is not displayed publicly but is viewable to them in their profile, they can choose to reveal it upon account creation or at a later date.
Regarding:
It should be not be understated, that implementations that depend on other services are not desirable.
My solution implements a self-hosted service and touches no external resources not owned/managed by the TC community. As I believe that was the intent, to avoid external services to preserve privacy, this service would run along side any of the existing TC services, Discourse included.
Of the outlined deliverables:
- Fork the Discourse source code
- integrate logic to handle a web3 provider
- on registration and sign in require a message to signed to prove owneship of the address in question
- Replace email key mappings in the database store with Ethereum addresses
- Create a repository on the community git and document the logic thoroughly
- #5: I have documented both the installation of the service and how to connect it to all the existing TC infra. services.
- #2 & #3: Both are implemented as described
- #4: Was not met because of #1
- #1: Forking and building a custom Discourse image, while opensource, seems to have been made deliberately difficult if not near impossible. See below for more context.
While speaking with Micah in the matrix general chat he corroborated the difficulties I experienced when trying to build the base Discourse app from source, without any modifications. Linking me to this thread. Reading through more thread of people trying tweak Discourse the dev team seems to not at all be receptive.
Instead of forking Discourse to implement a custom solution I made use of existing plugins to implement an already widely used standard that Discourse, and many other services, support.
To see a demo of this infrastructure in action I have them hosted at the following subdomains for testing purposes:
NOTE: The current SIWE page where the message is signed is the default one shipped by the dev team. It shows options for several wallet providers. Currently only MM is supported as the other require api keys to use. This page can be forked and modified, far more easily than discourse, to the desires of the community.