PayID Server-Side Forwarding

[GAFO]

Hi i want to suggest payID forwarding.

That means that I want to be able to store my payid of e.g. bitrue (username$bitrue.com) behind my
very own payID. So if some resolver (like XUMM) sets out a requests for gafo666_bitrue$pid.gafo666.me
it should return the address written in e.g. username$bitrue.com .

Greetings GAFO666

[0xCLARITY]

Hey @GAFO , that sounds like it would likely be an extension / update to the PayID Protocol. Would you want to draft a PR on our RFC repository outlining your proposal?

[0xCLARITY]

And thinking through this further, I'm not even sure it would require a change to the PayID Protocol.

Couldn't you set up your server at pid.gafo666.me to have a PayID of gafo666_bitrue, but just pass along the request to gafo666$bitrue.com?

Or are you asking for an easy way to set that up using this project?

[GAFO]

Hey @GAFO , that sounds like it would likely be an extension / update to the PayID Protocol. Would you want to draft a PR on our RFC repository outlining your proposal?

Im not sure if I understand what you mean by that - should i repost my suggestion there or ?

And thinking through this further, I'm not even sure it would require a change to the PayID Protocol.

Couldn't you set up your server at pid.gafo666.me to have a PayID of gafo666_bitrue, but just pass along the request to gafo666$bitrue.com?

Or are you asking for an easy way to set that up using this project?

My goal is that the payID server itself forwards (without additional code or reverse proxys) to another payID server if it finds a payID in its db record. The goal is that this becomes generic and standardized within payID servers and the entry could look like this:

{ "payId": "gafo666_bitrue$pid.gafo666.me", "addresses": [ { "paymentNetwork": "XRPL", "environment": "MAINNET", "details": { "address": "username$bitrue.com" "forrwardRequest":"true" } } ] }

(maybe it could be a bit more generic so the payment network and environment dont have to be set for an forwarding)

Greetings GAFO666

[0xCLARITY]

Yeah, I guess there are two ways you could implement this.

Server-Side Solution

The first is a "server-side" redirect. You set up your PayID server (Server A) such that, for some PayID requests, it fetches the associated address(es) not from its own database, but from another PayID server (Server B).

One way to implement that might be the schema you've described above, but from the view of the client, it doesn't actually matter if the address is stored in Server A or Server B, it just gets back an address.

A solution like this doesn't actually need to be standardized across PayID servers, because the client is completely unaware that this is happening behind the scenes.

Client-Side Solution

This type of solution would rely on the client making multiple requests. You get back something like {"address": "username$bitrue.com" "forrwardRequest":"true"} as your response from Server A, realize you had been given another PayID, and make a second request to username$bitrue.com.

This type of solution would require standardization across the PayID ecosystem, since all servers and clients would need to understand this.

This type of solution would require an RFC on the RFC repository.

Thoughts

What do you think about the pros and cons of the two types of solutions I lined up? I think a server-side only solution would probably be preferable.

[GAFO]

I would definetly go for the server side solution so the client would not notice it but the server handles all whats happening behind the scenes. This avoids - as you said - that the client would need to make multiple requests.

That said, when I refer to "payID server" I mean the nodejs server application of payID which runs on a physical/virtual server.
So the payID server provided on this git repo should be able to store the json pattern from above and recognize the forwardRequest flag. On a client request and based on that it should automatically forward the the request (if the flag is set to true) with header to the entry written in the address field (another payID) and after all that happened, return the result to the client.

(feature should be shipped by this repo, to avoid that everyone would have to implement it as described)

Greetings GAFO666

[0xCLARITY]

So the payID server provided on this git repo should be able to store the json pattern from above and recognize the forwardRequest flag. On a client request and based on that it should automatically forward the the request (if the flag is set to true) with header to the entry written in the address field (another payID) and after all that happened, return the result to the client.

Do you think the forwardRequest flag is necessary? What about just storing a PayID as the address:

{ "paymentNetwork": "XRPL", "environment": "MAINNET", "details": { "address": "username$bitrue.com" }}

Then we could introspect the address before sending it over to the client, and if the address was a valid PayID, just go ahead and forward the request?

(feature should be shipped by this repo, to avoid that everyone would have to implement it as described)

That makes sense, but there are other PayID server implementations out there. I think this is a reasonable feature though, and it's not necessary that every PayID server in the world supports server-side PayID forwarding, just the server that you use.

[GAFO]

Well I personally do think the flag is necessary, otherwise the payID server application would always forward if there is another payID stored within the address field. For our scenario that is ok, But let someone else appear who solely wants to read it out without forwarding. It should be flexible enough for different needs, not just ours. But if you would say that its too complex to add another flag because of reason x then its for me personally ok as well, just thinking in multiple directions.

Regarding other payID server implementations, well its theoretically fine to be added here - for the other implementations a howto add docu would be nice, imagine someone self-implemented a server and wants its, but doesnt know how to do it in a good way. Would be a possible scenario.

Yes I would need it, thatswhy Im suggesting it, next to the "fact" that it would be a helpful feature. On that way companies could act as a payID record holder for other payID issuers by simply using your implementation in a simple way. (like in domains, someone issues .de , someone issues .com .. but all are accessible due a DNS management above it)

