I’m absolutely not ignoring it. I’ve been one of the largest proponents of derived canister IDs as a resolution to this problem since the discussions started.
I had a call with Psycadelic who was one of the biggest dissenters from the direction that ICRC-1 was going and had been a principal-only advocate since day 1 on July 26th 2022 where I explained the exact problem you are mentioning. Custody of funds should be kept by canisters in distinct accounts. Together we identified that there was an existing derived canister id pathway in the specification that could give a canister multiple principals. They presented the thread here: DIP20 Community Proposal (PsychedelicDAO)
Soon after they left the ecosystem and there was not enough follow up. In an ideal world we would have implemented derived canister ids and ICRC1 would not have needed a subaccount. The principals of a canister would have been derivable via a standard BIPXX like interface and users would have been left with a simple principal-only interface.
I’ve tried bringing these back up multiple times such as here: Derived Canister IDs
The meetings were open and all were invited to participate. Those who didn’t participate forfeited their voice. The discussions took place over months and all the steps along the way were published. Attempting to backtrack two years after the general consensus of those who cared enough to show up is counterproductive.
Here is why account ids are bad: You can’t get rid of the concept of principals due to canisters needing them therefore you end up with two identifiers(accountId for something, principals for others). No one wanted two identifiers. It was confusing to developers, wallet creators, and users. There was an absolute consensus on making sure we only had one kind of identifier and unless we had derived canister IDs it was going to have to be principal + subaccount if we wanted canisters to hold funds in separate custodial accounts(as you have just mentioned). We also couldn’t revert to only account ID because it is a one-way hash and we would have had to keep a dictionary of all one-way hashes on all replicas(at the replica routing level) and that was seen as an exponential and untenable solution.
Sending tokens to a canister that you know as a principal at a different account id is confusing. No one wanted that anymore. It was ubiquitous and complete agreement.
If you can come up with a way to use account ids in place of canister id/principals and solve the problem of needing a translation table for routing at the replica level then please present it.
Other wise you’re just asking to perpetuate a system that everyone seemingly agrees is confusing by having both account ids and principals.
@timo: I’ve tried to copy/paste the discord history here: https://docs.google.com/document/d/1V3DzYIlucX2xXVtmVP5BXDQlu_XNryaHgcS6Ai8CS0c/edit?usp=sharing
It doesn’t do a good job with images, but most of the discussion is there.
This is an artifact of needing to get something out of the door. The basics of ICRC-3 that specify that had been discussed but it was agreed to move it to a different document as to not slow down the release of the initial ICRC-1 standard as DFINITY was waiting on the standard to release the SNS.