00:17 <stellar-slack1> <nelisky> I was trying to add a trust line from a user account to the DR account (all bogus, but all funded) and I'm getting 'result_codes': {u'operations': [u'op_not_required']

00:17 <stellar-slack1> <nelisky> is adding trust lines optional?

00:19 <stellar-slack1> <sacarlson> I would think on the user side it would be required to hold any assets from the issuer

00:20 <stellar-slack1> <jed> can you paste the tx_blob?

00:20 <stellar-slack1> <scott> @nelisky: you’re probably using an “allow trust” operation, when you want a “change trust” operation: https://www.stellar.org/developers/learn/concepts/list-of-operations.html#change-trust

00:21 <stellar-slack1> <nelisky> I am using allow trust, thought that was eq to change trust, no limit

00:21 <stellar-slack1> <nelisky> jed: lemme try change trust and see if that works

00:21 <stellar-slack1> <scott> Allow trust is used by accounts that require authorization to form a trustline, i.e. KYC

00:21 <stellar-slack1> <nelisky> right, the flag thing

00:25 <stellar-slack1> <nelisky> scott, jed: changeTrust works as expected

00:29 <stellar-slack1> <nelisky> the limit, which was (in theory, need to debug the lib) set to max int, appears as 1 stroop

00:30 <stellar-slack1> <nelisky> since transaction fees always appear as 0 even though they are 100, it could be a visualization issue

00:30 <stellar-slack1> <nelisky> but otherwise, what's max(limit)? isn't it 64bit unsigned?

00:32 <stellar-slack1> <jed> 64bit signed

00:32 <stellar-slack1> <nelisky> roger that

00:34 <stellar-slack1> <nelisky> ok, that is what it was set to (again, in theory), specifically (2**63)-1, or 9223372036854775807

00:34 <stellar-slack1> <nelisky> assuming that is correct, I'll find where the problem is

00:39 <stellar-slack1> <nelisky> my bad...

00:55 <stellar-slack1> <nelisky> ahm, are we really forced to 7 digit precision on all asset types?

00:57 <stellar-slack1> <sacarlson> me and dzham spoke of this also but I guess the precision can be decided by the issuer and can be interger

00:57 <stellar-slack1> <sacarlson> I was going to add integer base to my wallet just to show it can be

00:58 <stellar-slack1> <sacarlson> as in the case of equity stocks I'm not sure we could move between networks with fractional parts of like IBM

00:59 <stellar-slack1> <nelisky> sacarlson: but looking at the xdr isn't amount an int64?

01:00 <stellar-slack1> <donovan> I think formatting of precision is the responsibility of the client?

01:00 <stellar-slack1> <sacarlson> yes but you can format 64 bit any way you want

01:01 <stellar-slack1> <nelisky> unless there's a way to annotate the format so client wallets show the balance correctly, it seems moot to me, but I may just be tired

01:01 <stellar-slack1> <donovan> Jed mentioned having mBTC vs BTC. There was some debate :)

01:01 <stellar-slack1> <sacarlson> I'm adding integer format to my wallet as we speak

01:02 <stellar-slack1> <nelisky> ah, annotating as part of the asset code

01:03 <stellar-slack1> <donovan> Effectively the integer is a fixed decimal with the precision determined by the characters for the currency. Obviously this means there is no central list of precisions per currency.

01:03 <stellar-slack1> <sacarlson> for fractional I guess it's default to 7 decimal places

01:04 <stellar-slack1> <nelisky> still, a standard would be good, and honestly I have no issue with sticking to some static limit and using multiple notations, but there are two problems to that; 1 that we would be better served with 8 decimal points to follow the cryptos (of course that's arbitrary and volatile, but still) and 2 moving between denominations would need to be easy

01:04 <stellar-slack1> <nelisky> so I issue BTC today, but tomorrow need to operate in mBTC... so what happens to all those holding BTC credit?

01:04 <stellar-slack1> <nelisky> oh well, that's going to bite us soon

01:05 <stellar-slack1> <donovan> I argued for embedding the precision in the currency definition, but here we are :)

01:06 <stellar-slack1> <nelisky> I guess it's fine, we'll make do... the truth is that all these simplification decisions, while reducing flexibility somewhat, make for a much simpler code base, and that is good too

01:07 <stellar-slack1> <donovan> True, until you submit an offer for a BTC against an mBTC without thinking, and oops :)

01:56 <stellar-slack1> <dzham> For things that aren’t currencies, non-fractional would be nice

01:56 <stellar-slack1> <dzham> Well, at least the got rid of the pile-o-crap that BOOST is

02:43 <stellar-slack1> <sacarlson> what you making dzham a windows client with BOOST?

