Straighten out wallet "petnames"

[michaelfig]

Hmm, there is something about this that violates the concept of petnames. I think there should not be a merge of autogenerated aspects + user-chosen names. The unknown-* defaults are the right way to deal with something that really has no name and no other information. @erights, what should be done?

Originally posted by @katelynsills in #1440

[michaelfig]

Currently, the wallet "petnames" are either primitive strings, or array-of-strings paths whose first element is the Dapp origin and the rest are specified by the Dapp. We don't have a general UI flow for renaming petnames, just for editing the petname for the Dapp's origin letting it specify all the rest.

We should specify a UI design that uses only paths internally (paths with just one element are the legacy "petnames"), whose first element (edge name) maps to a petname, and allows for resolving of conflicts or renaming the petnames in the UI.

It would make sense to redesign the dapp-to-wallet bridge (and wallet backend) to provide a clist, so that the dapp keeps tables mapping clist numbers to paths, so that the names can be easily changed without breaking existing references.

[cwebber]

Just dropping a note that I'm interested in this, both the backend architecture and the frontend, if you all are interested in talking about it. I think it's something we both need to think about and solve soon-ish, and could learn from each other.

[rowgraus]

Notes:
Dean & Kate:

• dapp provides a suggested name which needs to be represented differently
• suggest storing user petnames as strings

Michael:

• Ensure we retain paths as part of suggested naming

@katelynsills @dtribble @michaelfig @erights to discuss

[dtribble]

References from MarkM:

• Architectures of Robust Openness -- Mark S. Miller keynote at ActivityPub 2019 from 39:15 to 47:43
• https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/petnames.md
• https://github.com/cwebber/rwot9-prague/blob/secure-uis/draft-documents/secure-user-interfaces.md are good pair

[michaelfig]

@erights how would you indicate a proposed name for "dapp at https://faucet.agoric.app calls this issuer Foo"?

I've been doing this as an issuer with path from the "Faucet" petname for https://faucet.agoric.app to "Foo". Can such static relationships be part of a naming hub (i.e. no power to change "Foo" to anything else), with the intent that the user can assign a new petname to "Faucet -> Foo" as a whole.

[erights]

Yes, I think you got it. To restate:

If we already have a petname "Faucet" for http://faucet.agoric.app , and it exports an edge name binding the name "Foo" to some object, then starting from out own naming root, the path "Faucet/Foo" designates that object.

The FaucetHub may change its mind over time over what object it exports associated with its edge name "Foo". The FaucetHub can also change its mind about what export name to associate with that object. We can change our own mind about what object to associate with out petname "Faucet" as well as what edge name to associate that FaucetHub object with.

Dereferencing the pathname "Faucet/Foo" at any time is ideally done on terms of the current bindings at that time of each of those steps. Likewise, mapping backward from the object to the pathname for rendering the object should ideally be according to the current bindings. In both cases, they should actually be in terms of the most recent bindings we know about. A screen rendering of the pathname should dynamically update as the appropriate current rendering changes.

Finally, having come to know some binding of Faucet/Foo at some time, we can enter it into our own root petname namespace to give it a name meaningful to us. Once this happens, that binding is subject only to further renamings by us. It does not vary with further changes to the binding of Faucet/Foo.

Did all that make sense?

[katelynsills]

@erights and @michaelfig, it doesn't sound like you are in agreement.

@erights, I think you are describing the dapp being a naming hub, with dynamically updated edge names. In other words, the user has a petname for the dapp, which is Faucet. The dapp has a suggested name (edge name) for the issuer, which is Foo, and which may change at any time, updating the user's UI in the wallet without any user intervention. The user's petname is NOT "Faucet -> Foo". Instead, wallet dynamically asks the dapp "what do you call this issuer", to which the dapp replies Foo. Anytime the dapp replies differently, the name is changed in the wallet UI.

Our current system works very differently than what you've described. The user has a petname for the dapp, which is Faucet. The dapp is able to suggest a name for the issuer (Foo) at a single point in time (which currently the wallet accepts unconditionally if the dapp has been approved!) This is stored statically as a two part petname: ["Faucet", "Foo"]. The user is able to change the petname through the API but not through the UI . There are no naming hubs and nothing is dynamic. In the UI, "Foo" (below "Token") is colored in red but that is the only indication that it did not come from the user.

This is a bad idea for two reasons: 1) It's confusing. It doesn't match any official petname documentation, so the few people who understand petname systems will be unfamiliar with it, and the people that learn this system won't understand petname systems as documented. Furthermore, users don't have a clear idea of what is under their control, and what is under the control of the dapp. And 2) it means petnames aren't always strings, causing significant problems in UI rendering, such as indexing into something that may be an array and in the case it's a string, getting just a character.

We needed something quickly, so I didn't force the issue earlier, but I don't think we should keep this model for the above reasons.

I think there are two different paths forward:

