I wrote a blog the other day about how to statically host a PayID on your own site, if you maintain one:
A friend and colleague, Si, asked me if you could host one on a Github Pages site.
@HammerToe Seems like a fun thing to have on your personal github pages site...22:57 PM - 18 Jun 2020
My first thought was probably not due to not having control of the content-type header that is set...
...but turns out you can. So in this video I briefly explain what you need to do to serve up a PayID from Github Pages.
In short:
You need to create a Github Pages repository if you don't already have one. These are named after your username. So if your username is
hammertoe
then your github pages repository needs to behammertoe.github.io
and will then be served up onhttps://hammertoe.github.io
You need to create a file in the repository named after then local part of the PayID (before the
$
). So I want my PayID to bepay$hammertoe.github.io
and so I need to create a file calledpay
. And in that file I have put the PayID information. This is a JSON block that describes my payment destination. e.g.
{
"addresses": [
{
"paymentNetwork": "XRPL",
"environment": "MAINNET",
"addressDetailsType": "CryptoAddressDetails",
"addressDetails": {
"address": "X75nEw5QD8Ej8jWt7EkJXHoVAV9YCtjuUSJppADpNtPKdim"
}
}
],
"payId": "pay$hammertoe.github.io"
}
You can have multiple address blocks, so you can reference multiple payment systems, e.g. XRP, BTC, SWIFT, etc.
Commit. Push. And you are done!
Now anyone with a PayID compatible wallet (such as Xumm, below) or payment system can search for your PayID and it will resolve to the payment information contained in the PayID file you put on Github.
Top comments (4)
Hi Matt - is it necessary for the GitHub repo to be set to "public" as opposed to private in order for the PayID protocol to find your addresses? I am using repo that contains nothing other than this text file, and so I currently have it set to private.
Keep in mind that to use PayID properly, it's dependent on the application as well as a server properly adhering to the PayID specification. This example makes some assumptions that can be dangerous for regular use. It's very possible to lose funds if you try to mimic this kind of implementation.
Yes, it doesn't quite adhere to all parts of the spec strictly. So if a client were to be extra strict it could fail. To be clear, you wouldn't lose funds, just someone or something might not be able to resolve your payment addresses.
is pay id needs special content type for the response? or just simply application/json?