Contacts specification

[cygnet3]

All the things needed for a contact.

[Sosthene00]

Here's some suggestions to kickstart this big topic (that's basically my notes here):

• The basic block is a contact. A contact is defined by:
  • A nym
  • a picture
  • A sp address or a bip353 url (optional?)
  • other contacts? email, phone...
  • sp labels (so defined by them)
  • UI label (so defined by us, only for organizing contacts purpose)
  • a transaction history
  • a shared secret, if we already sent/received a transaction before

Questions:

• is the name chosen by us or by them? If defined by them how do we fetch it?

• same for picture?

• do we want to display the sp address to the user or is it supposed to be some technical knowledge only showed for debugging?

• sp labels are a bit hard: they are provided by them, for certain purpose. Should we expect that they give us only one labelled address (so basically the sp label is invisible to the user and we don't want him to be aware of it), or that we can have multiple labels for the same contact?

• the transaction history and shared secret(s) implies that as a sender we have some way to prove who we are to the recipient, but we can't be forced either. This could be solved with signed message

• this also implies that our interface need to make it clear when we know who we've been interacting with and when we don't (we may have incoming transactions and have no idea who sent us money, we can have weak identification with sp labels, or strong with signed messages and shared secrets). There's a certain dissimetry between sender and receiver, when I'm sender I'm very confident of the contact I'm sending to or at least its address, as a receiver most of the time I'll have 0 information to display.

• we use contact blocks as bricks to build the contacts wall:

  • sort contacts by labels
  • display nym + picture
  • main action should be send money to, show tx history sure enough, but what else could we do?

• export/import: We need to define the format to export all that information, import it (restoration), and decides if we want to be compatible with other formats to allow user to import them.

• donation feature: We should be able to define a short list or even one fren we want to give to. Maybe simply add a "dana" label on frens?