#14: Update ENS IPFS content

Proposal
#1

Since the August 8th crisis, the organisation has found itself in the crossfire of regulatory scrutiny and unnecessary censorship. On such actions that attempt to restrict usage of the protocol, the graph censored the tornado subgraph on their hosted service. This resulted in the inability of the application to index deposit events for withdrawals and such proof generation. Essentially restricting normal usage of the protocol through the official interface.

While the frontend did have logic to fall back on cached events, it was not functional out of the box. Unfortunately, it took two independent builds to resolve these problems entirely, as the frontend had some undesirable logic that caused further issues.

In the case of Nova, it was dependent on the official Gnosis assigned RPC endpoint, which strangely experienced downtime after the crisis for amount of time - but was eventually restored. To negate reliance on one provider, a simple RPC resolver was developed and assigned as the Gnosis RPC endpoint. Additionally, SecureRPC was set as the default Ethereum endpoint in place of the censored Infura endpoint.

I undertook efforts to entirely resolve these conflicts, the solution builds have been deployed live under the following IPFS hashes, and assigned to the community-managed ENS for the past 2 weeks. No critical issues have been reported, thus seeming safe to bring into production and restore usage.

Classic (tornadocashcommunity.eth) [source code]

bafybeiguelxw5aanwnhvaea5vjhknmcdmwvujne36wgabnkmcbt3563toa

Nova (nova.tornadocashcommunity.eth) [source code]

bafybeifj3aynom2v5crx5cxrysgcgtvbwaejucxxpqacoe3zg7ysaua5sm

Furthermore, the need to update the official ENS’s IPFS content is because of the community social links. To those not aware the old community Discord’s invite link was namespaced attacked since its deletion. The adversaries are now luring in unaware potential users and exploiting them for their inexperience, Discord will also not do anything to resolve the problem.

This brings up the discussion of either:

  • replacing all the social links with the new community substitutes (as implemented in the community build)
  • removing all social links, the argument being to negate the liability of management

A draft implementation has been authored to enact this proposal and shall be finalised in the next few days. Please express your opinions and critiques on it or the basis of the proposal, as it will be going live shortly.

#2

If curious to audit and verify the changes to the classic frontend, see Micah’s guide:

#3

My vote is to just remove the social links. I don’t think they provide significant value, and it is something that may be contested in the future and cause a community split. By just not having them, it removes a potential social attack vector against the community and simplifies the page to being a purely functional tool.

1 Like
#4

I’d agree to remove them from the front-end app. Social links should maybe just be on the tornadocash.community main landing page.

I am a little confused about the potential liability you mentioned. Is it because these social services (Discourse, Gitea, Matrix, etc.) require a vps and domain name registrations by an individual or org and if the TornaDAO ‘endorses’ those as the official social links it’d put those individuals at risk?

1 Like
#5

I’m in agreement to remove the social links, it is a liability. I will make the necessary commits and will update the new content hashes before pushing this on-chain this week.

If the person who manages the social links either goes MIA or in the turbelence we are currently facing, is held against their will. Then these portals can either be exploited or just become useless and outdated, that is the liability.

#6
#7

The proposal has been deployed and is now live, please take the time to vote as the voting period ends in 3 days. You can vote on the governance route of the community build.

#9

Is it too late to make any adjustments to the proposal now that the submission has been made on Etherscan?

Maybe I’m looking in the wrong place but when I look at all three branches of the existing classic-ui repo the unknown donation address is still the same.

One other thing I noticed, very minor, but when just now when playing around with multiple tabs I noticed I still get redirected to the old twitter page instead of the new one. In the staging branch the Footer component links have all been corrected including the twitter one, it’s just the redirect when multi-tabs are detected.

Both of these are pretty minor and can be addressed at a later date when needed.