In Polkadot 1.0 wallets contain different addresses for each parachain and you must transfer tokens from address to address. This is non-user friendly and isolates parachains-- you could argue this very much hurts mainstream adoption. Ideally, you would have one wallet address that could be used to interact across all protocols seamlessly(like ETH smart contracts).
In the current JAM concept, would wallets have different addresses for each service? Would you have to transfer tokens/NFTs/etc. from service to service? or would you have a single JAM address that allows you to seamlessly interact with all services, protocols, tokens, NFTs, etc.?
Addresses in Polkadot already can work the way you described, with one address across all parachains. See for example that your address is the same on the Relay Chain and all system chains.
Huh I didn’t know that was possible. The thread seemed to have ended a little over a year ago, what ever happened to it? It would be nice if JAM launches with this sort of standard built-in, because retroactively adding it by the community seems like it either will take a long time or not happen at all-- not good especially considering how critical it is for the user experience.
With SS58 how would trading on hydration work for example? Say I got onto the DEX and want to trade DOT for USDC, will the DOT balance on hydration show the combined balance of all my DOT across parachains?
Let’s say I have 3 DOT in the asset hub, 2 dot on the relay chain, and 1 DOT on hydration. Will hydration show all 6 DOT as tradeable and could I trade all 6 instantaneously for USDC? or will I still have to bridge the DOT from the asset hub and relay chain onto hydration as two additional steps? If users still have to do the cumbersome bridging it won’t really make anything simpler or more streamlined and might be even more confusing.
The composability we need, and I hope will be in JAM, is the ability to make contracts leveraging multiple protocols without having to bridge.
You are confusing different layers of the stack – what the UI shows you should not expose the “backend” architecture and sharding. So these standards are not “built in” to Polkadot or JAM, they are adopted and followed by UI/UX developers. What I’m saying is, you should ask the Hydration UI developers to show you the information in the way that you want (which, fwiw, I agree with).
What JAM will bring is the ability to execute your example synchronously. There is also no need to bridge now between parachains in Polkadot, but they could only execute a trade like that asynchronously and with some delay for message delivery. However, it still could be presented as one action to the user.
I don’t think leaving it to the community to develop these standards and create a user friendly experience is a good strategy-- clearly it is not working with Polkadot today. The community itself is fragmented, thus we see a fragmented user experience as a reflection. Sure, on Polkadot 1.0 you can technically create this user friendly experience, but I am not aware of a chain that does this-- probably because its a lot more work to code and develop.
The Polkadot dev team should design the chain to work in this way natively. On Ethereum the community doesn’t have to create a standard and build tools to make smart contracts work seamlessly that just how it works, and my question is will JAM be like Ethereum where everything will just work together naturally?
If it’s going to work like it does today I imagine the user experience will get even more complicated and confusing. There would be little point in making something like JAM technically feasible if its user experience is so bad it is not adopted.
JAM Services all have one account type, so we won’t have the same issue as the different SS58 Formats in Polkadot 1.0.
But JAM services are all super low level primitives. A service has an account, and a service holds DOT. And JAM being transaction-less, I don’t think it is sensible to even describe “User owning an account and DOT on JAM”. As far as I know, only services own DOT in JAM (please double check me here).
For example, the CoreChains service will own a lot of DOT, as it will be the service where AssetHub (AH) will be hosted. Within the service, I am pretty sure JAM does not enforce in any way how accounts are managed, so we fall back to the existing model.
TLDR; As @joepetrowski, the existing parachains should use to a unified address format, and most likely JAM will not alter anything about this.
One thing people needs to be keep in mind is that JAM is an infrastructure. Users never interact with JAM chain directly. In fact, no one can because there is no transaction in JAM chain. User only interact with Services built on top of JAM and one of the service is Parachain service (or whatever it is called).
JAM service holds DOT on JAM chain but that’s some implementation details that user should never need to be aware of.
So first thing, everything we have today, stays (the goods and bads).
It is the JAM applications (e.g. parachains) to decide what account model to use. Most of the existing parachains are using ss58 format. Some of them using ETH format. Some uses both. JAM do not offer a silver bullet to magically unify the accounts. It is still up to each application to decide the authorization and authentication mechanism.
It does offer us an opportunity to think if we can create a new account / identity mechanism. However, this is will just be a new JAM service project. It can potentially solve some problems we have today but it will be a new project and requires a team to spend time to research and build it.
I will image someone can build some SPREE (or whatever the new name it is) application that offers a unified account abstraction and each application can choose to opt-in this service. In that way, we can achieve the goal.
TLDR; it is possible to build the ideal world, but a lot of work and collaboration are required.