1. Making the dapp a real naming hub, which means "Foo" is entirely up to the Faucet dapp and not the user, and will change dynamically in the user's UI without user intervention.
2. Creating default but editable petnames for the user, based on the the edge name, and only with their consent. In other words, when the dapp suggests a name for the issuer, the wallet offers the user the default of something like "Faucet's Foo" for the petname, which the user is able to change or reject outright.

The benefit of 1 is that we'd be building the system as we intend to use it in the future. The downside is that it could take some time and thought and we don't really have the bandwidth.

The benefit of 2 is that it fixes the major problems without having to do much work. It fixes the issues of sometimes having arrays and sometimes having strings, because now petnames are always strings. And it fixes the first issue, because although we still don't have naming hubs, we only have true user petnames as decided solely by the user. It eliminates the "static naming hub" concept. To implement it fully and safely, we must have UI for the user to edit or reject a suggested name. But until then, it is an improvement over what we have now.

[dtribble]

Let's distinguish mechanics from semantics. The "string or array" representation started life as a plumbing hack. It also has some characteristics that are useful but it's still a (useful) hack. I certainly don't believe that an array is a per name. It's also partly a hack because we don't have a story that hangs together yet. I don't know of any "official petname documentation" if it's not the attached references. I note that the glossaries in the references above seem slightly contradictory and in any case not quite sufficient.

The useful extract from what we hacked, and what meaning I imputed:

Dapps must be assigned a pet name, and it starts from a "self-proposed name" (I think).

Dapps can introduce other things by a name relative to the dapp. You could construe that as a "proposed name". The names presented by dapps are "here's what I told you when we met" so we don't actaully want them to follow along if the dapp changed names. As a history, that original name matters. Even once you assign a petname to it, both the history of it and all the other names it is known by might be of interest.

In this model, dapps in general are not naming hubs. That's currently because we have no support for naming hubs. It's also partly because that would add complexity to dapps. The names that we provide right now are static with the dapps. Obviously dapps should be able to choose to be naming hubs, but it should be optional and separate.

The UI currently visually distinguishes a tiny bit so that we have a PoC that we can visually distinguish these. Since we knew there wasn't agreement about terms, capability, etc., going farther along that route didn't make sense. There's more infrastructure there for giving things unique pet names, and we had a version that showed the history when you hover over a named thing. Those are relatively easy to put back one we have the right underlying structure.

[dtribble]

I think it is simply not feasible to ask for pet names for all the things that app proposes. I think we really want naming hubs and then when the app proposes a particular issuer, the name it picks could be the proposed name according to the user's default naming hubs.

[dtribble]

Notes from @dtribble/@erights conversation

A petname system comprises a graph of naming nodes, connected with names. The particulars are below.

Glossary

We define our own glossary here because the names used in prior docs aren't quite precise enough for use in the general wallet case.

naming node

An object with a mapping from edgenames to other objects. Naming nodes typically have a static set of names. An example is a dapp configuration, which presents a fixed set of named things that it requires.

naming hub

An naming node and provides a dynamic mapping from names to other objects. An example if a name server, or a directory of issuers.

petname

The string name a user chooses for a specific target.

edgename

The name by which a naming node refers to another object.

naming path

A composite name with an initial petname followed by a sequence of edgenames that describes a path through the naming graph.

UI thoughts

• The target should always be displayed using that petname. If the petname is changed, that change should be reflected everywhere in the UI.

• The user should be able to see (e.g., via hover) the set of naming paths by which the user has encountered the named target. This should include dates!

• The naming path which the user initially accepted the object should be remembered. Mark used the term "inertia".

• The UI should NOT follow dynamic renamings of objects. Once the user is introduced to an object via a naming path, that path should be presented until the user changes the name they want to show. The dynamic change can be made visible (e.g., by showing that the object is available with a new name), but the new name should be be imposed on the user.

[dtribble]

A few more notes

suggested names

We also discussed "suggested name". I proposed that as a better term for us than "proposed name", since "proposal" is not central to offers and zoe. It's also more accurate.

In our discussion, we tentatively agreed on "suggested name" for the name an objects suggests for itself. Afterwards, in considering the UI interaction, however, the "suggested name" should instead be whatever name the UI proposes to the user as an initial petname. That is a UI-dependent policy, which might come from:

• the target object itself
• the source naming node providing the reference to the target, for example the a dapp's edgename for an issuer
• the name of the target according to some naming hub of the user. For example, issuer names might be looked up at a directory managed by an exchange, with a suggested name from social consensus.

These all are plausible "suggestions" that users can understand. It would still be useful to have a term for the name that a target advocates for itself. I note though that it's not actually compelling in most cases: just because a new issuer asserts that it wants to be called "eth" doesn't mean it's the issuer of the brand that everyone means by "eth".

Types

In the wallet APIs, names are mentioned with types; e.g., suggestIssuer is different than suggestInstance. In the wallet itself, those are maintained in separate tables. In practice however, we don't seem to need that. Dapps introduce non-overlapping edgenames, typically "Installation", "Instance", and some token name as issuer. Usually only the tokens name's edgename is differentiated.

Alleged name

