01:58 <stellar-slack> <nelisky> with path payments and things alike, is the source_account guaranteed to be the initial sender of the funds? The origin account, if you will? I know with ripple and old stellar that was a hard one, and destination tags were pretty much mandatory for a gateway but while I'll keep support for them as memos (required for cross-ledger native currencies in DR) I'd like to also allow people to simply transfer ass

01:58 <stellar-slack> source_account

02:02 <stellar-slack> <jed> which endpoint are you looking at?

02:04 <stellar-slack> <jed> source_account is the source account of the tx. you need to look at the "from" in the actual payment operation

02:10 <stellar-slack> <nelisky> ok, maybe I'm off here, I'm debugging the upgrade process and just realised I need to reword / rethink the destination tag thing

02:10 <stellar-slack> <nelisky> on both ripple and stellard I forced the dt, and that was that, there was always one

02:11 <stellar-slack> <nelisky> now I will ask politely for user to add the tag as a memo on payments, but my question is if I need to force it. If I look at the from field on the payment operation, even if that's a path payment, will it always be the initiating account

02:11 <stellar-slack> <nelisky> ?

02:11 <stellar-slack> <jed> well it isn't enforced on a protocol level on ripple

02:12 <stellar-slack> <jed> it is just a hint to clients

02:12 <stellar-slack> <nelisky> not if I set the flag to require it, right?

02:12 <stellar-slack> <jed> the flag is just a hint

02:12 <stellar-slack> <nelisky> regardless, that much is working, now I need to decide on stellar-core

02:13 <stellar-slack> <jed> you can certainly know for sure what account sent you the payment

02:13 <stellar-slack> <nelisky> there's no simple format for me to force a memo to be a destination tag, no hint mechanism for client software if you will, and honestly I'd do better without enforcing it

02:15 <stellar-slack> <nelisky> Of course it is nice to send funds from one account and have them be processed as if they came from another, so you don't have to register all your accounts on DR, but enforcing as it is now (no dt means refund currently) should be unnecessary, if "from" is always the topmost account in the payment chain

02:17 <stellar-slack> <jed> you could make the memo optional and if they include it use that as the dest ID

02:18 <stellar-slack> <nelisky> that's the plan, I just need to make sure the lack on memo on a complicated transaction won't mean I end up crediting the wrong person

02:18 <stellar-slack> <jed> no the "from" is always the account the balance was moved from

02:20 <stellar-slack> <nelisky> cool, thanks

02:42 <stellar-slack> <nelisky> also, and I'm pretty sure this is correct, but just making triple sure; without protocol enforced transfer fees there's no sendmaxmulti weirdness, i.e. what I send is what I send, and that also goes for partial payments, i.e. there aren't any, right?

02:45 <stellar-slack> <jed> there are no partial payments but there is still sendMax for path payments

02:45 <stellar-slack> <jed> since you aren't sure what orders will be taken in the path

02:46 <stellar-slack> <nelisky> ok, but if I'm not knowingly sending a path payment (I'm using a payment operation) then that's not part of the equation?

02:47 <stellar-slack> <jed> right, then it will send what you tell it to send

03:09 <stellar-slack> <xekoukou> Hello, how can we write a web app? Is horizon ready?

03:14 <stellar-slack> <jed> Yeah horizon is ready

03:14 <stellar-slack> <jed> What do you want to make?

03:17 <stellar-slack> <xekoukou> Do you know about the loyalty cards that supermarkets use? I was thinking of using stellar as a replacement with the potential of creating a trust network in the future.

03:31 <stellar-slack> <jed> OK cool. Yeah stellar should be good for that

03:31 <stellar-slack> <jed> http://Stellar.com/developers/learn|Stellar.com/developers/learn to get started

03:50 <stellar-slack> <nelisky> is there anything similar to account_lines in stellar_core? Specifically, I need to know the total sum of issued IOUs per asset, so when account GBDOCABSLKZIVYCW643B2HNYLW3VFYBI3RNXDDT3B2FPWNQ2VAMU5ECZ received TRC from GBFYAHT66I454GP3T2JJTZASWBPT4OCDE2MLTDKKNTFEVZW2RIOXK4X3 (which happens to be the issuer too) I correctly see the positive balance on the former

03:51 <stellar-slack> <nelisky> but not the negative on the latter

03:52 <stellar-slack> <nelisky> needless to say going through all operations to calculate this does not scale, and keeping a cached total is hard and prone to errors

