there’s another thread where folks figured out how to login/register using a eth wallet. i’ll track it down
This one Sign-In with Ethereum plugin
My guy, thanks. PS: love your responsiveness on Communique
1 Like
I don’t believe the question was about how a forum would specifically benefit from blockchain, just simply what the benefits of blockchain are in general.
1 Like
I suspect the value of a generalisation is limited.
The question was specific about Discourse, a forum platform.
A “Web 3.0 application” presumably uses blockchain so I believe my post was entirely appropriate.
My opinion: it would be a complete disaster!
6 Likes
I’d love to see tools to power free speech, maybe supporting cryptocurrencies as Monero or platforms as Nostr.
I work for a Solana blockchain gaming company. We have a DAO, and we want to use Discourse because it is the ne plus ultra of discussion and community building apps currently available. Hands down.
However, in web3 the basis of identity is focused on a user’s public key, their self sovereign identity. I can leave aside discussions around blockchains in general, NFTs and so forth for the moment. All that’s happening when a user pushes a button on their hardware wallet is that the private key on the device is being used to sign a message. It’s basically PGP in some regards. Now those messages can be signing a blockchain transaction and broadcast to the network, or they could be signing any arbitrary string that meets whatever authentication interface we need to spec to. Ultimately, my team is trying to figure out the best way to do that.
There are examples of basic chat and messaging apps on Solana, but right now we’re restricted to 1200-ish bytes for our messages which is about 800 words or tokens. https://www.dispatch.forum/ has built a pretty nice on-chain open source Reddit-style app, but we think we can build a better product by tacking Solana pubkey and message signing onto Dispatch. We’ll be restricting external users via custom front end or some sort of API middleware while we build out and figure out our eventual strategy for a transition to a full web3 experience.
Regarding the UX, Solana has sub-second confirmation times, and with several tens of thousands of transactions per second, so it’s not like like EVM chains where you’re waiting in mempool for half a minute. People make jokes about SQLana, but it’s actually more akin to a noSQL database with a Rust execution engine. Programs in Solana have no state, all of that is stored separately in account objects. So it’s quite different from Ethereum and it’s derivatives.
Anywhoo, we’re going to solve this problem one way or the other, and my hope is to open source the solution from the get-go.
5 Likes
When discussing a Discourse integration your vision is that every message I post is also signed using my private key in my wallet?
so the integration piece becomes “talk to my wallet on the fly” and technically no login is needed? Is that spam proof?
We currently tie identity to email, but I guess you could synthesis something there.
I think the Sign-In With Ethereum is probably the best example we have right now, just using it for a login session is fine because the app isn’t storing data on the blockchain. If you were using Solana instead of Postgres however …
Our current design plan is to build some sort of middleware that can create new users and retrieve their API keys. On login we check for the user’s ID, which would be something like their Solana pubkey @ nonroutable internal domain or whatever. We send the API request to create the user.
We do not plan on exposing the default web interface to users, but instead will retrieve specific categories that we designate via the API and render them in our React app.
When a user goes to post a comment — the only functionality we plan on providing them for our MVP – we need to have some wallet signature event that validates the signature, then retrieves the user’s API key and sets it in the browser so that it is passed along with the post event.
We don’t have Rails developers on staff and it seems counter-productive to build around your front end. We figure we can extend the REST API or go straight to the database to set and retrieve these keys.
I’m still thinking my way around middleware solutions that pass OAUTH, but again, not sure that’s relevant given that we’re bypassing your front end.
1 Like
I don’t need to read any article to know that a system, that relies on always more and more CPU having to to be running permanently, is just wrong.
And all that for god knows what, who needs crypto-money?
Speculation is nothing useful.
Ever-increasing energy consumption for such lame purpose is waste.
1 Like
I agree with this. Sadly there is too much emphasis on this because people want to get rich quick. All this noise sometimes obscures that there are also genuine people building things.
There are many places around the world where citizens don’t have access to banking and the digital economy. For example Afghanistan:
I think its unfortunate that the taxpayers from the US and Europe spent 20.000.000.000.000 $ on the war there. And now Afghans can not even make an account on upwork.com and find work in the digital economy. 
I started working on an upwork alternative (using a Discourse forum) x.com It is not easy to overcome the network effects (especially as I can only work on this in my free time.)
But it is clearly a solution. Without crypto it would have been very hard to pay someone living there and build trust. The barrier to installing a wallet app is way lower than doing a remittance.
I just wish people were less cynical and just built things 
I made a subscriptions plugin for Discourse that uses Monero: x.com
You can try it with stagenet coins at https://forum.monerochan.news
I could also make it compatible with other currencies if someone is interested.
That is indeed the right solution. Discourse is very tied to email. So it would be hard to patch out the mandated necessity for a confirmed primary email. I investigated this question a while ago and found it would be much easier to create a user with a placeholder email and set active to true (aka user has a confirmed email).