MultiAccount for same PayID

snub-fighter commented 4 years ago

Detailed Description

We could provide multiple accounts (XRPL-Mainnet) under one PayID using "sub-domains". If a sub is present it references a specific account if it is absent a default account is used.

Example prod.johndoe$xpring.money

Using the example below are two mainnet accounts applied to johndoe$xpring.money. A default key, value pair is applied and if Default = True sub must = null. If default False a sub value may be applied. the sub then allows for the client to query prod.johndoe$xpring.money to specify the main account and johndoe$xpring.money when using default account.

Context

It benefits everyone so that they can maintain one PayId instead of multiple.

Possible Implementation

{
  "payId": "johndoe$xpring.money",
  "addresses": [
    {
      "paymentNetwork": "XRPL",
      "environment": "MAINNET",
      "default":True,
      "sub":null
      "details": {
        "address": "TVQWr6BhgBLW2jbFyqqufgq8T9eN7KresB684ZSHKQ3oDth"
      }
    },
    {
      "paymentNetwork": "XRPL",
      "environment": "MAINNET",
      "default":False,
      "sub":prod
      "details": {
        "address": "X7zmKiqEhMznSXgj9cirEnD5sWo3iZSbeFRexSFN1xZ8Ktn"
      }
    }
  ]
}

Alternatives Considered

Alternatives are allowing for multiple accounts to be created and having a descriptor or title instead of sub. No default would exist. The client would query the payid as normal. A list would be provided showing the title and the user can select the appropriate one.

{
  "payId": "johndoe$xpring.money",
  "addresses": [
    {
      "paymentNetwork": "XRPL",
      "environment": "MAINNET",
      "details": {
      "title":Child_trust
        "address": "TVQWr6BhgBLW2jbFyqqufgq8T9eN7KresB684ZSHKQ3oDth"
      }
    },
    {
      "paymentNetwork": "XRPL",
      "environment": "MAINNET",
      "details": {
      "title":Savings
        "address": "X7zmKiqEhMznSXgj9cirEnD5sWo3iZSbeFRexSFN1xZ8Ktn"
      }
    }
  ]
}

Additional Context

None

Bonus

Not for the short term.

0xCLARITY commented 4 years ago

Some other alternatives:

Gmail emails ignore anything after the + sign, so we could make that the special character and have aliases like johndoe+prod.
If we did a name property for addresses, we could add another property that was default: boolean, to indicate which address was the default
Or, instead of a default key, we could add a preferenceRank: number, to be used as a sort order, so you could assign a preference for which address to get used.

snub-fighter commented 4 years ago

Some other alternatives:

* Gmail emails ignore anything after the `+` sign, so we could make that the special character and have aliases like `johndoe+prod`.

* If we did a `name` property for addresses, we could add another property that was `default: boolean`, to indicate which address was the default

* Or, instead of a `default` key, we could add a `preferenceRank: number`, to be used as a sort order, so you could assign a preference for which address to get used.

I can see the +prod suffix working as well, I like it. I dont think it would really matter which way it went as it would be simple enough to separate the two johndoe and prod. Probably the deciding factor is which one fits more to industry standard in this situation. That was a hidden feature with gmail for a long time, for me anyway.

Could you explain the difference of the name and default properties offered vs the sub and default in original thread. they sound very similar.

0xCLARITY commented 4 years ago

Regardless of whether the property is called name or sub, the key difference would be whether or not it is visible in the PayID.

So, one option is johndoe+prod, where the address has a sub/name of prod.

The other is that you always just ask for johndoe, and then select the address you want to send to. This is what you described in your "Alternatives Considered" as a descriptor or title.

PayString / paystring