PayID Aliases #26
PayID Aliases #26
Conversation
There was a problem hiding this comment.
The technical aspect of this proposal makes sense to me, but have we received this request from partners? Would just want to make sure we're solving problems people are experiencing before we add complexity to the protocol. It's pretty simple as it stands today and I think that is one of its main selling points
It doesn't come from a partner. Just trying to anticipate a feature that would be useful and provide a bit of flexibility to PayIDs. |
|
@elmurci First, let me say I really like this idea -- this type of functionality is highly used in gmail, and I suspect would improve the experience around PayID. That said, I don't think this should be an "RFC" per-se. What I mean by that is, I don't think every PayID operator should be forced to implement this behavior. Instead, as with email aliases, I think this capability should be something that operators can freely choose to do, or not do. As an example, if Gmail supports "plus-based aliases" and Yahoo doesn't, then the email protocol isn't fundamentally broken, nor affected. I think the same is true for PayID in this case. Thus, I propose that we do two things:
I think task-2 directly above also addresses the question from @austin-king. E.g., Xpring probably wouldn't build this into the RI until we have heard sufficient feedback from partners that it's a useful feature. However, anecdotally you and I can agree that this feels useful, so maybe as a hackathon or weekend effort, one of us might be able to get it added at some point (especially if it doesn't rise to the top of the Xpring priority list). Though if we hear from partners that this would be very useful, of course it would make sense for Xpring to build. Thoughts? |
|
Makes sense @sappenin. Agree with your points. |
| "memo" : "Additional optional Information" | ||
| } | ||
|
|
||
| A request to retreive addreses linked to an alias might look like this: |
| # Definition | ||
|
|
||
| Create the concept of PayID aliases that will allow the user to create PayID aliases linked to the primary one. | ||
| For example, by owning `alice$example.com` could allow the user to generate multiple aliases as needed: |
There was a problem hiding this comment.
For example, by owning alice$example.com, the user could be allowed to generate multiple aliases as needed:
|
|
||
| This approach implies that you will get back different payment details for alice+main than you would for alice+savings, for the same Network, Environment tuple. | ||
| There will be a "wall" between aliases, so the only way to retrieve an address within "alice+savings$example.com" will be to request the "savings" alias. | ||
| Requests made to the main group ("alice$example.com") will not return addresses linked to other aliases. |
There was a problem hiding this comment.
Is there any way to get back information for all associated aliases for alice$example.com?
|
|
||
| Registrations of PayID variations after the plus sign should be blocked and return an error. | ||
|
|
||
| The syntax convention could allow further features like the generation of single use / one time PayID's or assignment of different policies to different accounts under the same PayID. |
I was away, but I am back now. Should this suggestion to allow + aliases be put into place now at docs.payid.org? |
High Level Overview of Change
Proposal for introducing Aliases in the PayID protocol.
Context of Change
Create the concept of PayID aliases that will allow the user to create PayID aliases linked to the primary one.
For example, by owning
alice$example.comcould allow the user to generate multiple aliases as needed:So, in this example, "alice+main$example.com === alice+savings$example.com === alice+crypto$example.com".
This approach implies that you will get back different payment details for alice+main than you would for alice+savings, for the same Network, Environment tuple.
There will be a "wall" between aliases, so the only way to retrieve an address within "alice+savings$example.com" will be to request the "savings" alias.
Requests made to the main group ("alice$example.com") will not return addresses linked to other aliases.
Registrations of PayID variations after the plus sign should be blocked and return an error.
The syntax convention could allow further features like the generation of single use / one time PayID's or assignment of different policies to different accounts under the same PayID.
Type of Change