<stellar-slack1>
<sacarlson> does this appear to look correct for the new federation support with proper Access-Control-Allow-Origin settings? https://equid.co/.well-known/stellar.toml
sacarlson has left #stellar-dev [#stellar-dev]
<stellar-slack1>
<jed> Yeah. You don't have an https cert though
<stellar-slack1>
<sacarlson> I should have an https cert
<stellar-slack1>
<sacarlson> it's working https from firefox ok
<stellar-slack1>
<sacarlson> or maybe you mean I don't have cert for the http://equid.co:8000 were the server resides? I'm not sure how to setup a cert on that yet
<stellar-slack1>
<dzham> looking good from here
<stellar-slack1>
<dzham> firefox didn’t show the connection as secure at first, but when I reloaded it was ok
<stellar-slack1>
<sacarlson> it will temp hook the federation to members of the https://equidmarket.com until these guys finish playing with http://equid.co|equid.co site
<stellar-slack1>
<sacarlson> yes I wasn't sure where to put access-control so I put it everywhere ha ha
<stellar-slack1>
<dzham> I’d do Access-Control-Allow-Origin; *
<stellar-slack1>
<dzham> so other clients can do a federation lookup also
<stellar-slack1>
<sacarlson> I tried that but it didn't hook to https unless I add this
<stellar-slack1>
<sacarlson> other clients?
<stellar-slack1>
<dzham> Yeah, right now only http://equid.co|equid.co can load the stellar.toml file
<stellar-slack1>
<dzham> So, using the http://lobstr.co|lobstr.co website, it won’t work.
<stellar-slack1>
<dzham> (Not sure if they support federation though)
<stellar-slack1>
<sacarlson> it only points at http://equid.co|equid.co if the domain is set in your stellar account
<stellar-slack1>
<dzham> yeah… but a wallet hosted at some other website wont be able to load the stellar.toml file from http://equid.co|equid.co
<stellar-slack1>
<sacarlson> as far as I know it only has to be allowed from the clients browser that gets the address
<stellar-slack1>
<sacarlson> the server at :8000 is set for Access-Control-Allow-Origin; *
<stellar-slack1>
<dzham> I think both have to be: *, how is the browser going to be able to find out about :8000 ?
<stellar-slack1>
<sacarlson> https://equid.co:8000 you should note the header is set to Access-Control-Allow-Origin; *
<stellar-slack1>
<sacarlson> yes that's the server that other link is just a pointer to the server
<stellar-slack1>
<dzham> :8000 just closes the connection for me
<stellar-slack1>
<dzham> OK...
<stellar-slack1>
<dzham> I have a web wallet at http://example.com|example.com
<stellar-slack1>
<dzham> I want to find out the accountId of mailto:sacarlson@equid.co|sacarlson@equid.co
<stellar-slack1>
<dzham> but fails, because you only allow https?://equid.co/
<stellar-slack1>
<sacarlson> no http://example.com|example.com doesn't but the client on his browser does
<stellar-slack1>
<dzham> Only clients running your own wallet at http://equid.co|equid.co will be able to use your read the stellar.toml-file
<stellar-slack1>
<dzham> @sacarlson: yeah, but the origin of the webpage in the browser is http://example.com|example.com, and not http://equid.co|equid.co
<stellar-slack1>
<dzham> I’m just getting the origins I posted previously
<stellar-slack1>
<sacarlson> I have yet to test it so you may be correct. as with my method I don't even check the stellar.toml file I just go direct to the server
<stellar-slack1>
<sacarlson> that is pointed to from homedomain
<stellar-slack1>
<dzham> homedomain is where you go to look for /.wellknown/stellar.toml
<stellar-slack1>
<sacarlson> yes but I didn't know that when I wrote my federation
<stellar-slack1>
<sacarlson> but I plan to move to the standard
<stellar-slack1>
<dzham> Anyways...
<stellar-slack1>
<dzham> > For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest follows the same-origin policy. So, a web application using XMLHttpRequest could only make HTTP requests to its own domain. To improve web applications, developers asked browser vendors to allow XMLHttpRequest to make cross-domain requests.
<stellar-slack1>
<sacarlson> other than one change that we won't need to add the sacarlson*http://equid.co|equid.co just sacarlson will work in my wallet
<stellar-slack1>
<sacarlson> that will default direct to the server
<stellar-slack1>
<sacarlson> yes that gave me alot of problems when I first made a working federation server
<stellar-slack1>
<sacarlson> this Access-Control-Allow-Origin was new to me then
<stellar-slack1>
<dzham> Either way, it should work with `*`, I had it working in the MVP
<stellar-slack1>
<sacarlson> cool I'm looking for examples of the new function that added to stellar sdk. mine at present is outside sdk within my own js code
<stellar-slack1>
<sacarlson> do you use https on that server with the Access-Control-Allow-Origin: * added?
<stellar-slack1>
<dzham> yes
<stellar-slack1>
<sacarlson> I tried adding it in .htaccess and also in apache2 configs but failed to get it on both
<stellar-slack1>
<sacarlson> without what I have setup now that I'm not totally sure will work or not
<stellar-slack1>
<sacarlson> what is your site address of your stellar.toml file?
<stellar-slack1>
<dzham> I was talking about http://equid.co|equid.co v1
<stellar-slack1>
<sacarlson> I don't think we had federation in v1 or maybe they did in the old system
<stellar-slack1>
<dzham> I certainly had a federation server there
<stellar-slack1>
<sacarlson> ic but that's broken forever now
<stellar-slack1>
<sacarlson> we need something today
<stellar-slack1>
<dzham> Yeah, but the Access-Control-Allow-Origin principles are exactly the same
<stellar-slack1>
<sacarlson> yes your right I'll have to fix this
nivah has joined #stellar-dev
<stellar-slack1>
<sacarlson> but didn't have any luck yet but I'll try a few more things to get "*" in there
<stellar-slack1>
<dzham> It’s dead simple in nginx, but that doesn’t help you
<stellar-slack1>
<sacarlson> I might already have it
bit2017 has quit [Ping timeout: 240 seconds]
<stellar-slack1>
<sacarlson> nope don't got it. not even any header added now
<stellar-slack1>
<sacarlson> I'll take a look at your link
<stellar-slack1>
<sacarlson> this guy has tried all the things I've already tried with the same failures I get. I'll try his last solution to see if i works for me thanks dzham
nivah has quit [Ping timeout: 260 seconds]
<stellar-slack1>
<sacarlson> I assume he puts this in .htaccess?
<stellar-slack1>
<dzham> yup
<stellar-slack1>
<sacarlson> ok
bit2017 has joined #stellar-dev
<stellar-slack1>
<sacarlson> nope didn't work even his last entry
<stellar-slack1>
<sacarlson> at least not when I put it in .htaccess of the dir /var/www/html/equid.co/.well-known/stellar.toml
<stellar-slack1>
<sacarlson> any other ideas dzham?
<stellar-slack1>
<sacarlson> oh wait I think I forgot to reset the server
<stellar-slack1>
<sacarlson> I'm thinking maybe try php code as apache configs seem to fail
<stellar-slack1>
<sacarlson> also failes when I add that .htaccess to the root of http://equid.co|equid.co
<stellar-slack1>
<raymens> Any core developers awake/online?
<stellar-slack1>
<sacarlson> I can get this to at least put out Access-Control-Allow-Origin: * header but can't get it to run when renamed to stellar.toml https://equid.co/.well-known/stellar.php
tectonic has quit [Ping timeout: 250 seconds]
tectonic has joined #stellar-dev
<stellar-slack1>
<sacarlson> ok I might have it now with changes to mime.type I now have toml running as php
<stellar-slack1>
<sacarlson> I hope someone finds a better way that I ended up doing it
<stellar-slack1>
<sacarlson> ok new problems now that I'm using https on the port :8000 federation server side I'm still getting blocked will allow origin problems
<stellar-slack1>
<sacarlson> worked fine before I had https setup
<stellar-slack1>
<sacarlson> I don't think this server https://github.com/stellar/federation is at all setup for https. maybe I can setup proxy from apache to feed it in http?
<stellar-slack1>
<dzham> @raymens: Did you do anything with regards to assets, and number of decimals?
<stellar-slack1>
<dzham> I issued some counterparty assets yesterday, but wasn’t sure what to do with the ones that were indivisible
<stellar-slack1>
<dzham> Half a token isn’t going to do much good :S
<stellar-slack1>
<raymens> Not for Stellar no. I haven't touched counterparty yet. I just had some sort of proposal for Stellar wallets some time ago
<stellar-slack1>
<raymens> It seems that the history test of the core is failing on Windows, if this is related to my question if there's a core developer online :)
<stellar-slack1>
<dzham> Oh, I issued them on Stellar..
<stellar-slack1>
<raymens> Oh ok. Well you could use one 'satoshi' (forgot the Stellar name for it). In that case it isn't divideable
<stellar-slack1>
<bartek> stroop
<stellar-slack1>
<dzham> But we need to inform the various wallets what the units for a specific asset is
<stellar-slack1>
<raymens> I agree, that's why I think that information should be put in the stellar.toml file or somewhere similar of the issuer
<stellar-slack1>
<raymens> (brb)
<stellar-slack1>
<dzham> That’s probably the place for it. There’s a counterparty wallet that uses webtorrent to store that in a DHT
<stellar-slack1>
<dzham> It kind of forces you into having a stellar.toml file as an issuer though :S
bit2017 has quit [Ping timeout: 240 seconds]
<stellar-slack1>
<raymens> yeah it does, another way would be using URLs like stellar://asset?code=BEER&issuer={...}&decimals=0
<stellar-slack1>
<raymens> or a custom Horizon
<stellar-slack1>
<ant> when you do path finding and get back a bunch of results - is the top one the best? - in my case sometimes the first result gives back an empty path [].
<stellar-slack1>
<jed> Ant: the results should each be sending different currency. For example if you are trying to get the receiver NGN it will give you the option to send X USD or Y EUR
<stellar-slack1>
<jed> Raymens: I was thinking of adding a new asset type that is indivisible so clients know.
<stellar-slack1>
<raymens> indivsibleAlpha4 and indivisibleAlpha12? :)
<stellar-slack1>
<jed> ok thanks can you make an issue
<stellar-slack1>
<raymens> sure
<stellar-slack1>
<raymens> done
<stellar-slack1>
<ant> Yes they are different - but which one is least expensive/ best route? Is there something in the results that tells me that? e.g EUR - XLM XLM-NGN or EUR NGN - Or does the client calculate that...
<stellar-slack1>
<dzham> there’s no objective best route, that all depends on how the sender values their assets
<stellar-slack1>
<jed> ant: it should give you the best route for each sending currency. So the least amount of USD you can send or the least amount of EUR you can send
<stellar-slack1>
<jed> whether it is better to send USD or EUR is a choice the client has to make
<stellar-slack1>
<jed> it shouldn't give you two paths with the same starting currency. If it is that is a bug
<stellar-slack1>
<ant> so if the client has both XLM and EUR -> NGN they decide... ok just to confirm that makes sense
<stellar-slack1>
<jed> yeah
<stellar-slack1>
<dzham> what you could do, and the old http://stellar.org|stellar.org wallet did that IIRC, is show the slippage for each path… I.e., if it’s a thin market and you exchange a big amount, you’re going to move the market a fair amount
koolhead17 has joined #stellar-dev
koolhead17 has quit [Changing host]
koolhead17 has joined #stellar-dev
<stellar-slack1>
<dzham> @jed: of course, the negative aspect of indivisibleAlpha4/12 is that it’s a bit of a leaky abstraction.. every time you create a StellarSdk.Asset()-object you need to remember if it’s indivisible or not
<stellar-slack1>
<jed> why do you have to remember? The asset object should handle it
<stellar-slack1>
<dzham> so the asset object checks the ledger to find out what kind of asset it is?
<stellar-slack1>
<dzham> I’m thinking client side here.. creating a tx, add some operations.. send a payment, and you need to know what asset you’re sending.
<stellar-slack1>
<jed> you always need to know that though right? you normally tell because you trust a particular asset or the receiver does
<stellar-slack1>
<dzham> I don’t have to know if it’s a assetTypeCreditAlphanum4 or assetTypeCreditAlphanum12.. I just need the name and the issuer
<stellar-slack1>
<jed> well you do need to know. you can just derive the type from the name. But yes now the names would be ambigous
<stellar-slack1>
<jed> I'd have to think about the best way to handle it
koolhead17 has quit [Remote host closed the connection]
koolhead17 has joined #stellar-dev
DomKM has joined #stellar-dev
bit2017 has joined #stellar-dev
<stellar-slack1>
<brian.ebert> At the risk of playing to, hippie era type, I notice js-stellar-base has moved on to v0.4.20.
<stellar-slack1>
<garth> Totally Awesome dude.
koolhead17 has quit [Read error: Connection reset by peer]
koolhead17 has joined #stellar-dev
koshii has quit [Remote host closed the connection]
Strmnrm has joined #stellar-dev
Strmnrm has quit [Client Quit]
koshii has joined #stellar-dev
koolhead17 has quit [Remote host closed the connection]
<stellar-slack1>
<sacarlson> so before I research on how to do https proxy to http might it be possible for this https://github.com/stellar/federation federation server to handle https certs?
<stellar-slack1>
<bartek> @sacarlson: I was thinking about this today. it shouldn't be so hard to implement in this server but it's also super easy to do it in nginx (and in most cases devops will have to use nginx to attach `/federation` path to their main domain).
<stellar-slack1>
<bartek> we need to think it over
<stellar-slack1>
<sacarlson> yes more I think about it the more proxy sounds to be the answer as apache is already listening on port 443 so woudn't have much of an option any way
<stellar-slack1>
<sacarlson> so proxy it is then. I've used apache proxy before just not with https