02:44 <stellar-slack1> <sacarlson> I could make another super crapy one writen in ruby that should compile and run on windows

02:44 <stellar-slack1> <dzham> I wanted to upgrade my node to 5.0.0. Homebrew as a package manager

02:45 <stellar-slack1> <dzham> How do I unpin?

02:47 <stellar-slack1> <sacarlson> oh I interpreted homebrew as something you wrote yourself not a name of a package

16:06 <stellar-slack> <nelisky> jed: small nitpicking for horizon polling; using account_transactions only matches transactions with specific source account, but I need to get both ways, so using account_operations does this correctly, however to get the transaction memo I'll need to fetch the specific transaction, and the only link (other that bitmasking the operation id) to the transaction is the horizon url, which means parsing a text

16:06 <stellar-slack> future.

16:06 <stellar-slack> <nelisky> so one or all of the following would be great:

16:07 <stellar-slack> <nelisky> - operations have a transaction id field

16:07 <stellar-slack> <nelisky> - account_transactions find all transactions that touch the account, source or not

16:07 <stellar-slack> <nelisky> - operations carry the memo field from the enclosing transaction

16:17 <stellar-slack> <scott> @nelisky: Is there a reason you can’t just follow the `transaction` link from the operation’s `_link` attribute to get the transaction details for an operation.

16:17 <stellar-slack> <scott> At present it is only a path (so you would need to add the server’s base url onto it for a full url), but I’m planning on resolving that issue in the next couple of weeks

16:19 <stellar-slack> <nelisky> scott: yes, there is a good reason :) I'm using py-stellar-base, and I want to keep the api vs url separation. Basically having an operation object I want to be able to store the transaction id, which is a property thereof, not a link.

16:19 <stellar-slack> <nelisky> maybe it's not that good of a reason, it just makes much more sense to me

16:21 <stellar-slack> <scott> yeah, that’s really not inline with the design of the API. it borrows from hypermedia APIs, and building the URLs yourself is potentially dangerous (as in, future versions of the API may change the url structure and if you use links you’ll get free compatibility)

16:22 <stellar-slack> <nelisky> still, that's implementation vs object model

16:22 <stellar-slack> <nelisky> building the urls myself is not any more dangerous than building the urls for the initial query myself

16:23 <stellar-slack> <nelisky> hence the use of a helper object

16:23 <stellar-slack> <scott> Well, it’s also not recommended you build the initial query yourself, and instead use the url templates from the root resource: https://horizon-testnet.stellar.org/

16:24 <stellar-slack> <scott> (which needs to be updated with the latest endpoints)

16:24 <stellar-slack> <nelisky> ok, I can do that, but I still say the transaction should be in the object model of the operation, not as an external link

16:24 <stellar-slack> <nelisky> it is, already, in a proxied way using the operation id

16:25 <stellar-slack> <scott> that’s up to the client library… js-stellar-sdk exposes it as a simple function call

16:25 <stellar-slack> <scott> for example:

16:26 <stellar-slack> <scott> `server.operations().operation(someId).call().then(op => op.transaction())` would return a promise that resolves to the transaction object that the operation someId was validated in

16:27 <stellar-slack> <nelisky> right, but underneath that's doing one call to operation + 1 call to transaction just to get the id the call to operation already has since it has the link

16:27 <stellar-slack> <nelisky> and "that's up to the client library" is exactly where I am, building the client library

16:28 <stellar-slack> <scott> I’m sorry, I thought you were trying to get the memo for an operation

16:28 <stellar-slack> <nelisky> do I need to go one step up and build my own implementation of horizon? I was really hoping to not have to do that... hehe

16:28 <stellar-slack> <nelisky> yes

16:29 <stellar-slack> <nelisky> in a nutshell, I am doing DR implementation of stellar-core, but while I do that I'm also building the python client library support to help with that

16:29 <stellar-slack> <nelisky> I *can* do everything I need, it's just there are some extra steps and http calls that we could do without

16:30 <stellar-slack> <scott> yes, it’s more http calls that strictly necessary. Let me explain the design a bit and talk about how we’re going to resolve it going forward (remember, this horizon is still pre-v1)

16:31 <stellar-slack> <nelisky> hehe, I don't mean to be impatient, I'm just calling things as I see them.

16:32 <stellar-slack> <scott> totally, I’m not trying to say your wrong, just trying to fully understand your concern while talking about our recommended solutions

16:32 <stellar-slack> <scott> Coming down the line in, you’ll be able to add “expansions” to a request that will dereference links for you and bundle the responses together.

16:33 <stellar-slack> <scott> For example, the url `/accounts/1234/operations?expand=transaction` would get what you want in one go

