yuqi’s Designer’s Take is a view of a visual way.
Here we see a more technical objectve point of view.
And did: Web5 seems to be a hinge to be able to combine both worlds. The more optical, depending on manual user interactions, such as D.id and the very technical technology used for the function, such as one-time stealth-addresses to carry out a one-time address for the function.
In the light of what regulators of different laws are currently being admitted and may be considered permissible in the future, we should describe for new processes automatically generated addresses as process-specific and we should refrain from placing them in a confidential- or in the privacy- corner.
Ultimately, every transaction can be assigned by the right key and it is not necessary to anticipate the reason for assignments. In the end, it is best practice to have a specific address for a specific transaction. The accumulation of many different actions about a certain address is usually not desirable and should at most be visible to the user with a private key. The example of Monero may be interesting: private and public cryptographic keys, with the private view key required to view all transactions related to the account.
Since you can write sufficient user-information with less than one hundred CKB, we are in a remarkable position. Even if old addresses are replaced by new ones, this can only mean to carry out a transaction that makes one cell die for which a new cell is then created. This would even use and strengthen the ability of CKB intrinsically. The native layer1 asset would become a further part of the basic functions of low levels. The existing hurdle, locking 62CKB for a cell, would be supplied with further use. It would be another explanation for users: A user -specific space must be available in order to assign addresses and associated keys. For a complex, interoperable Smart Contract Platform, this is only understandable; it does much more than a transfer from one person to the other person.