We use the term "alleged name". It is however unrelated to these naming terms. It is "the name that an introducer claims is the name that the target would like". But as above, that's not necessarily informative (other than for debugging purposes).

Targets

Most targets are just objects, but I could imagine a name for e.g., a governance parameter. All the naming considerations about such parameters apply, but it's just a mutable named slot. I'm assuming that we would just implement such a thing with a named object that has the mutable state).

[erights]

Hi @cwebber , please help us converge on a common theory described by consistent and common terminology. Thanks.

[katelynsills]

A few questions:

• Why not make the dapp a naming hub? My understanding is that there is a very low bar to being a naming hub (anyone and everyone can be a hub), and in many of our use cases, only the dapp knows about the particular issuer or instance they are trying to convey to the user. For instance, the fungible faucet dapp knows the issuer of the token that they are giving away, but probably no one else does. And instances are generally only known to the dapp.

• I'm not sure why we're rejecting dynamic naming. That's been the majority of petname system examples so far. Is there a reason to do so?

Also, about the types: We should retain the types, as otherwise the user must input the type as part of their petname. This is silly, because this is information that should be managed for the user, and the UI should be able to organize and display them based on the type of object. If we find ourselves creating suggested petnames that are like "Instance" and "Installation" we are doing something wrong, either in the display or in the suggestion itself.

[michaelfig]

One design constraint I had was for the wallet to do something sensible when a given website is replaced by a different dapp instance (i.e. a different backend contract instance, and potentially different logic). Users who had names for the earlier instance's token, etc. need to see new names, but users coming to the dapp for the first time should not need to know that this used to have an old instance.

So, the notion of a unique "the dapp" in relationship to the wallet is a weird thing. One web origin is probably the unit of trust for a dapp, but having that origin reuse proposed names should not break the wallet.

Suggestions welcome!

[dtribble]

A few questions:

• Why not make the dapp a naming hub?

Dapps are naming nodes because they provide named things to the wallet. They aren't naming hubs because that takes the dapp from being a simple immutable set of names to a mutable set where that functionality is not necessary for most dapps. Thus, the added conceptual complexity of making all dapps naming hubs is very high.

I note that the wallet is a naming hub, in tht it has a dynamic set of named purses that it makes available to dapps. So having a protocol for a read-only view of a naming hub seems useful.

My understanding is that there is a very low bar to being a naming hub (anyone and everyone can be a hub), and in many of our use cases, only the dapp knows about the particular issuer or instance they are trying to convey to the user.

So I think that's satisfied by the node comment. The current API in which the dapp pushes named things to the wallet works just fine. But if there's a notion of a naming node API, then that would flip the relationship. I suspect for a naming node, just having a format to pass a bunch of named things woudl do it. However with promise pipelining, having separate calls like we currently do to pass each named thing is at least plausible.

• I'm not sure why we're rejecting dynamic naming. That's been the majority of petname system examples so far. Is there a reason to do so?

Mostly because you want inertia in names. If I was willing to go along with "Faucet.Token", and I come back tomorrow and see "Faucet.Eth", I'm not just confused, I'm unhappy that it's trying to spoof me. If it shows me "Faucet.Token (renamed 'Eth')" (where maybe that's a hover), then I don't feel like someone was trying to pull a fast one.

I note that most previous apps that have petnames revolved around those connections, rather than the connections being merely one architecture element. For example, chat is all about who you are talking to. The first petname system that I recall was Tyler and/or Ping who did petnames for URLs the browser. We have a lot more things to name in an ocap ui, even in just the wallet. That makes names changing for those expensive. As with any system, good support for change is important, but I think, as usual, we prefer mostly static connections, with good but explicit support for the connections that change.

Also, about the types: We should retain the types, as otherwise the user must input the type as part of their petname. This is silly, because this is information that should be managed for the user, and the UI should be able to organize and display them based on the type of object. If we find ourselves creating suggested petnames that are like "Instance" and "Installation" we are doing something wrong, either in the display or in the suggestion itself.

I made the same argument. Then I went looking into our usage. We use "Instance" and "Installation" as edgenames in all out dapps, partly because of they are displayed as a path. so "CardStore.CardStore" is a worse name than "CardStore.Installation". Neither is inspired, but in practice, this was simple and clear.

Mark argued that for currencies, we really want only one petname for the whole shebang. We currently do that with suggestIssuer. He proposed naming the Brand, and then always having the Issuer have an edgename from there: "SomeBrand.Issuer". We start from the issuer currently. However, having the Brand be always referenced via an edge name would result in amounts of the display form "20 Faucet.Token.Brand", which is clearly silly.

[dckc]

@michaelfig when was that petname demo you did? I'd like to leave a cookie crumb here.

[michaelfig]

@michaelfig when was that petname demo you did? I'd like to leave a cookie crumb here.

2021-12-17 https://drive.google.com/drive/folders/1NxwNQAwzxJTkVWObYSNrr-ZbjccS62mv is the URL for the recording, which @cwebber may be interested in. Request access if you like.

[erights]

What's the advantage of discussion threads vs issue threads?

The disadvantage is huge: lack of backlinks.