03:59 <stellar-slack> <sacarlson> I think I could write a program the just does a total on an issuer of an asset that could have added input of a destination ID. but like you said I'm not sure how scaleable it would be

04:02 <stellar-slack> <nelisky> sacarlson: that would be fine and performance would be great, but then I'd be coding against the stellar-core db and not horizon, which I'm hoping will allow me to use it as a single point to communication

04:02 <stellar-slack> <nelisky> unless you are offering to add that to the horizon api, of course :)

04:02 <stellar-slack> <sacarlson> yes I think they could add that to horizon also

04:03 <stellar-slack> <sacarlson> I would add it to my mss- server

04:03 <stellar-slack> <nelisky> I guess I'll need to learn go if I'm to keep making requests all the time

04:03 <stellar-slack> <sacarlson> ruby works fine

04:03 <stellar-slack> <sacarlson> at this scale

04:06 <stellar-slack> <sacarlson> and I think the total part of the software would be running in c++ like in postgress so might be fast up to medium scale

04:09 <stellar-slack> <nelisky> I'm sure of that, my problem is not performance, it's separation. If I'm going to code against the stellar-core db then I'm effectively replacing horizon on some tasks, so I might as well do that for everything. Otherwise it gets really messy as both pieces of the framework progress

04:11 <stellar-slack> <sacarlson> well I started before we had a working and documented horizon so I started from the stellar-core db. but for clients I don't want them to deal with waiting for a stellar-core to spin up at each start

04:13 <stellar-slack> <nelisky> I'm not saying it's not worth it, mind you, but at this early stage, and unless the developers are unresponsive and the code is hard to tweak by myself, I think focusing efforts on the single client facing interface is the best approach. And honestly it does 99.5% of what I need it to do, so going through the effort of coding a separate helper facility seems silly.

04:14 <stellar-slack> <nelisky> for my case, that is.

04:15 <stellar-slack> <sacarlson> yes and I think as stellar sees your ideas that to me sound good they will implement them

04:15 <stellar-slack> <sacarlson> or others will PR request to add those features

04:29 <stellar-slack> <jed> Nelisky: https://github.com/stellar/horizon/issues/178

12:23 <stellar-slack> <nelisky> jed: nice to know I'm not the only one. Is there a "peer pressure" button I can push to up the priority? It's kind of important for DR to assert everything adds up correctly before sending out payments

13:03 <stellar-slack> <nelisky> one successful payment result from horizon:

13:05 <stellar-slack> <nelisky> I assume the lack of "status" can be inferred as status: done (that and the hash for the tx + ledger number, of course) but do I still need to parse the result and result_meta from the xdr encoded values? Or is it completely moot?

14:15 <stellar-slack> <jed> No you don't need to if it succeeds like this

15:08 <lupusinfabula> Hi everyone, we are at a huge hackathon event in Helsinki (http://hackjunction.com/). Stellar came up in a discussion, but I don't know much about how it works (followed Ripple a few years ago but didn't follow since then).

15:08 <lupusinfabula> I would be interested if lightweight / SPV clients makes sense on this network?

15:09 <lupusinfabula> If someone integrates Stellar, do they have to use a SPOF API point, or can they directly connect to nodes/validators, and download transaction lists, send transactions, etc.?

15:09 <lupusinfabula> Thank you for your help in clarifying.

15:25 <stellar-slack> <jed> hi lupusinfabula

15:25 <stellar-slack> <jed> check out http://stellar.org/developers/learn|stellar.org/developers/learn to get started

15:26 <stellar-slack> <jed> SPOF is "single point of failure"?

15:26 <stellar-slack> <jed> yeah people can run their own node and connect to it

15:30 <stellar-slack> <jed> most stellar clients act as SPV clients. They talk to one or more horizon servers which are connected to one or more stellar-cores

15:30 <stellar-slack> <jed> but it is flexible

17:00 <lupusinfabula> @jed so by conecting to more horizon servers it can be made more resilient? The point is not to rely on one single horizon server run by us (yes, SPOF means single point of failure here).

17:00 <lupusinfabula> is there a list of "public" horizon servers, or would we have to run them ourselves?

17:52 <stellar-slack> <jed> We are running one: https://horizon.stellar.org but you could also run one yourself

20:44 <stellar-slack> <eva> @lupusinfabula hey, awesome to hear that you found out about Stellar in Helsinki :) Great to have you here, and hope the docs help clarify for you. We’re still in the process of refining the developer resources, so please let us know if you have questions or feedback :)