Feedback: you can customize a little bit the toast: green color, add a suggestive icon maybe
1 Like
Regarding Syrius v0.0.7 release:
Hopefully we can integrate my WalletConnect implementation before the bridge goes live next week.
Why?
Because most of you I think are more comfortable using the Syrius desktop wallet rather than the browser extension.
4 Likes
Certainly, since most users already have the mnemonic imported in syrius.
2 Likes
100% agree on this.
Love the checks!
Will there be a address book in 0.0.7?
Option to name accounts?
Can be easily implemented, but it’s not a priority right now.
You already have this option right now.
1 Like
I wasn’t aware of that, how to do that? Which tab?
Settings tab, you can rename each of your own wallet addresses
1 Like
Added logging to disk functionality:
I’ve created a new log directory inside the syrius directory: ../znn/syrius/log/
Get the latest build here.
2 Likes
Another improvement for regular users:
When you first setup Syrius, present a list with community nodes you can connect to.
Many users are complaining about the time required to fully sync Syrius using the embedded node.
Until someone implements faster syncing of the embedded node, I can tweak that screen to show users the options they have and some hardcoded full nodes ran by the community:
- Do it
- Not now
0
voters
Not your node, not your code.
Who will manage the list of supported nodes?
What prevents them from abusing their status?
Don’t trust. Verify.
I think it’s not your node, not your rules.
I agree. But we need to take into consideration that no-coiners want a seamless experience and can’t wait days to be able to send a transaction.
Until we have a good IBD solution, we need to make some trade-offs.
I don’t think Syrius should suggest any nodes, even if it is a barrier to accessibility.
The community can manage an external list of public nodes. I already have this list.
1 Like
I do think it should. However if Syrius ends up being the equivalent of Bitcoin core wallet then some more user friendly ones can suggest nodes for the ones not willing to do more than 1 click.
Normies go for chrome extensions, how about we work to implement Layiids design and bring the chrome extension up to syrius standards while hardcoding a public node on it.
6 Likes
If ethereum wallets required everyone to run their own node or look for one on a forum, do we think they would have the same level of adoption they have today?
Maybe the nodes need to be approved by AZ. I plan to submit for the new my.hc1node.com.
I 100% agree with your comments. And for the people who are “qualified” to understand what you wrote they will use their own nodes. But for > 95% of the population they don’t want to sync a node and wait 24 - 48 hours.
So do we force them to run their own node and get frustrated and/or look for one that maybe a scammer provides? Or should we offer a solution that tries to balance adoption and some level of trust?
2 Likes
Imo we have 3 options:
EASY
- Do nothing. Hurt adoption when we need it the most (to get some traction and create a positive feedback loop for the price as well)
- Implement my idea: just a small change and I can emphasize that going with a public node is risky (regular users don’t even backup their seeds)
MEDIUM
- Light node for
go-zenon
HARD
- Instant IBD with zero knowledge proofs
Regarding medium and hard, I think the extension chain is more important than implementing either of these two solutions.
Regarding Easy, curious what others thinks. HC1 offers a public node today. I will ask for funding for it in AZ, which means the Pillars support it (f approved). Maybe AZ funding and community support is required for a node to be added to a list in Syrius.
I can make a sketch and we’ll see if we gather more support for this feature.
For example only approved nodes can be hardcoded into this list:
- Mandatory secure WebSockets connection (
wss) - Latency threshold (eg
<200ms) - Implement proxy server
Idea: create a website like https://ethereumnodes.com/
1 Like