The Syrius implementation is nearly complete. The community testing phase will begin shortly.
For those that want to test and provide feedback, would you prefer to compile your own copies of Syrius or do you want me to setup cicd like aliencoder?
2 Likes
I’m able to compile from source, but I guess if we want greater engagement from the community, we should provide them a properly packaged Syrius version.
I’m thinking of using the built-in Sign & Verify functionality from Syrius with PGP keys.
We can generate Ed25519 keys for GPG in Github and map them to an on-chain address.
Not a bad idea, though it’s outside the scope of Atomic Swaps. We can work on it separately.
Based on community feedback and preliminary testing of the Syrius implementation, two new design iterations for atomic/p2p swaps have been made that can be found here. Thanks to @sol for helping brainstorm these ideas.
The “Guided experience” is a version with a high level of abstraction, with verbose guidance and with a minimum amount of affordances given to the user.
The “Primitive experience” is a version with a low level of abstraction that offers nothing fancy and is basically just a raw interface for the HTLC contract.
Both versions are still a WIP and are missing some details.
The Guided experience
The Guided experience would make P2P swaps easier to do for the user but there are certain risks that come with it.
One risk is that such a “sophisticated” user interface may not be that flexible to update when new tech is available that could be utilized to improve the swap experience. E.g. PTLCs or an off-chain messaging protocol. This may lead to us having done work that will have to be scrapped later on to make way for a superior implementation.
Another risk, which is more of a personal risk, is that implementing this design, testing, iterating and making sure it’s rock solid will take time, time that could be used to contribute to something else. Considering our limited resources, is the required effort justified right now?
In the best case scenario this Guided experience will provide users with a way to feelessly swap ZTS tokens with each other and allow users to make cross-chain swaps in a relatively user friendly way. It could also potentially be used as a marketing tool to target the wider crypto crowd.
The Primitive experience
The Primitive experience would be a lot quicker to implement and there would be less unknowns. Also, it wouldn’t be so abstracted which would possibly make it easier to build more sophisticated solutions on top of it later on when new tech is available.
The Primitive experience would require detailed tutorials that guide the user step by step on how to do a swap. I think this could provide a decent experience to the user, although it would obviously require more dedication from the user and probably discourage some users from doing swaps.
The risks with the Primitive experience are that users may see it as being too complicated to use and users may be at greater risk of losing funds due to user error. It would also likely not be as marketable to the wider crypto crowd.
Which way forward
I think both of these options are valid and have different benefits. I guess it boils down to whether there is enough community support for building the “Guided experience” considering the mentioned trade-offs and risks.
5 Likes
Honestly, I think just do the primitive experience for now. A detailed tutorial will provide all of the benefits of the guided experience, but without the drawbacks you mentioned.
A nice user experience is essential for mass adoption and beneficial for marketing, but it sounds like we’re not close to either of those things yet. Better to be smart with your limited time and resources; perhaps SYRIUS v0.0.7 can be the guided version.
And still a WIP, but for the guided version the time could say UTC as people live in different timezones with this global network, and “send the ID” is a bit confusing when there’s no way to msg it … is this what you mean by waiting for nicer tech to make UX even better? You just click send and they receive it within SYRIUS? Otherwise “Copy-paste this ID number and message it to your recipient via social media” is awkward but has better clarity imo
Yes that’s true, maybe it would better to add the GMT offset to the timestamp so the user doesn’t have to convert the time in their head. Something like: 11:26 AM, 11/30/2022 GMT-5
Yeah, for example if we had off-chain P2P messaging capabilites directly in Syrius we could definitely improve the UX for atomic swaps and do stuff like send the deposit ID to the counterparty automatically under the hood and the user wouldn’t have to care about that. But I don’t want to hype up possible future functionality too much because there’s a lot to do to achieve something like that.
I think it’d be best to actually just have a timer that counts down, same as the staking contract timer, since you’re choosing number of hours anyway and need to leave syrius open for the duration.
The more that can be automated, the better.
Are you referring to this popup?
This is the only place where a timestamp is shown in that format. Otherwise expiration times are shown as count downs. In the popup Syrius is automatically calculating a safe expiration time for the deposit and the user cannot set it themselves when participating in a swap.
1 Like
I personally think we should proceed with the primitive experience? Why spend time on something that cannot easily be used as we grow the functionality. I’m happy to make some nice videos on how to use the app and field many questions if that frees up developers to add functionality to Syrius.
@vilkris @sol you guys have obviously spent a LOT of time thinking about this and we appreciate all your hard work.
4 Likes
Well it’s hard to anticipate what possibilities we’ll have in the future and how they could affect the UX. But I do think many of those possibilities are still quite far away, so the Guided experience could serve users for a long time to come as it’s currently designed.
Of course nothing’s stopping us from first building the Primitive experience and then later on building the Guided experience. This just means some extra work overall.
We were counting on that haha. But yes some proper tutorials will have to be made to accompany the Primitive experience so I appreciate your willingness to help. Maybe we could even embed a link to a tutorial directly from Syrius.
1 Like
How does the UI deal with multiple htlcs created under the same hashlock?
Alice initiates a native swap and gives the ID to Bob, but Bob participates in a native swap two times. Maybe it takes to long for Alice to accept, Bob closes his window and thinks he needs to do it again effectivly creating two htlcs. Probably won’t happen often, just wondering how the UI deals with the situation.
Good point, Vilkris and I have discussed this as a possible scenario.
We can’t save Bob from making a mistake in the first place – fat-fingering his entry and submitting the wrong amount to Alice – but we can prevent him from submitting a second HTLC for the same swap.
The UI will not allow users to deposit two amounts for the same incoming swap.
Going one step further, we may also have to prevent Alice from re-using the same hashlock with the same recipient twice in a row.
Same logic for both cases: when creating an HTLC, check if timelockedAddress has already submitted the hashlock to hashlockedAddress.
1 Like
To add to Sol’s message, in a situation where Bob is using a CLI for example and there’s nothing stopping him from making multiple counter HTLCs with the same hashlock, Syrius would only use the first one for the swap and disregard any subsequent HTLCs with the same hashlock.
2 Likes
That’s a good thing, but you cannot prevent the situation from happening when someone uses the cli or the sdk directly. How will the UI handle multiple htlcs.
In our community call regarding the atomic swap layouts, we decided to move forward with the Guided experience.
A simple Figma prototype demonstrating the “happy case” swap flows is available here: Figma
Community members can try it out to get a feel of how the swap flows would work.
The design file for the protoype is here: Figma
2 Likes
I’m pretty happy with the swap flows/steps in general now, so I wanted to make another variation of the UI by replacing the full screen modal with a smaller more “uniswap-like” modal for the swap with further simplifications for the user.
The prototype for this version is here: Figma
The design file is here: Figma
5 Likes
Love the new look. You" will send and you will receive" is easy to understand, and ppl are already familiar with uniswap UI.
5 Likes
Very nice, I like the “uniswap-like” modal. Having the information neatly packed together makes it easier to understand.
5 Likes
I like the uniswap prototype. I think users will be accustom to this type of UI.
5 Likes