Refine Petname UX

[bfollington]

Fixes #649
Fixes #613
Fixes #610
Fixes #611

Potentially resolves #615

• If we are following a user, we need access to the name we follow them under
  • use a enum with payload for this
• if we follow a user, show our @petname on the first line and full path on the second
  • except in our address book where there's only one name
• Show "Maybe: " in profile header context
• Use leaf name on first line in .unknown case, italics, no @
• Own profile name should count as .known

Demo

Screen.Recording.2023-06-08.at.10.58.16.am.mov

[bfollington]

Redundant, we can just refresh the profile

[bfollington]

We need to be able to change this field to achieve #613

[gordonbrander]

I'm mildly wary of mixed mutation semantics (confusing), and try to go either all immutable or all mutable.

• Should we just var everything? (Are there interdependencies among fields?)
• Alternatively, could we make a "copy" method that changes this one field and constructs a new struct?

Non-blocking. Just a thought.

[gordonbrander]

A few small questions + comments

[gordonbrander]

Might consider type names that map directly to concepts from one of the petname papers? https://spritely.institute/static/papers/petnames.html

• petname (following directly)
• selfNickname or autonym or selfProposedName (the nickname a sphere proposes for itself in its header)
• nickname or proposedName (The nickname a 3p proposes for another sphere. This is the petname that sphere gives another sphere.)

[bfollington]

Yes, this is better. I dropped the unknown case & reworked the mapping API introducing UserProfile.toNameVariant() which can hold all the logic about this mapping.

[gordonbrander]

I think we can say this fixes #615. If we decide we need further refinement, we can always re-open.

[bfollington]

Couldn't find a specific recommendation in the google swift styleguide for formatting long switch tuples like this, so this is a best guess.

[gordonbrander]

Works for me

[bfollington]

#613

[gordonbrander]

LGTM!

[gordonbrander]

Works for me

[gordonbrander]

I'm mildly wary of mixed mutation semantics (confusing), and try to go either all immutable or all mutable.

• Should we just var everything? (Are there interdependencies among fields?)
• Alternatively, could we make a "copy" method that changes this one field and constructs a new struct?

Non-blocking. Just a thought.