Logged Conversation (all times UTC)
[10:19] <stellar-slack> graydon: _"matriarchal"_ is not a dysphemism.
[12:49] <stellar-slack> http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/
[12:49] <stellar-slack> 7.4 Cryptocurrency Payment (Bitcoin, Ripple)
[12:49] <stellar-slack> why not stellar ?
[12:52] <stellar-slack> tigre: http had proviso for money, so the real Q is "Why not?"
[12:55] <stellar-slack> neither stripe is contributing. so it's just draft.
[13:01] <stellar-slack> lab: stripe are having a good crack at online payments.
[13:02] <stellar-slack> they're not Robinson Crusoe, either.
[13:03] <stellar-slack> maybe we should move this conv to #general
[13:03] <stellar-slack> sure :simple_smile:
[15:48] <stellar-slack> matschaffer: #429 does require a history-reset, yes. sorry, I should mark the ones that do.
[16:33] <stellar-slack> https://twitter.com/jfuerth/status/587249053630648320
[18:18] <stellar-slack> @epsilon t isn't about 'matriarchal' being a bad word. It's about presenting a company where leadership is actually equally gender-split (Jed + Joyce) as such. It's also about saying that women are here to keep the men honest; it implies that our actual contributions to the organization aren't valuable. Not looking to debate this, especially in #dev, but please refer to the community guidelines if you'd like m
[18:18] <stellar-slack> here. https://www.stellar.org/community-guidelines/
[18:34] <stellar-slack> eva: yeah, right.
[18:37] <stellar-slack> so it's the second sentence?
[18:38] <stellar-slack> I split newbie's line in two to separate any disparity.
[18:43] <stellar-slack> @epsilon: like I said, not interested in debating this line-by-line, esp. in #dev. Feel free to DM me if you'd like more guidance. Please keep this channel relevant to developer/technical topics only.
[18:45] <stellar-slack> eva: there is a PM function.
[18:46] <stellar-slack> yup, that's what I'm saying :simple_smile:
[19:50] <stellar-slack> ^ and, for the record, nothing.
[19:50] <stellar-slack> No offense meant.
[21:30] <stellar-slack> So, after I ran into the jruby-rack issue yesterday, it seems like we’re going to take a different approach with horizon. Port it to go!
[21:31] <stellar-slack> We talked about it at the outset of the project actually, but chose ruby because my experience with it would let me concentrate on the design and get to our initial reveal with some hair left on my head
[21:32] <stellar-slack> Now that a bunch of the bigger design questions are all resolved with regards to the api, go seems like a good choice.
[21:32] <stellar-slack> :simple_smile:
[21:33] <stellar-slack> I’m going to be concentrating on the non-xdr stuff for a bit (mostly reading from the history tables populated from the ruby importer)
[21:34] <stellar-slack> I’ll post more notes here as I work up the plan… but my next step is going to be getting a working server that provides parity to ruby-horizon for our existing read endpoints
[21:35] <stellar-slack> @donovan: what have you used for managing the vendoring story in go? It seems like godep has the most traction.
[21:38] <stellar-slack> @scott: TBH, I don’t do vendoring, I just fix as I go along, report bugs to other packages, and build and test often with http://drone.io|drone.io to find the issues. Sounds lazy, but in reality, most other Go package authors get the fix done within a day of reporting :simple_smile:
[21:38] <stellar-slack> But godep does seem to be what others use :simple_smile:
[21:39] <stellar-slack> :simple_smile: ah, cool. so maybe I'll punt on that for now
[21:42] <stellar-slack> Worth knowing about the tag feature of http://gopkg.in|gopkg.in as well:
[21:42] <stellar-slack> http://labix.org/gopkg.in
[21:44] <stellar-slack> thanks!
[21:46] <stellar-slack> Out of interest,what’s the motivation behind using HAL? Is there some intent to build UI’s using the responses?
[21:49] <stellar-slack> so, the root motivation is that by leveraging some standard we could get easier client development to happen. For example, `ruby-stellar-lib` simply leverages the `hyperclient` gem to get very simple access to all of the resources defined by the api. For that reason, I did not want to simply use adhoc json for our responses.
[21:50] <stellar-slack> Then, the question becomes what standard
[21:50] <stellar-slack> (clearly you need to wait 3 more weeks until rust hits 1.0 and then do it in rust)
[21:50] <stellar-slack> (jk)
[21:50] <stellar-slack> :simple_smile:
[21:50] <stellar-slack> I looked into json-api, hal, siren, and json-ld
[21:50] <stellar-slack> ha
[21:50] <stellar-slack> I’ve played a bit with rust and can see it’s fit as well :simple_smile:
[21:51] <stellar-slack> I was leaning towards json-ld, for a number of reasons, but to be honest the spec is dense and automated client support is sparse.
[21:52] <stellar-slack> HAL was specifically chosen because it’s a very simple hypermedia layer on top of json, but I’m not tied to it.
[21:52] <stellar-slack> Library support seems pretty good
[21:52] <stellar-slack> Well, that’s my main question, is HAL well supported in JS UI frameworks and other server frameworks? I’ve struggled to find many tools that support it :simple_smile:
[21:53] <stellar-slack> ah :simple_smile: one sec, there’s a wiki page
[21:53] <stellar-slack> https://github.com/mikekelly/hal_specification/wiki/Libraries
[21:54] <stellar-slack> I didn’t look into all of them, to be honest. The library I use in horizon makes it trivial to switch to json-api or siren, so I punted a bit on fully exploring the entire ecosystem
[21:55] <stellar-slack> since then, I’ve seen more push from the json-api folks, so that’s a possibility
[21:57] <stellar-slack> My justification for HAL is that it’s not too much complexity overtop of plain-ole-json that working with it manually is onerous, but the benefits you get with library support are worthwhile.
[21:58] <stellar-slack> There is an argument for plain-old JSON over eventsource-everything, to deal with the streaming nature of all the data concerned.
[22:03] <stellar-slack> In other words, just create a well defined set of eventsource endpoints and just pipe simple JSON over it. eg:
[22:03] <stellar-slack> ```
[22:03] <stellar-slack> /transactions/
[22:03] <stellar-slack> /transactions/account/
[22:03] <stellar-slack> /offers/
[22:03] <stellar-slack> /offers/account/
[22:03] <stellar-slack> /offers/orderbook/
[22:03] <stellar-slack> ```
[22:03] <stellar-slack> where `Last-Event-Id` can be used where appropriate as the last seen ledger. If all endpoints could be reversed, you could supply historical data in the same way, for paging back through data, just close the eventsource when you’ve received enough data. Restart with `Last-Event-Id` set appropriately when you want some data.
[22:03] <stellar-slack> Controversial :simple_smile:
[22:03] <stellar-slack> is "plain-old" like really 1.0 ?
[22:11] <stellar-slack> I think you and me are on the same page for when it comes to streaming. I definitely want to support the scenario you describe. I think my current plan is this:
[22:11] <stellar-slack> For "collection" resources, requesting a representation of the resource as text/event-stream will stream the collection to you where each element is the HAL representation of that element. That will amount to a plain json object with a "_links" additional attribute. Requesting a representation of the collection resource as "application/hal+json" will return a page of that collection via embedding each element as a
[22:11] <stellar-slack> Having each streamed element be represented as HAL lets us maintain the nice story we have around navigating the api. You could, for example, be listening to `/transactions` and navigate through to each transaction's participants by following the link provided to you in the HAL representation of a transaction.
[22:13] <stellar-slack> By having support for non-streamed collection resources, we can still provide a simple means to follow along as the collection grows: Simply continually navigate along the "next_page" link of each page you load to load all of the data.
[22:14] <stellar-slack> That for clients that don’t have support for SSE or do not want to use it, for whatever reason
[22:21] <stellar-slack> I guess it’s the toss-up between data which is constantly changing and having an easily navigable structure for snapshots of the data. SSE is so simple that a parser only needs to be able to read a chunked HTTP response and follow these simple rules:
[22:21] <stellar-slack> http://www.w3.org/TR/2011/WD-eventsource-20111020/#event-stream-interpretation
[22:21] <stellar-slack> Anyway, the nice thing about stellar’s design is that the data is easily accessible from SQL, so multiple front ends to the data are easy to add :simple_smile: The only real other question I have is how the front end client will be notified of the last changes to the SQL data from the most recent ledger.
[22:23] <stellar-slack> > The only real other question I have is how the front end server will be notified of the last changes to the SQL data from the most recent ledger.
[22:23] <stellar-slack> I don’t understand the question. By fronte nd server do you mean horizon?
[22:24] <stellar-slack> The history system
[22:25] <stellar-slack> Just any software that has a connection to the SQL database. If stellar-core does some UPDATE/INSERT/DELETE’s as a result of the latest ledger, how does that other software (Horizon or another piece of software) know what changed?
[22:25] <stellar-slack> ah! At present we don’t have any notification. you have to poll. I’m sure the stellar-core guys are open to suggestions though
[22:25] <stellar-slack> what about using the history archive system to achieve this notification?
[22:26] <stellar-slack> yeah, I suppose you could configure a history archive to trigger a script
[22:27] <stellar-slack> or have the front end software just watch some directory the history archive is publishing to
[22:27] <stellar-slack> but yeah it takes an arbitrary command so using a script would work too
[22:28] <stellar-slack> My understanding (maybe incorrect) is that the history archive is always running behind the live ledger by some amount
[22:28] <bittrex-richie> quick question all..
[22:28] <bittrex-richie> we are using settings to validate whether an address is valid or not
[22:28] <stellar-slack> @monsieurnicolas or @graydon could you comment on that notion? Would you recommend andrew’s solution?
[22:28] <bittrex-richie> however, for accounts that havent' had a transaction yet, we are getting success=false even though the address is valid
[22:29] <bittrex-richie> is there a better way to do what we're tryign to do?
[22:29] <stellar-slack> bittrex richie, stellar-lib has an "isValid" function you can pull in
[22:29] <stellar-slack> if you're using javascript
[22:30] <bittrex-richie> i'm acually using stellar-rest right now
[22:30] <stellar-slack> history snapshots only triggers periodically, not at every ledger close
[22:30] <stellar-slack> see here: https://github.com/stellar/stellar-payments/blob/master/lib/client.js#L40
[22:30] <stellar-slack> for an example
[22:30] <stellar-slack> scott: the history publishing system was designed to be one way of doing this, yes -- you can configure history publication any way you like, it runs arbitrary commands -- but we also thought about doing it live with a notification channel or an SQL trigger
[22:30] <stellar-slack> scott: history publish events happen ~5 minutes apart (every 64 ledgers) so it's probably a bit too slow for "live"
[22:31] <stellar-slack> graydon: oh, yeah that's too slow for this
[22:31] <stellar-slack> good to know. Thanks for the clarification!
[22:32] <bittrex-richie> yeah.. i m might rewrite our stuff to use stellar lib later
[22:32] <stellar-slack> I have a meeting to go to. be back in a bit
[22:32] <bittrex-richie> unfortunately we rely on stellar-rest right now and it looks like we're stuck with this wonky behavior
[22:32] <stellar-slack> @bittrex-richie, are you refering to https://github.com/umbrellab/stellar-rest?
[22:32] <stellar-slack> because that already uses stellar-lib
[22:32] <stellar-slack> even pulling from the database every 100 ms (for example) isn't a bad thing, you can pull for the last closed ledger in the state table to trigger a more expensive select from the other tables
[22:32] <stellar-slack> nvm, pushed back 30 minutes :simple_smile:
[22:33] <bittrex-richie> andrew: i am... however it doesnt' expose the functinality
[22:35] <stellar-slack> ah i see
[22:37] <stellar-slack> It’s interesting to study how meteor tries to solve the same problem:
[22:38] <stellar-slack> https://www.meteor.com/livequery
[22:38] <stellar-slack> I definitely will.. thanks for the link
[22:42] <stellar-slack> @monsieurnicolas: 100ms can be a long in time in algorithmic trading :simple_smile:
[22:43] <stellar-slack> yeah, I am pretty certain that beneath a certain time resolution, the stellar platform will not be a great candidate for algorithmic trading.
[22:43] <stellar-slack> at least not high frequency
[22:43] <stellar-slack> maybe on the order of seconds-to-minutes
[22:45] <stellar-slack> Depends on how many transactions and markets are being handled. High frequency isn’t the same as algorithmic, arbitrage trialling of all incoming transactions is one thing I know that happens on “another” network. You’d be surprised how important it can be to get the data as early as possible.
[22:45] <stellar-slack> and to build an edge at that resolution, you need to hook at the consensus layer to see what may be coming
[22:46] <stellar-slack> Well, that’s it exactly, you want to see the incoming transactions for the current ledger before they are accepted.
[22:46] <stellar-slack> yeah, we don't have a way to get this data outside of the core right now
[22:47] <stellar-slack> you'd want to watch for SCP messages, positions across the network and build a model
[22:47] <stellar-slack> Have you considered abstracting the SQL DDL and DML parts outside of stellar core and having a simpler data retrieval and storage model which could feed to multiple outputs?
[22:47] <stellar-slack> I am sure some people are interested in this :simple_smile:
[22:48] <stellar-slack> Yep, building a network peer is a fun challenge :simple_smile:
[22:48] <stellar-slack> oh but what I am saying is that this data doesn't go into SQL at all right now
[22:48] <stellar-slack> we only store validated things in SQL
[22:48] <stellar-slack> Yes, I understand that proposals are only in-memory, but the accepted data could be fed to multiple outputs.
[22:49] <stellar-slack> s/proposals/proposed transactions/
[22:49] <stellar-slack> I think we could add a way to register notification endpoints - SQL as a reliable queue allows to not block the main process on external processes
About StellarVerse IRC Logger
StellarValue IRC Logger
is part of