Greetings GAFO666

[0xCLARITY]

Agreed that this would be a useful feature. And I think documenting how to set this up for roll-your-own servers would make sense.

Well I personally do think the flag is necessary, otherwise the payID server application would always forward if there is another payID stored within the address field. For our scenario that is ok, But let someone else appear who solely wants to read it out without forwarding. It should be flexible enough for different needs, not just ours.

I agree in principle, but what would the Content-Type header response for returning a literal PayID be?

The logical answer is application/payid+json... except that right now, that is reserved for "return all addresses associated with a PayID".

So, for a potential use case where we are responding with a literal PayID, we would probably want a different Content-Type.

I'm not entirely opposed to the flag, but I would want to have a concrete reason to build it that way up front. Especially since this is server-side only functionality that is opaque to the client, if we decided we needed a flag later to support returning a literal PayID, we could always refactor it, and nobody outside the server code should really be affected.

[0xCLARITY]

Also, to play devil's advocate, what is the problem this feature would solve? Why can't you just give out your username$bitrue.com PayID directly?

[GAFO]

Agreed that this would be a useful feature. And I think documenting how to set this up for roll-your-own servers would make sense.

Well I personally do think the flag is necessary, otherwise the payID server application would always forward if there is another payID stored within the address field. For our scenario that is ok, But let someone else appear who solely wants to read it out without forwarding. It should be flexible enough for different needs, not just ours.

I agree in principle, but what would the Content-Type header response for returning a literal PayID be?

The logical answer is application/payid+json... except that right now, that is reserved for "return all addresses associated with a PayID".

So, for a potential use case where we are responding with a literal PayID, we would probably want a different Content-Type.

I'm not entirely opposed to the flag, but I would want to have a concrete reason to build it that way up front. Especially since this is server-side only functionality that is opaque to the client, if we decided we needed a flag later to support returning a literal PayID, we could always refactor it, and nobody outside the server code should really be affected.

Hm well "application/external-payid+json" would sound good to me, it describes pretty good what it is - storing external payIDs - so its quite intuitive.

Regarding a concrete reason for the flag, well that's for if(x) scenarios, in my personal opinion its always good to be flexible enough to address different "needs" when the effort to make it possible is relatively low. (I do not know how complicated it is)

Also, to play devil's advocate, what is the problem this feature would solve? Why can't you just give out your username$bitrue.com PayID directly?

There will be many providers for payIDs, it is a way to bring them under one hood. Imagine an provider only hosts ACH payIDs and another only XRP and BTC payIDs and another whatever asset you want to name. Then you end up with the same problem payID is trying to solve. Concluding there should be payIDs for payIDs. At least in my personal logic it sounds well put.

You could take other examples like the domains and DNS as I did above - there is .de .at .com .whatever with a list of sites running on each of them. So you put them under one hood that they are all accessible & manage them. (and lets not forget that behind each domain ending and the domains on it are IPs, even each subdomain on a domain can have a IP) There are many examples in IT why it would make sense to implement forwarding and when it works in other standards, why wouldn't it be good in the new payID standard ?

Greetings GAFO666

[0xCLARITY]

If you have gafo666_bitrue$pid.gafo666.me that forwards to username$bitrue.com, what would you want the associated payId of the response to be? gafo666.me? or bitrue.com?

Why?

[GAFO]

If you have gafo666_bitrue$pid.gafo666.me that forwards to username$bitrue.com, what would you want the associated payId of the response to be? gafo666.me? or bitrue.com?

Good question, I think it would be more logical that the end-destination would be shown as payId entry in the response because the one forwarding acts as a address book to find the end-destination. That would also make sense since the actual addresses (+ eventual tags) are maintained by the end-destination. In this particular example an exchange.

And I thought about the paymentNetwork entry in the meantime regarding forwarding and came to the conclusion that it should stay for the forwarding. And that because of the following example:

my Address book payID : gafo666_exchanges$pid.gafo666.me

On XRPL Mainnet : username$bitrue.com
On BTC Mainnet: username$someotherexchange2
On ETH Mainnet: username$someotherexchange3

so depending on which header param is given (xrpl/btc/eth one) in the request towards 'gafo666_exchanges$pid.gafo666.me' it forwards to the right entry.

One question on my side:
Can you have more than 1 entry under the same paymentNetwork in a payID ? Didnt try that yet.
Because if thats the case you would need to choose which one is forwarded to by flag and which are not.

Greetings GAFO666

[0xCLARITY]

Can you have more than 1 entry under the same paymentNetwork in a payID ? Didnt try that yet.
Because if thats the case you would need to choose which one is forwarded to by flag and which are not.

Not currently. It's under discussion as something to consider, but right now PayID assumes a single address per paymentNetwork, environment tuple.

[GAFO]

Can you have more than 1 entry under the same paymentNetwork in a payID ? Didnt try that yet.
Because if thats the case you would need to choose which one is forwarded to by flag and which are not.

Not currently. It's under discussion as something to consider, but right now PayID assumes a single address per paymentNetwork, environment tuple.

Ah okey - well would be an interesting feature as well, but then it would require a selection on the user-side I would assume.
(lets save that for another thread tho ;) )

Greetings GAFO666