hahah, literally compete with Dfinity on everything. itâs actually comical (or should i say tragicomical).
Stuff like this makes @infu claims much more believable, If they donât like the SNS design why havenât they communicated their doubts in the forums? They say the SNS has âsignificant issues that wonât meet the needs of most projectsâ, so what are they? Why release an alternative framework instead of forking the SNS and modify it?
Not sure itâs a particularly good idea considering Dfinity is the biggest Crypto R&D team in the world and has 270+ employees, lol
They should start focussing on one product and perfecting that. As the old saying goes âjack of all trades, master of noneâ
Thanks for the allegory, let me build on it.
If NNS & Dfinity are a country - Is it ethical to let a popsicle brand advertise itself as healthy food while having a little bit of heroin in it? Children will be happy (for a while) they will love it. Parents will be happy having calm kids around. Investors in the popsicle brand will be happy, short term their stock will be skyrocketing.
Do we poll the drug-induced children & the popsicle brand on what to do next and how to run the country?
Could you please give a few examples of issues you face? Thatâll be useful to understand how necessary the 2-step transfer is. I implemented this flow as an exercise; it adds a lot of complexity to the ledger. We need to be 100% that we canât do without it before making it obligatory for all implementations.
100% against this forced and rushed consolidation of a âmake everyone happyâ standard, especially since it seems to add a fair amount of overhead, code complexity, and required future maintenance.
Instead of consolidating, DFINITY should focus on tooling that allow developers to more easily tag & inspect other canister interfaces in order to interact with those payment flow signatures.
3-5 main token standards will develop, and will have financial incentives to organically collaborate in order to provide interoperability with one another and to reduce friction.
This decision doesnât need to and shouldnât be mediated through DFINITY, and Iâm surprised this standard will be solidified by the current plans for it to be integrated into the SNS and BTC ledgers.
The standard is not forced nor rushed. We had several iterations around it and we are naturally reaching a good state for the standard. Thatâs why we started coding it.
Parts that feel rushed can be factored out of ICRC-1. We can always discuss about them in future sessions and add them to a standard that extends ICRC-1.
I strongly encourage everybody to participate and push back against complexity. The complexity of the standard can be decided by the working group.
Having 3-5 token standards for fungible tokens seems counterproductive. We should provide a nice experience for users and Iâm pretty sure you canât do that with so many standards. Incidentally this is the reason why a part of the community was interested in this effort.
Note that it may end up that the standard is compatible with existing ones. Itâs not necessarily a replacement. That would be great actually.
It actually makes a lot of sense in order to avoid a second ICP Ledger that is not supported. Wrappers are not really an option here unless you want a wrapped token per standard per DAO token.
It seems theyâre succeding though, considering both their standard and wallet is more used than Dfinityâs.
I just had a brief chat with one of Psychedelicâs dev: https://twitter.com/psychedelicDAO/status/1545013761144229888
Looks like they are quite adamant in going forward with their own standard, at this point I think Dfinity should contact directly all major Defi devs and ask what theyâre planning to do with ICRC1, if they arenât convinced and want to go forward with their own solution then we might have to reconsider the work done and go back to the drawing board. Iâd also be curious why Psychedelicâs objections have fallen on deaf ears, they seemed quite frustrated with Dfinityâs practices.
Parts that feel rushed can be factored out ICRC-1. We can always discuss about them in future sessions and add them to a standard that extends ICRC-1.
Iâm not sure how convenient this is, with my limited experience Iâve come to the realization a token standard isnât something that should be iterated on, especially not the way we are planning to do. If we want to extend it with new features that makes the old ones outdated weâd end up with a bloated standard, services will have to support many payment flows and even worse projects will either have to miss out on new features or migrate to a V2/3/N canister.
I think we should stop for a second and ask ourselves: Why release an official standard as soon as possible?
- ckBTC
- SNS
- Kickstart DeFi
DeFi wonât benefit from an interim standard that isnât widely supported, SNS is meeting lots of critics and should also be slowed down to act upon communityâs feedback and imo ckBTC can wait if we can get a more solid standard that can be implemented without ever looking back as a result.
Lots of interesting ideas have been rejected during WGs cause they would have delayed the standard, it would have been nice to know by how much and in case of prioritization what would have been put on the backburner to prioritize them, e.g ETH integration delayed to implement named callbacks. Then we could have a community vote to decide whatâs the best course of action.
I would agree with this analogy if what theyâre building is patently damaging, which I think the opposite is the case for the reasons I typed out in the post youâre replying to. I think of ICP as a platform that can absorb all demand, because itâs so flexible it can do anything. I prefer to have more options available for any service, that I can use my personal judgment to choose from, not less options, I donât want âexpertsâ to force me to use this or that service. Itâs on you to prove that psychedelic has heroin in it, your post on their intent is borderline conspiracy theory at this point, unless you have information youâre not sharing.
ânoooo I donât want independent developers that disagree with dfinityâs approach to build their own serviceâ
Really dude? You understand what open infrastructure means yeah?
Dfinity has had an ultra conservative approach to their services, example they want to whitelist projects through the NNS first, so Iâm actually glad a more open alternative is being built. DFINITY could just use the NNS to have a subsection of the SNS as âverifiedâ or âsafeâ and allow people to filter their options in order to be under the wing of âexpertsâ IF THEY SO CHOOSE. Instead of literally denying the service to initiatives they donât deem worthy and denying people that like to judge by themselves the opportunity to take risks.
I think NNS controls SNS. I think itâs necessary. Letâs take a look at the titanium chain, the coin security smart chain, and the fire coin chain. If you want to issue coins, you can issue coins? What concept project can be launched? After selling money, the world evaporated. In terms of project quantity, most of these chains are rubbish. The ICP launched by cheating people and money must break through their model and become a high-quality chain. I support NNS control SNS.
If you donât want NNS to control SNS projects but want to develop on IC, you can give up SNSâs coin-issuing mode. SNS is not mandatory.
So why not leave things as they are and let them play out?
Here a sequence diagram demonstrating the current flow (without the new approve-commit)
Legend:
Account - AccountIdentifier - AID
Treasury account - One account where all tokens are gathered (eliminates the need to store in memory every RCA clients sent tokens to)
RCA - receiver controlled account. Generated with accountIdentifier.fromPrincipal(reciever_principal, subaccount), where subaccount could be:
- random
- the client accountIdentifier
- id obtained from Receiver
I usually end up using (2) because * client can easily resume - itâs always the same * Receiver doesnât have to store anything in memory * Receiver can only let Client with the correct Principal to use the notify function and nobody else
You can make your own easily here: https://sequencediagram.org/
The code generating this one:
title ICRC-1 Successful transfer & notification
actor Client
participant Ledger
participant Receiver
Client->Ledger:transfer tokens to receiver controlled account (RCA)
Ledger-->Client:transfer successful
Client->Receiver:notify
Receiver->Ledger:query balance of RCA
Ledger-->Receiver:balance
Receiver->Ledger:transfer tokens to receiver treasury account
Ledger-->Receiver:transfer successful
Receiver-->Client:success
Here is an even faster flow
Cons: it depends on a query, which only asks one node, not the whole network, so it may not be as secure?
Receiver has to implement a collection mechanism which will gather all tokens at some point, otherwise using them is hard
This is what the flow should look like imo:
The flow shown above would be extremely easy to use, potentially removing the need of 3rd party wallets or services for many interactions and set the IC payment flow apart from other chains.
There would be a place also for approvals with customizable expiration, but itâd require scalable storage and weâd have to figure a system to counter bad actors storing thousands of extremely cheap approvals to drain the ledger, Itâd be nice to have but not a must.
If âReceiverâ is a canister then then the âquery balanceâ call is also replicated, i.e. essentially executed as an update call.
If we are going to use notify inter-canister call, then it can be reduced to this.
However, we are told that inter-canister calls going to an untrusted canister can be dangerous.
https://www.joachim-breitner.de/blog/788-How_to_audit_an_Internet_Computer_canister
What I am doing in Anvil is having all my canisters in a safe space where they can call each other and authenticate themselves. So I use notify coming from my Ledger canisters. And I wrap ICP for faster use.
The only drawback to this is that if someone from another ecosystem wants to use my canisters, they have to - (A) wrap ICP with my wrapping canister
(B) - pay with cycles (so far it looks like this is going to be the universal payment method for services because itâs built-in in the language and we canât mess with it) @lastmjs suggested we handle ICP the same way, and its a good idea. (But then, how do we make other tokens work beside ICP)
(C) - pay with my own token
I thought about this approach, but it would imply if the service canister is malicious and never returns anything, the user wouldnât know what happened without querying the ledger. With the flow I proposed the user would be notified of tx result so he knows for sure whether the tokens have been transferred and then he gets to know from the service if he got what he paid for.
Named callbacks would fix this issue, but its a complex task which would delay the standard by many months (not sure how many).
Now here is the real puzzle. This is the challenge token standards (flows) need to be solving, because they are just a crypto primitive used to build bigger machinery.
Atomic swap means you synchronously make the swap or you let clients get a refund. There is no asyncronicity that can somehow drain someoneâs account without returning them what they paid for. Itâs just not possible, you always get what you pay for or a refund.
In reality, it seems we are always exhanging one token for another. Even if it is a token for a receipt (a receipt is a token). You may say - but I am just increasing a number in memory in return (but well⌠thatâs what tokens are)
So basically each actor fills their RCA1 and RCA2 accounts with whatever they want. The simplest - two tokens in two different ledgers. Or it could be a token for nothing (Which is a simple one-way transfer). But it could be 2 NFTs + 1 FT against 2 FT + 1NFT like in the picture I have shown (part of Anvil designs)
What really happens under the hood is this:
Cons + puzzle: How do we notify ONE and TWO that the swap happened, Do we use timeouts. If we use timeouts then if TWO is a canister, then does it use heartbeat to constantly poll for an answer? What happens if ONE and TWO are canisters. Or there is another way of notifying them.
Maybe the new approve-commit changes solve it? Maybe not? Does anyone feel like drawing them?
title Atomic swap
actor ONE
actor TWO
participant ICP
participant BTC
participant "Receiver (Custodian)" as Receiver
ONE->ICP:transfer tokens to receiver controlled account (RCA1)
ICP-->ONE:transfer successful
ONE->Receiver:notify
Receiver->ICP:query balance of RCA1
ICP-->Receiver:balance
TWO->BTC:transfer tokens to receiver controlled account (RCA2)
BTC-->TWO:transfer successful
TWO->Receiver:notify
Receiver->BTC:query balance of RCA2
BTC-->Receiver:balance
note over Receiver: Swap internally the owners of RCA1 and RCA2
note over ONE: Wait for timeout and query Receiver
note over TWO: Wait for timeout and query Receiver
ONE->Receiver: request tokens
TWO->Receiver: request tokens