Configuration appName - string or Name?

[aaroncox]

Should this appName value be a string or should it be a Name type variable?

This topic came up today during the weekly call (Meeting #19 - timestamp link) regarding the appName field on the SessionKit.

The current purpose of this field is for an app to communicate to Wharf, and subsequently the user, the name of the app they are logging into. In the future, the planned usage of this field was to use it to associate the app with on-chain metadata and some protocols to verify incoming requests. To prepare for this future, the appName was declared as a Name type object which eventually would match up with an on-chain account.

After the call today, I wanted to raise the discussion about a few potential changes, and collect feedback before changing anything.

The main change we could make here is converting appName into a plain string value. This would remove the current limitations of the Name type value, since currently the appName is limited to the same restrictions as an account name (1-12 chars, a-z1-5). This change would also mean we could potentially drop this as a required field for the developer, since without length requirements, it could just default the value to match that of the page title. Developers could specify and override this behavior if they wanted.

This would mean in the future, we would need to add an additional optional field to use for associating apps to on-chain accounts, which doesn't seem like too big of an ask to opt-in for that new functionality.

[openventures]

If appName will be passed to the anchor link transport, it will be converted to a Name anyway right? So with UAL currently I frequently observe "weird" looking names in Anchor iOS, due to dApps not using a Name as appName.
So for my wrappers around anchor-link I am currently forcing a Name type to ensure that it will display a "nice" string in Anchor iOS.

[aaroncox]

The anchor-link library is being replaced essentially with this new library. The Name requirement can be dropped because of that.

[nsjames]

An app name is one of the first things the user should see in a wallet UI when they are interacting with an application. It should be exactly what they expect it to be, not a version that fits within restrictions that don't apply to it.

It's also a branded value. "Nike" is not the same as "nike". Both the users and the companies expect things to look cohesive across an experience, and this is especially important for things like web3 where there is a large component of trust that needs to be cultivated.