A service can hold the funds of both parties or one party (in escrow), and then give out the funds by the rules of the trade, like in the sns-auction-canister.
Is there a practical benefit for a service to hold an approval (in escrow) instead of the funds?
There are differences in holding funds vs holding approvals. The main one is where the tokens live. In the first case, the funds are in a service account while in the second case they are in the user account. I can see how the latter option may be useful, e.g. approving multiple services to access the same funds, but the benefits for DEXs are not very clear.
My view is that a DEX could use subaccounts and work with locked funds (as you seem to suggest in your message). Subaccounts remove most of the issues related to lack of funds during a transferFrom and, by consequence, remove a lot of pain in writing exchanges and reduce the cycles usage. A minor downside of subaccounts (besides having funds locked) is that the fees needs to be paid twice: once from the user when transferring funds to the DEX and a second time from the DEX when completing the transaction.
DFINITY position from the very beginning was that one could do most things with just subaccounts, transfer and balance_of. The remaining set of things could be done as separate services. Perhaps we failed to explain and support the community for implementing protocols based on this API, but the result was that DEXs did not support ICP and considered wrapping ICP in new standards.
2 Likes
Letâs be honest here, some DEXs chose to do this for political reasons to create a different standard, not because Dfinity failed to explain how to use subaccounts.
2 Likes
Why would that be the case? A different standard forces users to wrap tokens which isnât ideal for the Dex
How did they find that complex. Itâs literally done with 5 lines of code in a function you can tuck somewhere. Then you just need to pass an extra subaccount parameter.
I want to emphasize half of the community
Letâs call it for what it is?
Since the beginning of personal computers, there is a war. Itâs a war for the interface (the frontend).
Windows vs Mac
These two were perhaps the first to realize it. Whoever owns the interface is the dominant power. The battle is fought subtly so attacks canât be proven. One way you fight is to make custom interfaces, patent them, and get people used to them (hooked). If possible throw your interfaces for free in kinder gardens so future generations are secured.
Law 1 - The one who owns the interface has the power to change the backend as long as users arenât bothered.
Law 2 - The majority of users will never leave their âfavoriteâ interface even if they are offered a superior one.
The harvest - At some point, the dominant power will monetize, and in Windows example, thatâs Microsoft Office apps and the browser - installing apps by default and killing the competition.
ây2k - MICROSOFT IS RULED AN ILLEGAL MONOPOLYâ
Netscape vs Firefox vs Safari vs Chrome vs Internet Explorer
Internet Explorer was installed by default on Windows. It made early web devs (like me ~ 1998) life miserable. Microsoft made sure a dozen of critical W3C (internationally agreed-upon specification) html+javascript standards werenât working the way they should. Microsoft were economically incentivized to slow down standardization in IE as much as they can. A web developer had to basically write the whole app two times. It didnât make sense to write it two times if only 5% of your users use other browsers using the W3C standards. So you just ignored them unless you were in Fortune 500 or you made your web apps dead simple. It took the world painful ~16 years of polyfills & ugly javascript & billions of human hours wasted to get rid of IE.
Web and iOS
The same battle again. One of the reasons Dominic Williams was annoyed at iOS while trying to make video work for the Proof of Personhood app. There are a lot of features from the web browser intentionally removed by Apple or just made bad. If the browser on iOS is too good, it will make the marketplace obsolete. Apple enforces ~40% commission from apps in the marketplace and they canât take anything from web. It will probably take another two decades and a lot of angry people for things to get fixed.
Conclusion so far
Letting someone control the interface is a trap. Maybe a lot of developers on the Internet Computer donât realize it and are tricked by the offered convenience. Do they know what they are getting into? Isnât it the job of experts to warn them? Will Dfinity warn these developers? After all, Web3 is solving that huge problem and for once a DAO can control the interface, and browser extensions canât be DAO owned. Instead of using what IC is great at - avoid another decade-long interface battle that will cause a ton of pain to all developers, Dfinity is promoting the Plug wallet on the front page. Junior developers
and hackers are sent straight to it. Users always prefer the convenience and if experts donât pick a side, they will always get tricked. So we created our own monster and now we referring to it as the âpopular community choiceâ when it comes to modifying core standards? The communityâs popular opinion is that everyone should use Plug wallet, meanwhile, the big dapps in our eco DSCVR, DISTRIKT, NNS, realize whatâs happening and are using only the proper thing - Internet Identity.
Why change the standard used by the current ledger?
My guess is the DIP-20 standard folk wanted to move to Principals and delete subaccounts and AccountIdentifiers fully. They probably met resistance because this means canisters canât have multiple addresses and also itâs not backward compatible. So all came to the conclusion, that they have to add multiple flows in one standard, so everyone is happy. ~not good.
How do the flows supposedly work?
Legend: ledger - canister holding the token. dex - a canister trying to work with ledger
-
The old perfectly working flow using reserved subaccounts and the current very simple standard
1.1 (UI: makes one call to ledger)
1.2 transfer to reserved subaccount (no cost for dex)
1.3 (UI: makes a second call to dex)
1.4 dex sends a query call to ledger checking balance (cheap)
1.5 if itâs full it sends an update call moving reserved funds to its main subaccount (expensive, but not a problem since a fee can be charged)
== speed: 2 update calls and 1 query
== note: dex makes 1 query call, but query calls are really cheap. If someone wants to DoS your canister, this wonât contribute, because just receiving update call costs a lot more. -
The new way (correct me if I am wrong, just guessing here)
2.1 (UI: makes one update call towards ledger)
2.2 calling icrc1_approveTransfer which supposedly will let dex call ledger later to move tokens.
To implement this, a ledger has to add stuff to its memory. This means it has to take a fee right at this moment or it exposes itself to a critical vulnerability.
2.3 (UI: makes one update call to dex)
2.4 dex query calls ledger.allowance with approvalId to check if itâs all good
2.4 dex update calls ledger.icrc1_commitTransfer to finalize transaction
== speed: 2 update calls 1 query
So, we are basically not gaining anything technically, except transitioning to a supposedly easier system for DIP-20 developers and Plug wallet enthusiasts. They will just pass a null subaccount and wonât have to use these terrifying ~10 lines of code to handle AccountIdentifiers.
Maybe I am wrong and we did gain something? I have yet to hear what it is.
In reality, we are losing, because we abandon a simple system with AccountIdentifiers flow and implement the approveTransfer flow which requires us to add 4 more functions and we keep more things in memory. So we will end up having few ways to do the same thing, more possible errors, more code for token canister developers to write. What will happen is, not all devs will get on board and will keep using the old simple way.
Current standard which looks like this:
âŚand used for at least 8 months now will be changed to something pointless. I will definitely NNS vote with Reject.
Literally, everything Psychodelic has done so far is an attempt to take over power from the Internet Computer ecosystem. I hate to break it to you, but this is a hostile takeover at daylight.
Plug - control of the interface and users. (Only that should be bad enough)
Cap - control transaction history.
DAB - control token registry.
XTC - control the wrapped cycles
Terabethia - control the bridge to Ethereum
Cover - control canister code verification
ICNS - control .icp domains
Unless we want this to be called Psychodelic Chain and not the Internet Computer, we should all steer clear of their âkindâ convenient offers. And absolutely not allow any attempt to alter core token standards for no beneficial reason.
I would advise Dfinity to reduce its Plug & Psychodelic advertising on its pages It is all made to sound like the abovementioned systems are the official way of doing things. It would be more clear if users/devs are guided and things are more clear. Make it look like what it is - We have NNS ecosystem, then we have Psychodelic ecosystem, and so onâŚ
Psychodelic can demonstrate I am wrong by discontinuing Plug and moving their services to Internet Identity and using AccountIdentifiers.
What will happen if the takeover is complete - We will all have to pay for another coin to keep things secure and decentralized. My guess is, at least 50% of ICP market cap.
Letâs get back to Law 1 - The one who owns the interface has the power to change the backend as long as users arenât bothered.
This means the Psychodelic ecosystem & interface can feed on the Internet Computer, grow big, then move to its own network and abandon the NNS without users feeling a thing.
Then ICP will lose all of its value.
You can do everything and all the DeFi you want with what we have right now. The reason devs donât do it and I donât do it is because itâs risky or they wait for SNS.
We need to improve frontend security, dfx security, figure DoS & multi canister scaling, certified canisters, distribution of tokens, proof of personhood, DAO controlled canisters and figure upgrading types. Itâs not because we need these 4 new functions.
These are all connected and will result in a proper DeFi when done. Whoever is rushing into DeFi now is taking a lot of risks just to be first.
Ofc I will be happy if someone persuades me otherwise. Thatâs how it looks to me looking from above without any internal information. I will publically apologize if I am proven wrong and even join Psychodelic. (Never met them, maybe they are wonderful people and I am just paranoid).
18 Likes
In my opinion there are 2 reasons why the official standard wasnât widely adopted by the community:
- I noticed many devs are so used to the EVM style of doing things they want to force that approach into the IC too.
- The official standard works well when sending tokens to other users but not so much when you want to pay for a service.
Over the past week Iâve been trying to figure out the best way to do it and it seems like you either use Plug, which makes it easier but canât be run on testnet, or with II but from what I understood you have to move the funds from the NNS wallet to the principal generated by the dApp, which makes it quite tedious and less secure when compared to a Metamask style wallet where you can keep all funds in the same place and ideally protected by an HW.
Token standard discussions should have been started way sooner and the features needed for a better payment flow should have been prioritized, the community should have realized where we were heading but Dfinity is also at fault here, I know they have lots on their plate but they should have known there is no point in having an SNS or BTC integration if you donât even have basic DeFi figured out.
Now I fear the âget something out as soon as possibleâ approach will cause issues in the future when better standards will be discussed, at that point Dfinity will either have to keep the new standards bloated to make them backwards compatible or break retrocompatibility, either way tokens created with ICRC-1 wonât be able to benefit from the new features unless they migrate to a new canister, which isnât ideal for the ecosystem.
That being said I donât have anything against Psychedelic but they should stop creating new projects and try to become the standard for everything, I havenât heard anything about Terabethia for months, Plug canât be run locally or paired with an hardware wallet, ICNS is shady and Iâm sure the other have issues too.
1 Like
The IC is far too different from Ethereum for the EVM style argument to hold water. You program in Rust and Motoko, accountidentifiers are nothing in comparison. You can also use the InfinityWallet, which letâs you mint tokens from a test-ledger to get started. Much more convenient for devs.
The IC did have a payment flow that worked fine⌠it should have been advertised as the defacto standard rather than to allow members of the community to try and take market-share by force, effectively splintering the IC.
2 Likes
The IC is far too different from Ethereum for the EVM style argument to hold water
Thatâs my opininon too, but based on what I heard and saw many devs want to replicate what they used to do on other chains here, otherwise why would there be so many alternate standards following the approve/transferFrom flow?
The IC did have a payment flow that worked fine
Fine was not enough for many I guess.
rather than to allow members of the community to try and take market-share by force, effectively splintering the IC
How do you tell the difference between healthy innovation and market share take over? Infinity Swap came up with its own standard and wallet too, why is it bad if Psychedelic does it but okay when itâs another team? Dfinity is building a decentralized chain so I donât see how they could have prevented fragmentation other than by intervening sooner, instead of letting everyone do his thing when it was clear there wasnât much of a discussion going on.
I have to try it, but still this is far from ideal, if I donât have any particular need like doing batch transactions or interacting with a custom token, there shouldnât even be the need of a 3rd party wallet.
My use case is pretty simple, send ICPs to a canister and have the canister update the balance of the sender in a hashmap, as simple as it gets, in a perfect world the canister would get a notification from the ledger canister that a transfer has happened with all the relevant infos (amount,sender, memo, etcâŚ). Sending the tokens from the NNS wallet should be all that is required for such cases.
Infinitywallet exposes the same interface as agent-js.
I donât see how that has to do with my previous statement, but Iâm new to IC development so perhaps Iâm missing something.
The way I see it there are 2 payment flows worth having in a token standard, everything else is a stop gap that will only cause issues in the future:
- transfer/notify, this could have implemented in 2 ways: one that requires new tech and another one based on a notifier canister, which iirc was proposed by you.
The cons of the latter were it made the standard more complex and in case the notifier canister was replaced, all services would have required an update, the formerâs cons were it would have delayed the standard by a lot.
After giving it some thought I have come to the conclusion, both would have been better than the current interface. Why is that you might ask. We are rushing a token standard in a period when there is no need to rush anything. 1 year ago having a working DeFi, SNS and BTC integration may have done wonders for price action, but now I doubt any of those will affect price in the slightest.
If I were building a dApp Iâd rather release a testnet with a temporary standard and wait for a more scalable and easy to use one than go live with a ledger that has been rushed, especially considering there is barely any hype going on and even big projects like Orygin have troubles selling their NFTs.
What we should focus on is providing dev teams rock solid foundations they can use to build their product and be ready for the next bull market, not give them a bandaid that will only cause headaches in the future when theyâll have to figure out how to upgrade their ledger.
If Dfinity and dev teams value time to market more than a proper ledger implemenation, the notification canister approach would have been preferable over âDIP20++â cause:
-
It would have got dApp devs used to use the notify pattern, so once we get named callbacks the switch would have required less effort.
-
Risks caused by greater complexity could have been mitigated by security audits and services will have to update regardless in the future if new standards come out and ledger migrate to a V2 canister.
-
approve/transferFrom with customizable expirations for approvals, this one was proposed by @lastmjs and would allow some interesting use cases, the main issue was storing all those approvals isnât possible on a single canister at the moment.
There is also something else that hasnât been considered in the WGs: ledger scalability. If Enoki devs are to be believed: Why do we need sharding? - Enoki Docs, the proposed standard wonât be much scalable and if nothing is done to improve the situations pretty soon all ICRC-1 based tokens will have a terrible UX. I still have some doubts about their findings cause the ICP ledger also runs on a single canister and it doesnât seem to have any issues. Scalability should have been a topic of the WGs though, figuring out the limit of single canister ledgers is important and we should have considered multiple canister approach for the same reason stated above: upgrading ledgers will be messy. We have the opportunity to gather years of experience from the EVM world and use cutting edge tech in the blockchain space, letâs not make the same mistakes ETH did and and up with a bloated that gets bloated over the years.
2 Likes
Psychedelic can demonstrate I am wrong by discontinuing Plug and moving their services to Internet Identity and using AccountIdentifiers.
I agree with you but there are a few issues:
- II is not as accessible as it should, so as much as I dislike it, the Metamask like approach is needed at the moment if we want wide spread adoption.
- From my understanding there is no way to achieve a wallet like experience, with all your funds and NFTs easily accessible in one place using II at the moment, the closest thing might be Stoic, which has II login but isnât secure apparently. dApps with II login generate a new principal, so say you have ICP on the NNS wallet, youâd have to move them to the newly generated principal and then you can spend them, itâs tedious, less secure and Iâm not sure what would happen if the dApp shuts down.
That being said I hope we get to a point where we can leave behind the outdated Metamask like wallets and embrace II/NFID fully, all the wallets available at the moment are all quite similar: metamask clones that do the same thing slighly different with no hardware wallet support, in my opinion they contribute almost nothing to the ecosystem and just cause further fragmentation.
Well, not only that but canisters using the notify flow with a separate notifier canister would not have needed to be updated. There would be no reason to deprecate the old notify method when the new notify flow with named callbacks comes into play. Both could have been used. Itâs not even a disadvantage.
if it absolutely had to be replaced, the IC could have employed another deployment pattern, by proxy calling a notifier canister. If the notifier canister needed to be replaced it could just be swapped out for another canister. So in effect upgrades would have also been possible.
Do you realize that youâre saying building (very much needed) infrastructure equals a perverse takeover?
As a member of the community that advocates for Plug as opposed to the II every time I have a chance to Iâll tell you why I do:
- itâs a familiar interface (metamask)
- I donât have to buy an extra piece of hardware to use it across devices. (Massive point, especially for third worlders (me), one of cryptoâs target demographics)
The NNS up until recently was an absolutely horrible experience to use, and Iâm glad thatâs changing (and love the sns), but naturally people gravitated towards the services with not so terrible interfaces, and especially not so alienating ones. And the alienating point is relevant too because it makes plug not really a competitor of II or the SNS, but an alternative for people that prefer to stick with what they know, and this is how I felt when I started navigating the ecosystem myself, if the only means of authentication on ICP was the II i probably wouldnât have stayed in the ecosystem, especially given the horrid marketing weâve had, so I think youâre making the situation a lot more adversarial than it should be.
I think psychedelic should be appreciated as a group of people that decided to build high end infra and other awesome products in an ecosystem in such a tough spot as ICP was and still is today.
In simple words, instead of crying to daddy to force people to lick this or that popsicle try to make a popsicle people want to lick, you have an absolutely anti-crypto mentality imo
Pd: I am however in favor of incentivizing psychedelic devs to engage in the forums if theyâre not doing so sufficiently, since theyâre such an important actor in the ecosystem
1 Like
All I can see that Psychedelic has done is bought out a bunch of projects/devs that serve their purpose of becoming the front-end for the IC. Havenât seen much innovation from them.
We donât need Plug Wallet, when there are so many wallets on the IC - NFID, Earth Wallet etc⌠We donât need Cap. Dab kinda borderline useful, but only because Dfinity failed to set a token standard for NFTs. Terabethia is like pouring money down the drain given the ICâs native integrations. ICNS was bought out and thereâs already IC Naming.
Yeah, not much innovation, just VCs at it again. I heard Psychedelic has a multimillion fund to invest? Which explains all the corporate acquisitions. It would be nice if there were an even playing field for projects. Does one entity really need to be doing NFTs, Tokens, wallets, exchange, bridges, aggregators, code verification. Might be better if they just chose to do one thing well lol.
3 Likes
Let me begin by attacking your premise, what do you mean by âwe donât needâŚâ? I donât understand the thought process here, the service is there and people choose to use it, period. NFID wasnât a thing until a month ago, and I love NFID btw, it solves the problem I mentioned above about authentication across devices. And Earth Wallet is just there, i donât understand your expectation in mentioning competing services, I donât think Psychedelic invented the internet or cured cancer, I think they were very proactive and built services I personally appreciate (Plug, Jelly, Crowns (the nft, not CAP the service)). And if we donât need CAP why is it being used?
IC naming had an horrid execution, and Iâm telling you this owning a bunch of amazing IC naming domain names.
Iâm not aware of their resources, I honestly thought they were a bit amateur because their UIs arenât very appealing, I donât really like the Jelly logo, etc. But they do seem very quick, and somewhat aggressive in how they operate, which I donât have a problem with but understand that other actors in the ecosystem may perceive it as negative, case in point is IC Naming. I hope no one stops building on the IC and that communication between all parts happens in order to avoid unnecessarily adversarial behavior
I heard they were a $200 million fund. But I donât get why they donât do more to promote the IC from an even playing field and invest like normal investors. Donât get why they buy out projects and force them to use alternatives to the IC, undermining the IC. Terabethia vs native integrations, plug vs II/NFID and this new dip20/ 721 token standard lol⌠they could do a lot more to support and empower the IC rather than compete with literally everyone with their money.
1 Like
The only point I could agree with you about is terabethia, I donât understand why theyâd pursue a traditional bridge over a native integration, I know theyâre developing a game on ETH and are planning to use the IC as part of the back-end of the game so that may have to do with it. I really donât see Plug as a threat or even a direct competitor to II/NFID for the reasons I listed above and I think it absolutely is positive to have Plug as an option and if anything have a slow transition to II that is on par with peopleâs learning curve. I personally use both and can see II becoming the standard but we are not there yet. When it comes to their funding I donât immediately see reasons to care, I want the ecosystem to grow at the pace theyâve been proposing, the IC needs to outgrow other chains. We canât afford not to.
1 Like
More than building infrastructure to me it seems they start a bunch of projects to have first mover advantage and get dApps locked with their services, would have been better if they stuck with 2/3 projects but actually developed them with a steady pace. Plug, their most used product, still doesnât support hardware wallets and canât be used for local development, itâs ridicolous.
The only point I could agree with you about is terabethia, I donât understand why theyâd pursue a traditional bridge over a native integration
I disagree, Terabethia is the only project which in my opinion they should have focused on, native integrations take time to implement and we will never have all chains natively integrated so bridges will always be needed. Now it makes sense to have an ETH bridge cause the native integration is at the very least 6 months away but for DeFi to start we need liquidity and tokens, which ETH has plenty of.
1 Like
What do you think about Enokiâs implementation? It seems to follow a similar concept but with sharding on top
1 Like