Thank you for the effort simplifying and explaining to us the onboarding process.
Would it be possible to add step #3 directly in syrius after the regular onboarding process of saving the passphrases etc ? I’ve read somewhere a dev suggesting that a new binary could be created for each download. Would it be possible to inject the WC user information in the syrius binary for each user so that the ‘WC login’ can be completed directly inside syrius?
My concern goes something along the lines of, given Zenon.org is currently an informational onboarding website, there is no incentive like on Zerion to go back and login because a user wants to use the web app. As you pointed out, the user might be overwhelmed with syrius and then he needs to remember: "oh shit, what was I doing, oh yeah surfing zenon.org, let me go back and read more, oh its telling me to connect the wallet, nah I’ll do that later let me learn more about staking’ potentially losing his on chain information.
marketing.zenon.org → download Syrius → setup new wallet → link Syrius address with marketing.zenon.org using WalletConnect → track user on-chain activity
Think of marketing.zenon.org like a DApp and Syrius like Metamask. You give it permissions to read your wallet and potentially sign/authorize transactions.
Using an extension is simpler than using a mobile/desktop wallet: you don’t need WalletConnect because you can communicate with the web page directly via the browser.
The practice of tracking user actions on-chain for marketing purposes is viable and already employed by other platforms, though I’m surprised we want to follow this trend.
The WC suggestion is conducive to our goal of interconnecting with the broader web3 ecosystem and could enable other Zenon organizations to create webpages/applications that interface with the NoM.
On the other hand, this does create some work for ZenonOrg and will significantly delay their marketing plans. Additionally, the solution depends on Syrius developers to test, integrate, and deliver the WC functionality. Given our current pace of development, I’m hesitant to even estimate a timeline.
At this stage I cannot guarantee that I’d make use of the proposed WC method, we’ll be evaluating all options including forks of wallets. This isn’t a race for us, it’s about identifying the path of least resistance. Though nothing can stop you from submitting an AZ proposal @aliencoder, it would be non-sense to try to prevent such things (or forks).
I’m here to help you and that’s why I tried to find a better solution in the first place. It’s not even in my power to stop you, the decision to merge code into the official codebase is in the hands of the team.
However, what we can do is to make sure that the changes proposed are aligned with the vision of the project and the expectations of the community.
Anyone can toggle out of anon analytics during the syrius desktop installation. Problem solved.
No need to hope for users to connect to the dApp using WC (even with incentives in place).
Enables in-product analytics which can be used to improve the product long term (UX, feature usage, app usage metrics etc).
18 voted yes, 8 voted no in Discord.
aliencoder proposal:
Sets precedent for 0 in-product analytics, ever. Will rely on a slower feedback loop: written/verbal/personal assumptions feedback.
Sets precedent of “non-sense” for others to fork syrius products, even though it’s inevitable to happen sometime.
Values an ideology over the value in-app analytics could drive for growth of the network and improvements it could make to the syrius desktop product.
Although the WalletConnect method is valuable for all kind of dApps to interact with syrius desktop, it creates the risk that users will not connect using WC and as a result putting marketing tracking in a limbo (regardless of the incentives offered). “Did they end up installing? Don’t know. Did they delegate? Don’t know. The connection with WC wasn’t made, so we’ll never know.” … It’s only chance is that the marketing funnel sets the expectation of the WC connection very early and repeats it so that the user thinks it’s almost requirement (very much less misleading/intrusive than my option’s toggle ).
Other marketers will be able to create their own versions ideas like Attribute, marketing frameworks etc. Every brand will control their own marketing tools.
I don’t agree with the ideology that non-intrusive anon tracking or forks are “non-sense”. That’s not the Zenon ethos.
For the sake of settling this issue and moving forward, ZenonOrg will vote in favour for the WC method, and will do its best to find a way to make it all work with the slightly more difficult experience to capture analytic tracking (WC connection requirement). It’s a shame that syrius products won’t ever get analytic data to help shape a better experience.
Any chance we can just implement the solution with the least friction and highest probability to facilitate adoption while leaving aside ideologies/dogmas 99% of all end users won’t ever care about? Especially if it still offers a puristic alternative to the 1% who do?
99% of web3 solutions experience near zero adoption because engineers believe to know better what end users should want. Let’s not make that same mistake please.
).