I'm now looking at the possibility of my next project. I'm looking at integration of federation to email and maybe later phone numbers as I see this might be popular and useful for new anchors as seen for example <email>coins.asia or <phonenumber>coins.asia. We (funtracker.site) presently use the released federation that stellar created that only looks up names in mysql db that already exist. This method will go and create new accounts and email the funds to the address given.
Before I start this I want to make sure that someone hasn't already created something like this or if someone might already be working on one that they plan to release to public.
it should be a very small project to start that can integrate into my_wallet that already provides a way to send funds with a URL link and/or Stargazer by sending a QR-code via email with links to install the app.
I might even have a first draft version done before the Apr 15 contest dead line if I'm lucky.
dzham
8:03 AM
I've got email working, would be simple enough to make that code available to the general public
sacarlson
8:04 AM
you have email on you wallet working you mean?
dzham
8:04 AM
yeah
sacarlson
8:04 AM
yes if so I would integrate your wallet
8:05
but the main thing is there federation side code already or in progress?
dzham
8:05 AM
IDK about phone numbers, would have to find an SMS service, and make sure the everything fits in a message or two
sacarlson
8:06 AM
yes sms services are no problem, I played with them long ago but they aren't free or they weren't back then
dzham
8:06 AM
it will cost a bit of money, a lot more so than emails
sacarlson
8:07 AM
oh but what good is sms that would still require a smartphone to get the money? so yes email integration first.
dzham
8:10 AM
the federation service is already running.
it needs documentation though, if anyone else would like to use it.
sacarlson
8:11 AM
released federation? sure I would like to look at that.
writen in nodejs I assume?
eno
8:12 AM
https://fed.network is almost done, but have no support of email-type username
dzham
8:13 AM
@Eno: looking good!
sacarlson
8:13 AM
ya looks good but we need integration that just takes <mail> part and adds it to memo with the anchor address, very small task on the federation side. The user can then send any asset types that this anchor supports to that federation address.
and then the post processor that receives the transaction events would resends the funds to a new random created accounts.
An email would then be created to send the URL linked funded wallet to the posted email address and the account added to the anchors database for future sends to that address. (edited)
anybody want to write it or are already writing it?
one more step should be added first I failed to add above, if the email address already has an account on this anchor that it should resolve to his public stellar address.
dzham
8:32 AM
that's what I'm doing, after you withdraw your funds, it registers you at the address you withdrew to
sacarlson
8:35 AM
so It's all been done then or is in progress? and will be public?
dzham
8:35 AM
it's done, just needs cleaning up.
sacarlson
8:36 AM
fantastic, then I will await your results
how does your wallet accept URL links for funding?
I guess it points them to install the app and provides them the qr-code to fund it?
dzham
8:38 AM
qr-core, or a link to the website where they can input their account id.
eno
8:39 AM
email or SMS support are anchor’s work IMO. Are you making a universal support for any asset with any anchor?
sacarlson
8:41 AM
well it would be the same format to any anchor that would want to support it but this method will only work with what the pointed federation anchor supports. How would you link all the anchors together in one federation pointing address?
but yes you could have multi asset support as long as the anchor provided them
dzham
8:42 AM
If the recipient has an existing account then any asset can be sent, if not, only XLM
sacarlson
8:43 AM
like funtracker.site now supports 4 or more assets.
dzham
8:43 AM
I couldn't figure out any other way to make it so I don't lose XLM on it (paying for accounts to be created).
sacarlson
8:45 AM
I guess I failed to consider it would require a 2 minimum opp transaction from the sender client to send an asset other than XLM to accounts that don't already exist and already have trust set.
dzham
8:47 AM
You could to do a createAccount, trustAsset, payment combo, but I'm not sure how to present that to the paying user in the wallet.
sacarlson
8:48 AM
well that can easily be done on the server side but also the client side needs to know if the added XLM funds will be needed that will also need to be sent.
dzham
8:48 AM
oh, right.. so.. payment in XLM, payment in <asset>
sacarlson
8:48 AM
yes
8:49
that's also not a problem but having the client know it needs to is another story
dzham
8:50 AM
as with a lot of things, it's more of a UX/UI issue than a technical one.
sacarlson
8:51 AM
maybe just force them all to send 31 XLM to do the transaction weather the account exist or not? I'm sure there is a better way that would require more thinking, something added in the memo by federation would be need to be added to trigger adding XLM funds maybe.
just comma delimiter after the email address with ,31 or whatever minimum value needed in XLM to also send in the transaction example: "scotty.surething@gmail.com,61" is what the federation would resolve for memo if the federation server detected that the account didn't exist yet. the trailing ,61 in this case triggers the wallet when sending to this address IF the sender is sending an asset other than XLM to also send 61XLM to provide all the funds needed to create the account and add trust lines for this anchor.
This also assumes that comma can't be a part of email address or domain?
also I'm not sure how happy the sender will be to have to send 10 XLM for every asset that an anchor supports as these numbers may grow much bigger. A more complex method of sending transactions from the server side to add needed trust with the asset when needed would be the way to go. But then the federation server also has to also track or lookup the trust lines that the destination point already has to determine what is needed in the memo to the sender and to trigger what is needed to send the destination as far as a transaction. Also at this time My_wallet is the only wallet that accepts base64 tx transactions as URL link input or QR-code or any method of input. Other wallets would also have to add this feature at some point to make this method possible with other wallets.
In this way all the added 2 operation asset sending when needed is invisible to the sender all done out of site by the wallet and anchor federation server. The client should just look at it as sending any funds they hold to an email*anchor address.
dzham 9:54 AM
you get into the territory of having to do two separate multi-sig transactions to make it work with non-native assets
with all the complications that brings
sacarlson
9:54 AM
ya no problem not as If I haven't done that before in the OpenCart escrow project
dzham
9:55 AM
again, it's more of a user interaction / interface problem
sacarlson
9:55 AM
well there is some techno stuff going on in the background but they the user of the wallet need not know.
dzham
9:56 AM
since the initiating tx has to be signed by the intermediate account too, in order to add a trust line for the incoming asset
sacarlson
9:57 AM
well that was all done in the escrow project so it's no different
remember the escrow project also sends any asset that adds trust lines to the escrow account if needed before it is sent.
dzham
9:59 AM
the trick is to make it seamless for the users
sacarlson
9:59 AM
as demonstrated in the OpenCart escrow transaction using my_wallet and the branched version of Stargazer, it all works the same as sending XLM with no escrow as far as user interface. It should be the same for sending funds to an <email>*anchor.site federation method.
As I also look closer at https://stellar-wilson.herokuapp.com/doc/ I feel in some way this auto created account via email federation should some how integrate with it. But it's a wide view at this point for me and I don't fully grasp how that would be done yet. with the username and password within the stellar data fields sounds very cool. But I guess at this point the wallet for this are not fully develped yet?