16:34 <stellar-slack> <scott> Each operation record would have an `_embedded` entry (read up on HAL if interested in the json sub-format we use) named `transaction` that is the expanded link

16:36 <stellar-slack> <nelisky> that would be really cool, but it would add to the wire payload unnecessarily when a transaction holds multiple operations, as each would have an _embedded transaction

16:37 <stellar-slack> <nelisky> though that's me nitpicking

16:37 <stellar-slack> <scott> yep, there are tons of tradeoffs

16:37 <stellar-slack> <nelisky> it's all about specific use cases, I guess

16:38 <stellar-slack> <nelisky> I want to be able to poll transactions and operations that touch one or more addresses, with as little effort and traffic as possible

16:38 <stellar-slack> <scott> that repeated data should gzip really well

16:38 <stellar-slack> <nelisky> so the expand case would work great the other way around, transactions?expand=operation

16:39 <stellar-slack> <nelisky> but what would really rock would be to have the important transaction fields (memo, specifically) be added to the operation marshal

16:39 <stellar-slack> <scott> you would be able to expand a single page of operations for a transaction, but not necessarily retrieve all operations in one go

16:39 <stellar-slack> <nelisky> yeah, that's true

16:40 <stellar-slack> <nelisky> well, for now I'll just do the multiple calls required, and I'll change the client to use the links directly

16:41 <stellar-slack> <sacarlson> nelisky: DR implementation I assume that mean Dire

16:41 <stellar-slack> <sacarlson> rect

16:41 <stellar-slack> <nelisky> no, DividendRipple

16:41 <stellar-slack> <nelisky> argh, DividendRippler... the gateway

16:41 <stellar-slack> <sacarlson> ok sorry

16:42 <stellar-slack> <sacarlson> got it

16:47 <stellar-slack> <nelisky> so, regardless of the memo type it will always be presented as a (utf8) string in the 'memo' field?

16:49 <stellar-slack> <sacarlson> if I recall I think the memo field has like 3 formats not all string

16:49 <stellar-slack> <sacarlson> but definable

16:50 <stellar-slack> <sacarlson> I'm not sure nelisky but it sounds like your method of interface might be more like mine as I did in mss-server, instead of static address puts I define actions with gets. not sure I'm even close here.

16:52 <stellar-slack> <nelisky> I'm using eno's py-stellar-base, which effectively does build urls from actions

16:52 <stellar-slack> <sacarlson> opps maybe reversted

16:52 <stellar-slack> <nelisky> sacarlson: well 5 types actually, none, int, text, hash and refund hash

16:53 <stellar-slack> <nelisky> not int, id, but same difference

16:53 <stellar-slack> <nelisky> the thing is that grabbing a tx with an id field yields:

16:53 <stellar-slack> <nelisky> u'memo': u'100061109', u'memo_type': u'id',

16:54 <stellar-slack> <nelisky> as you see, the memo field is of type id but gets delivered as a string. Which is fine and all, I just need to be sure that is expected for this and all other formats, or if there's any encoding I need to take under consideration

16:54 <stellar-slack> <sacarlson> I'm sorry my method uses post as in {"action"=>"get_seq_num", "account"=>"GDM6RBPBTDY3YE35I7LLU53LP4IZH26PIFE5IFPITGCEOZBX66IFZIDH"}

16:56 <stellar-slack> <nelisky> good to know horizon accepts both methods, gets are just easier to debug.

16:56 <stellar-slack> <sacarlson> my other method uses the same format but with sockets

16:58 <stellar-slack> <nelisky> one day I'll make full use of streams, but since they're not supported on every endpoint I need to poll, it's just simpler to keep a single method. But for dedicated clients using streams is really better

16:59 <stellar-slack> <sacarlson> yes I agree you should have both methods as some have no real use for sockets like to send a transaction

16:59 <stellar-slack> <sacarlson> sockets are new to me

17:00 <stellar-slack> <sacarlson> I'm old this is all new ha ha

17:02 <stellar-slack> <nelisky> hehe, that's not an excuse! old should be == more knowledge :P

17:02 <stellar-slack> <sacarlson> these smart kids are miles ahead of me

17:06 <stellar-slack> <sacarlson> I also noted that there was memo in operations and at the higher level, would you be looking at both of them?

17:07 <stellar-slack> <nelisky> memo in operations? have a link?

17:07 <stellar-slack> <sacarlson> as it could be posible to send to multi destinations

17:08 <stellar-slack> <sacarlson> I only found it in js-stellar-sdk not int the docs I originaly looked at in ruby-stellar-base

17:08 <stellar-slack> <sacarlson> I'll see if I can find a link

17:12 <stellar-slack> <sacarlson> I think this like provides an example https://github.com/stellar/js-stellar-base/blob/master/examples/low-level-payment.js

17:13 <stellar-slack> <sacarlson> I've only seen this in js-stellar-base not in ruby-stellar-base

17:13 <stellar-slack> <sacarlson> never looked in the stellar-core source

17:14 <stellar-slack> <sacarlson> this seems to allow adding memos within each operation

17:14 <stellar-slack> <nelisky> that's likely used to fill the transaction fields, would have to look deeper, but https://github.com/stellar/js-stellar-base/blob/master/xdr/Stellar-transaction.x#L53

17:14 <stellar-slack> <nelisky> the xdr object for the paymentop doesn't look like it takes a memo

17:15 <stellar-slack> <sacarlson> that's what I thought looking at what I thought was xdr so you may be correct

17:16 <stellar-slack> <jed> you can only add a memo to the transaction not to operations below it

17:20 <stellar-slack> <sacarlson> so were those documents in the code meant to be futuristic @jed?

17:20 <stellar-slack> <sacarlson> or plans that never became a reality?

17:21 <stellar-slack> <sacarlson> it seems it's only seen in js-stellar-base so not sure how much to draw from that

18:34 <stellar-slack> <powderfan> this used to work already and I don't think I changed anything

18:35 <stellar-slack> <powderfan> Any known issue in horizon or stellar-sdk?

18:35 <stellar-slack> <sacarlson> bummer I was planing to play with that tomaro

18:36 <stellar-slack> <eva> cc @scott

18:36 <stellar-slack> <scott> let me check it out.. one sec

18:38 <stellar-slack> <scott> it’s working just fine for me @powderfan. Can you give me an example url that is triggering the error?

18:39 <stellar-slack> <powderfan> difficult, cause it's no error I'm just not receiving anything on the stream

18:39 <stellar-slack> <scott> an example url could help me understand the situation better

18:40 <stellar-slack> <sacarlson> maybe just Internet conectivity on the phone? maybe try a browser to see if it conects

18:40 <stellar-slack> <scott> thanks! give me one sec

18:41 <stellar-slack> <scott> And you’re saying that the stream on line 22 there never gets it’s message handler triggered?

18:42 <stellar-slack> <powderfan> yes, that's how it looks like at the moment

18:43 <stellar-slack> <powderfan> initial call seems to work

18:48 <stellar-slack> <scott> @powderfan: just confirmed that a bug is getting triggered on that endpoint. I’ll get it fixed momentarily and pushed out

18:48 <stellar-slack> <powderfan> ok, great! thx

19:07 <stellar-slack> <scott> @powderfan: I’m not going to be able to fix this problem right away… just got called in to jury duty. I’ll work on it some tonight when I get back.

19:07 <stellar-slack> <scott> sorry about the trouble

19:49 <stellar-slack> <powderfan> np

19:58 <stellar-slack> <powderfan> The same file works on newer android versions. Could be a file size issue but I didn't find anything alike on developer community platforms

20:34 <stellar-slack> <jed> I think you probably don't want to name the function you are setting `value` to

20:54 <stellar-slack> <powderfan> No, I suppose that older js engine considers `native` a keyword. I tried and renamed it to `native2` and the error disappeared. Maybe there is a more elegant solution.

21:03 <stellar-slack> <powderfan> But then the problem remains that `Float64Array` is not supported by older js engines.

21:05 <stellar-slack> <powderfan> Think I've read something that there are possibilites to use newer js engines even on older androids

21:12 <stellar-slack> <powderfan> Yes, https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview is, what I had in mind, but the drawbacks are too expensive at the moment (17MB apk size and possible loss of localStorageData, which happen to be the keys)

21:20 <stellar-slack> <raymens> What's the lowest api version you support now?

21:26 <stellar-slack> <powderfan> in beta it is API 19. It turned out that this is too restrictive. I'm going to push a version for API 17+ to beta now

21:27 <stellar-slack> <powderfan> chances are good I can support anything API 15+ which would mean Android 4.0 or higher

21:35 <stellar-slack> <raymens> 19 is already 2 years old, 17 is 3 years old. Oh oh.. Android.. :(

21:36 <stellar-slack> <raymens> those versions have so many security issues it wouldn't be great to store cryptocurrencies on them :)

21:39 <stellar-slack> <powderfan> good point! On the other hand, we want to provide access to financial services to everybody! Not all of them can afford a new smartphone every 2 years.

21:41 <stellar-slack> <raymens> Yeah I get that, they don't have to buy a new one every 2 years though. Just have one that's newer than October 2013. It'll be interesting to know what the Android version usage is in the African and Asian markets

22:06 <stellar-slack> <powderfan> indeed. From my current statistics 95% use 4.0 or higher