rjones (Sun, 17 Jun 2018 16:28:00 GMT):
amundson

rjones (Sun, 17 Jun 2018 16:28:10 GMT):
Has left the channel.

Dan (Tue, 19 Jun 2018 19:21:15 GMT):
Has joined the channel.

Dan (Tue, 19 Jun 2018 19:21:51 GMT):
First! :D

Dan (Tue, 19 Jun 2018 19:22:08 GMT):
@amundson what kind of crack are you on?

amundson (Tue, 19 Jun 2018 19:32:31 GMT):
like, which brand?

Dan (Tue, 19 Jun 2018 19:35:02 GMT):
exactly! :D

Dan (Tue, 19 Jun 2018 19:36:35 GMT):
So my mental model of protos is that is the common thing that binds all the sdks & components. I'm curious about your email that they don't have to be sync'd.

Dan (Tue, 19 Jun 2018 19:38:27 GMT):
I'm also not familiar with the branching/tagging limitations you alluded to for git submodules. If you want to say a little more about that too, that would be helpful.

amundson (Tue, 19 Jun 2018 20:10:44 GMT):
re:submodules - you can't tag across repos

amundson (Tue, 19 Jun 2018 20:11:04 GMT):
you also can't branch across repos

amundson (Tue, 19 Jun 2018 20:11:30 GMT):
it's really horrific, IMO

amundson (Tue, 19 Jun 2018 20:26:02 GMT):
in terms of protos staying in sync. say we have a proto related to protocol level 1 and the validator goes to protocol level 2 (with backward support for 1); we don't need all the SDKs to immediately go to protocol level 2.

amundson (Tue, 19 Jun 2018 20:26:43 GMT):
in fact, it might not be desirable depending on the type of protobuf change we make

zac (Tue, 19 Jun 2018 20:30:48 GMT):
Has joined the channel.

Dan (Tue, 19 Jun 2018 20:42:53 GMT):
Maybe that works for submodules then. (I'm not pushing submodules but just want to talk through ideas). If we make a proto level 2 then we have to make that same change in every repo that wants it. Or if we use submodules drawing from a single protos repo, then the depending project just needs to do a submodule update to pickup the new change.

amundson (Tue, 19 Jun 2018 21:09:16 GMT):
sounds like you are pushing submodules

amundson (Tue, 19 Jun 2018 21:10:11 GMT):
if we hadn't stabilized the API already, I'd think this was a real issue

Dan (Tue, 19 Jun 2018 21:20:07 GMT):
I get 5 mickels everytime a submodule is used.

Dan (Tue, 19 Jun 2018 21:20:43 GMT):
The idea of copying the same file manually across n repos just strikes me as bad.

amundson (Tue, 19 Jun 2018 22:32:51 GMT):
it's not great but also not necessarily the #1 thing to optimize for

amundson (Tue, 19 Jun 2018 22:33:46 GMT):
I think if we were going to solve this, we would probably want to produce a sdk-protos package or something

amundson (Tue, 19 Jun 2018 22:35:04 GMT):
not sure how you handle the case where you need different version levels of the protos though

amundson (Tue, 19 Jun 2018 22:35:59 GMT):
if we were doing this earlier on, we probably would go the sdk-protos route and mandate that all sdks had to stay lock-step with it as it changed

tomislav (Wed, 20 Jun 2018 00:46:48 GMT):
Has joined the channel.

tomislav (Wed, 20 Jun 2018 00:50:38 GMT):
Is there a versioning guideline for the SDK releases? Should we match the SDK version to the core release supported?

amolk (Wed, 20 Jun 2018 07:50:47 GMT):
Has joined the channel.

yadhuksp (Wed, 20 Jun 2018 11:32:49 GMT):
Has joined the channel.

rbuysse (Wed, 20 Jun 2018 14:27:32 GMT):
Has joined the channel.

amundson (Wed, 20 Jun 2018 14:42:31 GMT):
I think they should be 0.x if they are prior to having a finalized API to which we are providing backward compatibility support]

amundson (Wed, 20 Jun 2018 14:43:07 GMT):
even the Rust SDK then would be 0.x until we finalize the API, even though it is feature complete (I think)

zac (Wed, 20 Jun 2018 14:43:38 GMT):
Don't all the SDKs have finalized APIs?

amundson (Wed, 20 Jun 2018 14:44:05 GMT):
no

zac (Wed, 20 Jun 2018 14:44:13 GMT):
They were included in the 1.0 discussions. And I thought modifying them was verboten at this point.

amundson (Wed, 20 Jun 2018 14:44:44 GMT):
https://sawtooth.hyperledger.org/docs/core/nightly/master/app_developers_guide/sdk_table.html

amundson (Wed, 20 Jun 2018 14:45:03 GMT):
only Python, Go, and Javascript have Stable API

zac (Wed, 20 Jun 2018 14:45:09 GMT):
Ah

zac (Wed, 20 Jun 2018 14:45:16 GMT):
Yeah, I was talking about those

Dan (Wed, 20 Jun 2018 14:45:23 GMT):
I think a graph of people moving from channel to channel on chat would be entertaining

zac (Wed, 20 Jun 2018 14:45:23 GMT):
and Rust I guess

amundson (Wed, 20 Jun 2018 14:45:30 GMT):
we should update that, the Rust one is more mature now and dotnet isn't listed

zac (Wed, 20 Jun 2018 14:45:47 GMT):
In any case, I agree their version numbers should _not_ match core's

zac (Wed, 20 Jun 2018 14:46:40 GMT):
Even if they are stable or whatever else, that will be a pain to maintain. They will follow their own development path and will inevitably need their own versioning.

amundson (Wed, 20 Jun 2018 14:47:02 GMT):
yes, that is also how I'm thinking about it

amundson (Wed, 20 Jun 2018 14:47:15 GMT):
we will have to keep our contentious discussions on #sawtooth I guess

zac (Wed, 20 Jun 2018 15:20:14 GMT):
hah

zac (Wed, 20 Jun 2018 15:21:29 GMT):
I'm always looking for new opportunities to disagree with you. Unfortunately, this was not one of them.

Dan (Wed, 20 Jun 2018 16:37:52 GMT):
which SDKs stay in core? Python and Rust?

kelly_ (Wed, 20 Jun 2018 16:57:08 GMT):
Has joined the channel.

amundson (Wed, 20 Jun 2018 22:18:18 GMT):
for now, yes

Dan (Thu, 21 Jun 2018 02:15:17 GMT):
_... he said ominously_

tungdt_socoboy (Thu, 21 Jun 2018 11:46:08 GMT):
Has joined the channel.

FrankC01 (Thu, 21 Jun 2018 13:14:29 GMT):
Has joined the channel.

pyzhang (Thu, 21 Jun 2018 15:50:24 GMT):
Has joined the channel.

pschwarz (Fri, 22 Jun 2018 14:15:00 GMT):
Has joined the channel.

danintel (Fri, 22 Jun 2018 17:11:19 GMT):
Has joined the channel.

agunde (Fri, 22 Jun 2018 21:49:55 GMT):
Has joined the channel.

ltseeley (Fri, 22 Jun 2018 21:51:14 GMT):
Has joined the channel.

ltseeley (Fri, 22 Jun 2018 21:54:59 GMT):
Speaking of Rust SDK, there was a minor update to how the Rust SDK handles getting and setting state. For the sake of flexibility and consistency with other SDKs, the `get_state()` method takes a list of addresses as an argument (rather than a single address) and `set_state()` now takes a map of address/value pairs to set (rather than a single address/value pair). https://github.com/hyperledger/sawtooth-core/commit/a95d623640eabe490c8a3a28c0d94eb2c71cced4

neocameback (Tue, 26 Jun 2018 02:40:27 GMT):
Has joined the channel.

bridgerherman (Tue, 26 Jun 2018 13:15:04 GMT):
Has joined the channel.

rootDistress (Wed, 27 Jun 2018 07:24:39 GMT):
Has joined the channel.

amundson (Tue, 03 Jul 2018 21:17:51 GMT):
I think we should change the rust crate name from sawtooth_sdk to sawtooth-sdk

FrankCastellucci (Sun, 08 Jul 2018 20:14:51 GMT):
Has joined the channel.

formax (Mon, 09 Jul 2018 19:08:13 GMT):
Has joined the channel.

pankajgoyal (Mon, 16 Jul 2018 13:31:16 GMT):
Has joined the channel.

mfford (Mon, 16 Jul 2018 14:07:14 GMT):
Has joined the channel.

LeonardoCarvalho (Mon, 16 Jul 2018 14:13:17 GMT):
Has joined the channel.

LeonardoCarvalho (Mon, 16 Jul 2018 17:46:13 GMT):
Hello

LeonardoCarvalho (Mon, 16 Jul 2018 17:47:18 GMT):
@amundson Suggested that I joined this channel, to help in the Java front

LeonardoCarvalho (Mon, 16 Jul 2018 17:47:52 GMT):
I did a PoC with some ideas and a functional implementation at https://github.com/CarvalhoLeonardo/sawtooth-core/tree/reactor/sdk/java-reactive

LeonardoCarvalho (Mon, 16 Jul 2018 17:48:15 GMT):
Any feedback is the most welcome

amolk (Mon, 16 Jul 2018 18:47:51 GMT):
BTW, there have been some PRs raised for the Java SDK recently.

LeonardoCarvalho (Tue, 17 Jul 2018 11:03:32 GMT):
Yeah, I've seen some, I would like to know the ways to interact with the project

LeonardoCarvalho (Tue, 17 Jul 2018 11:04:12 GMT):
I have some "old man ways" to do things that I alway adapt to projects I act on. :)

LeonardoCarvalho (Tue, 17 Jul 2018 11:08:55 GMT):
I'm seeing the videos now

LeonardoCarvalho (Tue, 17 Jul 2018 12:23:09 GMT):
I got a question

LeonardoCarvalho (Tue, 17 Jul 2018 12:23:18 GMT):
there's some java code of the current SDK

LeonardoCarvalho (Tue, 17 Jul 2018 12:23:23 GMT):
with the Intel copyright

LeonardoCarvalho (Tue, 17 Jul 2018 12:23:47 GMT):
I did create new classes, reused some of the old ones

LeonardoCarvalho (Tue, 17 Jul 2018 12:23:54 GMT):
how I need to handle the copyright notice?

sTyL3 (Tue, 17 Jul 2018 13:30:31 GMT):
Has joined the channel.

Dan (Tue, 17 Jul 2018 14:30:48 GMT):
All of the language SDKs are moving to their own repos. Unfortunately for the Java SDK we have PRs backed up waiting to get in, but no PR to move the SDK to its own repo (unless one was raised recently?). I propose that we get the existing PRs merged and then get the migration PR created after that @amundson @ryanbeck.

Dan (Tue, 17 Jul 2018 14:36:10 GMT):
@LeonardoCarvalho very happy to have you helping with the java sdk :) This contributing guide might help you with different "old man ways" https://sawtooth.hyperledger.org/docs/core/releases/latest/community/contributing.html As far as the banner at the top of the file, the linux foundation has recommended that for new files we use verbiage like ("copyright hyperledger sawtooth project and its contributors") If all of the file is contributed by a single entity you can probably reference that name instead of HL Sawtooth. The Linux foundation is supposed to offer more prescriptive guidance soon. Meanwhile we are holding off on refactoring that banner on existing files.

LeonardoCarvalho (Tue, 17 Jul 2018 15:10:20 GMT):
Ok, I've ready the contributing doc, my "old ways" don't interfere with that at all :)

LeonardoCarvalho (Tue, 17 Jul 2018 15:10:40 GMT):
About the Jenkins build, is there documentation on procedures and formats?

LeonardoCarvalho (Tue, 17 Jul 2018 15:11:32 GMT):
I usually create 3 test profiles (unit/local, unit/mock|fake, functional/test environment)

LeonardoCarvalho (Tue, 17 Jul 2018 15:11:53 GMT):
the 2 first I intend to run on JEnkins

Dan (Tue, 17 Jul 2018 15:40:24 GMT):
when you submit your PR jenkins will automatically build it and execute the unit tests. I'm not sure where the profiles fit in if that's a junit thing or a jenkins thing?

LeonardoCarvalho (Tue, 17 Jul 2018 16:56:41 GMT):
It's a architectural thing. Jenkins has some configuration patterns to handle them, I just need to know how are the current suite configured, to fit in

Dan (Tue, 17 Jul 2018 17:19:50 GMT):
there is/was a jenkins file in the root of the rep, but with this SDK dispersal all the jenkins stuff is also changing to jjb. @rberg or @pankajgoyal would know current/future jenkins config

LeonardoCarvalho (Tue, 17 Jul 2018 17:29:27 GMT):
ok, thank you!

LeonardoCarvalho (Wed, 18 Jul 2018 11:33:50 GMT):
question : who can give me some advice on 0mq?

FrankCastellucci (Wed, 18 Jul 2018 11:37:52 GMT):
What is the question?

LeonardoCarvalho (Wed, 18 Jul 2018 13:02:09 GMT):
I want to create stress test

LeonardoCarvalho (Wed, 18 Jul 2018 13:02:18 GMT):
for the TP

LeonardoCarvalho (Wed, 18 Jul 2018 13:03:11 GMT):
based on this code

LeonardoCarvalho (Wed, 18 Jul 2018 13:03:13 GMT):
https://github.com/zeromq/jeromq3-x/blob/master/src/test/java/guide/lbbroker3.java

LeonardoCarvalho (Wed, 18 Jul 2018 13:03:47 GMT):
But I'm getting some trouble wiring it in the TP

rbuysse (Wed, 18 Jul 2018 20:24:27 GMT):
Since we're on the topic of the Java sdk... when that moves into its own repo, what version should I use

rbuysse (Wed, 18 Jul 2018 20:48:48 GMT):
what do we think about 0.1?

rbuysse (Wed, 18 Jul 2018 20:48:59 GMT):
Also the same question for CXX

Dan (Wed, 18 Jul 2018 21:22:54 GMT):
I reached out to one user of the cxx sdk and did not get a response for impact of rolling back that version. Did java have a previous version? Is that also a rollback?

LeonardoCarvalho (Thu, 19 Jul 2018 11:32:17 GMT):
The java version looks untouched for almost an year

LeonardoCarvalho (Thu, 19 Jul 2018 11:33:12 GMT):
Since I intend to revamp it entirely, creating maven modules, among other things

LeonardoCarvalho (Thu, 19 Jul 2018 11:33:41 GMT):
the version 0.0.1 looks fine for me

LeonardoCarvalho (Thu, 19 Jul 2018 11:35:46 GMT):
https://i.imgur.com/PgXhlA0.gifv (me, right now)

Dan (Thu, 19 Jul 2018 15:08:13 GMT):
lol

Dan (Thu, 19 Jul 2018 15:08:46 GMT):
Yeah there's a few PRs backed up waiting for the repo change.

LeonardoCarvalho (Thu, 19 Jul 2018 17:37:12 GMT):
an indian dude already asked for a new module, lol

LeonardoCarvalho (Fri, 20 Jul 2018 11:30:47 GMT):
oh well, we willget an andoird SDK

LeonardoCarvalho (Fri, 20 Jul 2018 11:30:50 GMT):
android

Dan (Fri, 20 Jul 2018 13:21:41 GMT):
oh yeah? that would be cool.

LeonardoCarvalho (Fri, 20 Jul 2018 13:48:49 GMT):
yeah, AFAICS, there's a little issue in the supported JDK only

LeonardoCarvalho (Fri, 20 Jul 2018 13:49:01 GMT):
Oracle gone crazy on the forced update

amundson (Mon, 23 Jul 2018 21:02:35 GMT):
@LeonardoCarvalho very happy you are going to revamp the java sdk

amundson (Mon, 23 Jul 2018 21:04:17 GMT):
I'm curious your thoughts on whether we should essentially bring the java sdk on-par with what we have with the other SDKs (we have tried to keep most of the fairly similar), or if you have a different vision completely for what the SDK should contain.

LeonardoCarvalho (Tue, 24 Jul 2018 11:02:38 GMT):
Hello.

LeonardoCarvalho (Tue, 24 Jul 2018 11:06:03 GMT):
Well, I have a vision of a multi-module SDK, with at least 3 of them : Common (with the protobuf related artifacts), Crypto configuration -- JCA and such, one to handle the REST client, using Jersey as base, and the last one for the TP code.

LeonardoCarvalho (Tue, 24 Jul 2018 11:06:10 GMT):
the 2 last would depend on the first

LeonardoCarvalho (Tue, 24 Jul 2018 11:06:56 GMT):
a parent POM would manage the general dependencies, and define default values on some build variables

LeonardoCarvalho (Tue, 24 Jul 2018 11:07:44 GMT):
but a guy from India is asking for an Android SDK, and I didn't know yet if is possible to build it as a module for the SDK...

LeonardoCarvalho (Tue, 24 Jul 2018 11:08:10 GMT):
I've built my fork based on the Python SDK code.

LeonardoCarvalho (Tue, 24 Jul 2018 13:11:11 GMT):
Sure, if you think that's more to add, I'm all ears.

amundson (Tue, 24 Jul 2018 16:03:29 GMT):
we avoided including a rest client in the official SDKs because we didn't want to support a specific REST client technology and the 'normal' pattern we use doesn't include writing apps against the the sawtooth REST API anyway (we usually roll a custom REST API)

amundson (Tue, 24 Jul 2018 16:05:04 GMT):
IMO, we should avoid a 'common' dumping ground and be more explicit; if we want to package up the protobuf stuff separately, how about one with just that?

amundson (Tue, 24 Jul 2018 16:07:43 GMT):
I'm not that familiar with JCA but I'm assuming that could go in a module related to signing code, similar to how we broke signing out of the python sdk?

LeonardoCarvalho (Tue, 24 Jul 2018 16:52:58 GMT):
That's feasible. Some thoughts:

LeonardoCarvalho (Tue, 24 Jul 2018 16:53:40 GMT):
Java has 3 big "fronts" on REST clients, Jersey is the simplest, and almost everything done over it is usable in the other fronts. That would help a lot.

LeonardoCarvalho (Tue, 24 Jul 2018 16:56:19 GMT):
The "Common" package indeed was a little hack. But, since the classes created on the maven plugin are very intimate with the crypto setup, I tried to create the division over the packages, not a module. Usually I apply the "core", "commons", etc, on situation where pieces don't have a common domain, but the operation of the pieces would be indivisible.

LeonardoCarvalho (Tue, 24 Jul 2018 16:57:40 GMT):
JCA is in only a catalog, in a way. It would be easy to separate it, but I think that would only create unnecessary noise.

LeonardoCarvalho (Tue, 24 Jul 2018 16:59:03 GMT):
Sure, there's no sense in the Java SDK be a complete alien compared to the other languages, but Java is known to be stubbornly adherent to some procedures... (again, the "old man ways" talking... :-) )

LeonardoCarvalho (Tue, 24 Jul 2018 17:01:32 GMT):
Fortunately, due to the, aham, "culture" on my country, I'm very used to create maven setups for not-so-adherent projects structures, there's no problem at all in changing my current fork

Dan (Tue, 24 Jul 2018 18:40:04 GMT):
I do think that we can improve our ease of development for client apps across SDKs. Transaction processor development is fairly easy. I'm not sure client dev has seen as much ease of use attention.

LeonardoCarvalho (Tue, 24 Jul 2018 20:56:04 GMT):
That's my feeling as well. Since we have a REST API, and protobuf defined payloads, I was a little baffled that I couldn't send a simple request to the Integer or XO TPs ...

tungdt_socoboy (Wed, 25 Jul 2018 17:02:29 GMT):
Hi Everyone, When reading and checking the Transaction Processor sample, and try to do some twitch, I see that the current implementation of Transaction Processor and SDK doesn't allow it to be able to handle parallel requests from Validator, is there any reason for that? Which require the transaction processor to process one by one? I think if the current implementation of Parallel Scheduler which can compute the dependency of transactions, then the transaction processor should be able to process in parallel. If it can do that, this will boost the process of transaction validation a lot

Dan (Wed, 25 Jul 2018 17:07:35 GMT):
which language SDK?

Dan (Wed, 25 Jul 2018 17:08:12 GMT):
For those language SDKs that aren't offering multi-threading you can still launch multiple instances of your TP and then the validator will round-robin across them.

tungdt_socoboy (Wed, 25 Jul 2018 17:19:37 GMT):
ah

tungdt_socoboy (Wed, 25 Jul 2018 17:19:52 GMT):
we could run multiple instances of TP and the validator will round-robin?

tungdt_socoboy (Wed, 25 Jul 2018 17:19:55 GMT):
I haven't try that

tungdt_socoboy (Wed, 25 Jul 2018 17:19:58 GMT):
I use Python

tungdt_socoboy (Wed, 25 Jul 2018 17:20:05 GMT):
Will make a try and see how it works

tungdt_socoboy (Wed, 25 Jul 2018 17:20:18 GMT):
Thanks for your suggestion @Dan

tungdt_socoboy (Wed, 25 Jul 2018 17:20:18 GMT):
Thanks for your suggestion @Dan Dan

kirkwood (Wed, 25 Jul 2018 17:31:37 GMT):
Has joined the channel.

amundson (Thu, 26 Jul 2018 05:45:43 GMT):
@tungdt_socoboy some of the other SDKs support concurrent transaction execution (go and rust to some extent). For Python, it didn't seem worth spending much time on it since Python's GIL will prevent using more than a CPU core anyway.

amundson (Thu, 26 Jul 2018 05:47:39 GMT):
even in that case, the parallel scheduler can help keep the TP busy because it will give it a maximum amount of work to do in its queue

amundson (Thu, 26 Jul 2018 05:49:37 GMT):
and multiple instances of the TP are a supported configuration - that's how you would do rolling upgrades too, if you wanted to upgrade a TP with minimal interruption

amundson (Thu, 26 Jul 2018 05:53:33 GMT):
@Dan @LeonardoCarvalho the original reason for excluding client-side support from the SDK was a) keep SDKs small, we want a lot of them; b) didn't want to choose favorites with respect to client REST libraries; c) it's not actually how you would develop an "real" app (using the REST API) because "real" apps use state delta export and thus their own REST APIs

amundson (Thu, 26 Jul 2018 05:56:18 GMT):
I think it would be better to spend time on making it trivial to write state-delta-export SDK code than client code. But maybe if we go down the road of having client code, we can solve the picking-a-rest-client-implementation problem in some way (maybe the client library should be language and framework specific (sawtooth-client-sdk-java-jersey or some such)

amundson (Thu, 26 Jul 2018 05:57:47 GMT):
also, if you write a client SDK, I'm not sure it makes sense to go through the REST API - why not go directly to the validator, so you can use it in your REST API implementation; or better yet, make it support both the REST API and direct validator communication.

amundson (Thu, 26 Jul 2018 05:58:54 GMT):
I'd be interested to see a refactor of something like part of the CLI code to prove how much better it is to avoid the 3 lines of http submission code though :)

amundson (Thu, 26 Jul 2018 06:00:05 GMT):
(that's not a serious suggestion - we should rewrite all that CLI code in rust anyway, not worth the effort)

LeonardoCarvalho (Thu, 26 Jul 2018 11:00:48 GMT):
I completely understand what you are saying. But, as a old player on the J2EE ecosystem, I would like to share my vision that most of the real world implementations would need to use the REST client as base to create a permissioned, monitorable and multi-purpose gateways inside data flows. Is what almost 99% of "enterprisey" deploys look like

LeonardoCarvalho (Thu, 26 Jul 2018 11:01:25 GMT):
I completely on boat on creating a rest client package with the REST base client name on it

LeonardoCarvalho (Thu, 26 Jul 2018 11:02:43 GMT):
My perception was that auto-generating most of the boilerplate using the YAML file on the main project were an easy and controllable way of giving directions to the newbies

LeonardoCarvalho (Thu, 26 Jul 2018 11:04:33 GMT):
Using the protobuf serialization to send the data and receiving the protobuf-to-json capabilities removed most of the idiosyncrasies on the difference behavior of maps on the languages, and that is a really good bonus

LeonardoCarvalho (Thu, 26 Jul 2018 11:05:51 GMT):
better yet, using REST to shield other languages, versions, platforms, is the most used interoperational pattern inside IT companies...

amundson (Thu, 26 Jul 2018 16:48:02 GMT):
we don't want to drive newbies to implement apps against the REST API if that's not the desired way to write real applications. 99% of any app is going to be data retrieval, which is done by implementing state delta export and then writing a normal web stack against that materialized database. that leaves only transaction submission and status as interesting parts of the REST API

amundson (Thu, 26 Jul 2018 16:48:02 GMT):
we don't want to drive newbies to implement apps against the Sawtooth REST API if that's not the desired way to write real applications. 99% of any app is going to be data retrieval, which is done by implementing state delta export and then writing a normal web stack against that materialized database. that leaves only transaction submission and status as interesting parts of the Sawtooth REST API

amundson (Thu, 26 Jul 2018 16:49:28 GMT):
so, for example, we wouldn't want developers thinking they should write against the Sawtooth REST API to retrieve state. it might work for hello world / tic-tac-toe level examples, but since you can't do any real querying it's not a valid pattern for any real app

amundson (Thu, 26 Jul 2018 16:50:31 GMT):
(FWIW, we may not be entirely clear everywhere the correct pattern currently, obviously)

amundson (Thu, 26 Jul 2018 16:57:50 GMT):
which doesn't mean we shouldn't provide client sdk support, but my point is more that we should figure out how to make the state delta processor easier so everyone can accomplish the pattern (including newbies). and maybe focus more on enabling adding submission to rest apis being written that front the materialized database

FrankCastellucci (Thu, 26 Jul 2018 18:52:08 GMT):
Wrapping ZMQ in the SDK (providing submission, clean event subscriptions, etc.) would be a welcome addition to all the SDK

FrankCastellucci (Thu, 26 Jul 2018 18:52:23 GMT):
Or part of a 'client' pak

FrankCastellucci (Thu, 26 Jul 2018 18:52:23 GMT):
A 'client SDK'?

LeonardoCarvalho (Thu, 26 Jul 2018 19:06:28 GMT):
I'm working on that

LeonardoCarvalho (Thu, 26 Jul 2018 19:06:29 GMT):
:)

LeonardoCarvalho (Thu, 26 Jul 2018 19:06:55 GMT):
I understand the vision of @amundson now, and makes sense;

LeonardoCarvalho (Thu, 26 Jul 2018 19:07:09 GMT):
I'm not well versed in 0MQ

LeonardoCarvalho (Thu, 26 Jul 2018 19:07:45 GMT):
and to do some tests I'm using the Majordomo implementation with a little Reactor-style programming

LeonardoCarvalho (Thu, 26 Jul 2018 19:09:36 GMT):

2018-07-24.png

amundson (Thu, 26 Jul 2018 20:13:13 GMT):
following the pattern of breaking out the client SDKs by client framework, maybe we do sawtooth-client-sdk-java-jersey, sawtooth-client-sdk-java-zmq, etc.

amundson (Thu, 26 Jul 2018 20:17:33 GMT):
@LeonardoCarvalho the 0MQ piece should be the same code as we have for implementing the TP communication (a 'stream' class underneath, or similar) which basically lets you send a message, listen for a response (with a future), or provide a listener for new messages (that are requests from the server, not responses). currently state delta export code is written using that layer. in any case, the conversation ends up being creating the protobuf message and calling send(). it is nearly but not completely 1:1 with the REST API

amundson (Thu, 26 Jul 2018 20:19:04 GMT):
i like the idea of having an API to do that stuff and then having multiple implementations, one for each transport layer

FrankCastellucci (Thu, 26 Jul 2018 20:40:51 GMT):
@amundson You thinking the client SDK in the respective SDK repos or a more central client repos with multiple language packs?

amundson (Thu, 26 Jul 2018 21:05:10 GMT):
@FrankCastellucci I was thinking of it as mostly a packaging detail (still one sdk repo per language)

amundson (Thu, 26 Jul 2018 21:05:53 GMT):
so in Java, if you were using the jersey client, maybe you don't need to pull in the zmq client jar

LeonardoCarvalho (Thu, 26 Jul 2018 21:11:38 GMT):
that's my ideas

LeonardoCarvalho (Thu, 26 Jul 2018 21:12:05 GMT):
at this moment, the "common" has no dependencies on 0mq

LeonardoCarvalho (Thu, 26 Jul 2018 21:12:37 GMT):
I'm thinking about the protobuf-generated artifacts as an abstraction among implementations

LeonardoCarvalho (Thu, 26 Jul 2018 21:13:06 GMT):
there's a nifty Netty implementation based on pure grpc, for example

LeonardoCarvalho (Fri, 27 Jul 2018 12:20:44 GMT):
Guys, I was talking to a friend, and got an interesting question... Would POeT be expansible to also act as an Oracle, to confirm transactions' details from outside of the sawtooth network ?

LeonardoCarvalho (Fri, 27 Jul 2018 12:28:02 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=yvRf8mEdpYkKT3xa4) @amundson What do you think to create a sub-module "client", with one for REST, other for MQ, other for GRPC, and so on ?

jsmitchell (Fri, 27 Jul 2018 22:41:22 GMT):
Has joined the channel.

diegos (Wed, 01 Aug 2018 18:09:25 GMT):
Has joined the channel.

tungdt_socoboy (Sat, 04 Aug 2018 04:04:09 GMT):
Hi everyone, I have a question regarding of how to design an application on Sawtooth: - Firstly, as I see in provided examples from Sawtooth, the only methods implemented inside Transaction Processors are Update/Create actions, like Create Account, Deposit, …. -> By then, I see in Sawtooth, Transaction Processor only keep responsibility of Writing data into blockchain. Other actions like get, query business data will be up to Client responsibility, via RestAPI, with query functions on State. And Client will query and parse raw data in State to extract business data. Is it true? -> If yes, should we have a solution for reading business data by rules defined inside Transaction Processor, as in normal Ethereum smart contract, which have both Get and Create/Update methods inside a Smart Contract, which we can define rules of reading data. - Secondly, I would like to ask for how should we design to apply permission schemas into get/query data in Sawtooth? As you can see in privacy meaning, Only user have right of reading data of his/her state on Blockchain. User A cannot read and query data of user B - Lastly, as above question, I want to ask for a way of better query data without needs of parsing raw business data on State. I would like to have a way to allow Client query data by logic defined on Transaction Processor. I see it possible to update Sawtooth to allow that, but I want to ask for any impaction and intension of Sawtooth developer why we don’t add that into Sawtooth. Is there any impaction to performance or other things? Many thanks :)

amolk (Sat, 04 Aug 2018 04:51:06 GMT):
Hi @tungdt_socoboy as you correctly identified, the Transaction Processors are mainly meant to modify the state and clients can query data directly. TPs are really only meant to be used if the state needs to change. The Merkle Tree isn't a very efficient data structure so trying to do extensive search/querying/processing operations isn't advisable. So we encourage the use of the state-delta mechanism to subscribe to state change events and synchronize data with a traditional database, which can then be used for rich queries or analytics (or really any other usage). This will free up the validator to focus on processing state change transactions and offload the search / querying duties outside.

LeonardoCarvalho (Sun, 05 Aug 2018 15:24:16 GMT):
@tungdt_socoboy , there's an earlier discussion about that on the general chat, and from what I've got from it, the architectural solution would involve setting up an listener to capture relevant block publishing on the validator, and store in the database of the application the data in any suitable ways and forms you would need.

amundson (Tue, 07 Aug 2018 14:28:54 GMT):
@LeonardoCarvalho re:MQ/GRPC - what piece of the system to do these exist in? are you suggesting integration between our zmq interface and MQ/GRPC? the probably would end up being a standalone rest api/state delta processor-like service

LeonardoCarvalho (Tue, 07 Aug 2018 14:30:20 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=vW7F2LuTSMiTKhPTd) @amundson Exactly, it would be an add on, to cover more distinct needs of any users

amundson (Tue, 07 Aug 2018 14:57:10 GMT):
My only concern would be positioning those pieces so that they don't need to be maintained (and could be dropped) if they aren't used (i.e. not considering them part of the stable API).

LeonardoCarvalho (Tue, 07 Aug 2018 17:12:07 GMT):
sure! I was only considering it as a bonus, since I've seen some projects that would fit in such a scenario

LeonardoCarvalho (Thu, 09 Aug 2018 12:35:45 GMT):
Guys, about my earlier question, is there an idea to implement something based on Oracles (external confirmation of data) for Sawtooth?

LeonardoCarvalho (Thu, 09 Aug 2018 12:37:12 GMT):
I've got some scenarios from hypothetical clients that would need something like that, like bank transfers confirmations

LeonardoCarvalho (Thu, 09 Aug 2018 12:43:37 GMT):
AAAAANNNNDDD (sorry, during the last week I've got plenty of feedbacks about many scenarios... :woo: ) what about a third type o actor on the network, to store reeeeeeeaaaly big blobs of data, like encrypted files, outside of the blockchain, but with strong references to information about it (like, checksum, signers, etc), to guarantee that no tampering is possible ?

amundson (Thu, 09 Aug 2018 14:03:45 GMT):
@LeonardoCarvalho would that third type of actor be centralized?

LeonardoCarvalho (Thu, 09 Aug 2018 14:03:59 GMT):
no way

amundson (Thu, 09 Aug 2018 14:04:17 GMT):
what would the pattern be? p2p file sharing?

LeonardoCarvalho (Thu, 09 Aug 2018 14:04:36 GMT):
exactly, but with lazy sync

amundson (Thu, 09 Aug 2018 14:06:06 GMT):
you could do that a couple different ways

amundson (Thu, 09 Aug 2018 14:06:51 GMT):
we don't have a roadmap for that specifically, but do for some other features that would help build that

LeonardoCarvalho (Thu, 09 Aug 2018 14:07:00 GMT):
My initial idea would be to offer the "remote backup" of all documents, and, on top of that, serve partial files

LeonardoCarvalho (Thu, 09 Aug 2018 14:07:22 GMT):
my accountant LOVED the idea of show only parts of contracts to other users

amundson (Thu, 09 Aug 2018 14:08:34 GMT):
I think the question for those use cases would be around a) why not centralized; b) how is data shared (privacy/confidentiality/etc.)

amundson (Thu, 09 Aug 2018 14:09:16 GMT):
with (b) also including who runs the nodes

LeonardoCarvalho (Thu, 09 Aug 2018 14:09:17 GMT):
the not centralized is a no brainer, if a computer got destroyed or the disk is lost

LeonardoCarvalho (Thu, 09 Aug 2018 14:09:33 GMT):
the users can restore the data using their private keys

amundson (Thu, 09 Aug 2018 14:09:43 GMT):
shrug, I was including distributed databases hosted on aws as "centralized"

LeonardoCarvalho (Thu, 09 Aug 2018 14:09:51 GMT):
ah, ok

LeonardoCarvalho (Thu, 09 Aug 2018 14:09:53 GMT):
sorry

LeonardoCarvalho (Thu, 09 Aug 2018 14:09:54 GMT):
hee

amundson (Thu, 09 Aug 2018 14:09:55 GMT):
data redundancy is easy

amundson (Thu, 09 Aug 2018 14:10:06 GMT):
(in that, there are so many good solutions for it)

LeonardoCarvalho (Thu, 09 Aug 2018 14:10:29 GMT):
https://geti2p.net/ is a good starting point to implenet a secure way of syncong

LeonardoCarvalho (Thu, 09 Aug 2018 14:10:40 GMT):
syncing*

tungdt_socoboy (Wed, 15 Aug 2018 01:01:02 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=QW4RdAfzPhn2nmxTn) Thank you, that's very make sense to me

tungdt_socoboy (Wed, 15 Aug 2018 01:02:03 GMT):
I have one more question, I see the latest updated Sawtooth Core version already separate the consensus module into separated services, I could run the Devmode very easily but still not able to run PoET consensus on newest version

tungdt_socoboy (Wed, 15 Aug 2018 01:02:27 GMT):
Is there any document or manual for setup and running PoET consensus in latest version?

Dan (Wed, 15 Aug 2018 20:33:21 GMT):
PoET moved to it's own repo now. You might have some leftover files in your git directory causing you problems or maybe just need to get the newer components. checkout the sawooth-poet repo.

Dan (Wed, 15 Aug 2018 20:34:07 GMT):
If that doesn't resolve it, probably a better chat for the #sawtooth-consensus-dev or #sawtooth channels.

tungdt_socoboy (Thu, 16 Aug 2018 04:11:23 GMT):
Hi Dan, I cloned sawtooth-poet repo already and finding a way to work around. The new consensus model based on a consensus engine which connect to validator via 5050 port. Just read through source code and understood how new consensus works already. I'm going to do some setup to make it running. Thank you!

Dan (Thu, 16 Aug 2018 14:46:15 GMT):
great And note that if you are working with any of the formal releases e.g. Sawtooth 1.0.5, things still work the way they had before when all the consensus etc was in the same repo. We will be working on a release - probably called Sawtooth 1.1 - that will reflect the new code organization and use of engines in about a month.

Gabe (Fri, 17 Aug 2018 22:47:31 GMT):
Has joined the channel.

LeonardoCarvalho (Sat, 18 Aug 2018 11:17:33 GMT):
@Dan , the engines' architecture will be language agnostic ?

LeonardoCarvalho (Sat, 18 Aug 2018 11:59:23 GMT):
@Gabe , are you here?

LeonardoCarvalho (Sat, 18 Aug 2018 12:07:40 GMT):
Guys, I just ended a laboratory to create a pressure test on the 0MQ endpoints at https://github.com/CarvalhoLeonardo/LabReactiveMQ I intend to create a suite to test the transformation and the I/O of TPs and Validators implementations Any thoughts are very welcome.

LeonardoCarvalho (Sat, 18 Aug 2018 12:18:27 GMT):

Clipboard - August 18, 2018 9:18 AM

tungdt_socoboy (Sat, 18 Aug 2018 17:18:36 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=wFDTYgFhzoXiPMaDF) @Dan I'm working on the nightly master, I have rebuilt PoET Engine images to include the cryptography scripts, to generate key for it to use to create PoET Wait Cert

Gabe (Sat, 18 Aug 2018 20:11:55 GMT):
@LeonardoCarvalho yes, just tuning in, we have a small team of java and javascript developers for a couple of applications

Dan (Sun, 19 Aug 2018 14:09:40 GMT):
@LeonardoCarvalho yep. Sdks for python and rust are already written.

Dan (Sun, 19 Aug 2018 14:18:55 GMT):
What's our coding standard for line length in rust?

zac (Mon, 20 Aug 2018 12:19:43 GMT):
100

jsmitchell (Mon, 20 Aug 2018 15:00:16 GMT):
:100:

wkatsak (Wed, 22 Aug 2018 11:02:00 GMT):
Has joined the channel.

wkatsak (Wed, 22 Aug 2018 11:02:16 GMT):
Hello, I was wondering if someone could help answer a question with the Go SDK

alchmeina (Thu, 23 Aug 2018 14:18:25 GMT):
Has joined the channel.

danintel (Sat, 25 Aug 2018 18:55:24 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=yMfiocRv2tufw4byY) @wkatsak I would ask at #sawtooth instead of here (which is for development discussion).

LeonardoCarvalho (Sun, 26 Aug 2018 11:52:51 GMT):

python.jpg

jsmitchell (Sun, 26 Aug 2018 17:40:00 GMT):
“Multi”-threading

jsmitchell (Sun, 26 Aug 2018 17:41:54 GMT):
You can have as many threads as you want, but only one runs at a time

AyushKulshrestha (Sun, 26 Aug 2018 19:17:59 GMT):
Has joined the channel.

LeonardoCarvalho (Sun, 26 Aug 2018 20:42:26 GMT):
really ? O.o

jsmitchell (Sun, 26 Aug 2018 21:44:23 GMT):
Yeah, because of the global interpreter lock. The only workloads that are truly parallelizable in python are io-bound workloads

LeonardoCarvalho (Sun, 26 Aug 2018 22:09:50 GMT):
that's good to know

LeonardoCarvalho (Sun, 26 Aug 2018 22:10:04 GMT):
I wasn't aware of this!

sureshtedla (Fri, 31 Aug 2018 17:33:23 GMT):
Has joined the channel.

zZz (Mon, 03 Sep 2018 08:18:43 GMT):
Has joined the channel.

LeonardoCarvalho (Tue, 04 Sep 2018 11:18:04 GMT):
Hello all. I'm very advanced in the Java SDK, but I need to ask about something...

LeonardoCarvalho (Tue, 04 Sep 2018 11:18:25 GMT):
I'm using an DEALER - ROUTER - ROUTER 0mq topology

LeonardoCarvalho (Tue, 04 Sep 2018 11:18:41 GMT):
and I need to know in advance, or at connection time

LeonardoCarvalho (Tue, 04 Sep 2018 11:18:50 GMT):
the Socket ID of the 0mq socket on the remote validator

LeonardoCarvalho (Tue, 04 Sep 2018 11:19:05 GMT):
Looks like this is a known pattern: https://github.com/zeromq/pyzmq/issues/974

LeonardoCarvalho (Tue, 04 Sep 2018 11:19:40 GMT):
the question is, should I try to update on the python code, or just see on the rust tree about implementing this?

amundson (Tue, 04 Sep 2018 18:41:22 GMT):
@LeonardoCarvalho you should start submitting your changes in reviewable chunks to https://github.com/hyperledger/sawtooth-sdk-javascript

amundson (Tue, 04 Sep 2018 18:42:24 GMT):
we will try and stat on top of reviews, I know you have a lot

amundson (Tue, 04 Sep 2018 18:44:34 GMT):
as far as 0mq, go is currently the most performant for its parallelism; we will be looking at parallelism in the rust sdk soonish

amundson (Tue, 04 Sep 2018 18:46:07 GMT):
of course, i meant that to be the java repo. lol.

amundson (Tue, 04 Sep 2018 18:47:56 GMT):
https://github.com/hyperledger/sawtooth-sdk-java this one :)

LeonardoCarvalho (Tue, 04 Sep 2018 22:03:04 GMT):
I think I will commit a heart sinking mega commit later this week

LeonardoCarvalho (Tue, 04 Sep 2018 22:03:18 GMT):
:)

LeonardoCarvalho (Tue, 04 Sep 2018 22:04:46 GMT):
As s bonus, I did a little update on the python code to do the probe handshake, so far is working fine.

LeonardoCarvalho (Wed, 05 Sep 2018 11:49:34 GMT):
I've pushed the current status to https://github.com/CarvalhoLeonardo/sawtooth-sdk-java/tree/development

LeonardoCarvalho (Wed, 05 Sep 2018 11:49:46 GMT):
I intend to put the samples on it tomorrow

Dan (Wed, 05 Sep 2018 15:37:26 GMT):
@amolk I think you work with some people interested in java that might want to see / collaborate ^

amundson (Wed, 05 Sep 2018 17:53:48 GMT):
@LeonardoCarvalho very cool. it would be a very long process to iterate on that large of a PR though, so I think we should pick pieces we can get in to close the gap. maybe build stuff to start? thoughts?

amundson (Wed, 05 Sep 2018 20:14:57 GMT):
maybe signing code would be a good start

LeonardoCarvalho (Wed, 05 Sep 2018 21:29:32 GMT):
Yeah, I really don't know where to start, that's a lot of code... :)

LeonardoCarvalho (Wed, 05 Sep 2018 21:37:31 GMT):
September 7th is a holiday here in Brazil, I intend to search and map the CRs about java on Jira, create some, and send here my thoughts on how to organize the push

LeonardoCarvalho (Fri, 07 Sep 2018 13:22:04 GMT):
@amundson , I am thinking in create submissions this way: 1 - topological : create sub modules (I thnk I've seen a ticket about that already) 2 - architectural update : use a new java version, Reactive mode, etc 3 - Starting in the Commons project, put the core functionalities and basic tests

LeonardoCarvalho (Fri, 07 Sep 2018 13:22:17 GMT):
I think that this 3 steps can be done today and tomorrow

LeonardoCarvalho (Fri, 07 Sep 2018 13:22:50 GMT):
I think I'll struggle a little until I got the project ways, so, I ask for a little patience :)

amundson (Fri, 07 Sep 2018 13:37:42 GMT):
@LeonardoCarvalho (1) and (2) may generate a fair amount of discussion (based on the nature of them), so the PRs may take longer. I'd suggest separating things that might generate discussion/opinions (organization, naming of things (packages, etc.)) be separate PRs from those that are more straight forward to make that easier.

LeonardoCarvalho (Fri, 07 Sep 2018 13:41:00 GMT):
that looks fair, but... Well, the original tree was monolithic, I think that would be easier to propose a revamp, on one PR, and work over it

LeonardoCarvalho (Fri, 07 Sep 2018 13:41:40 GMT):
The revamp PR would concentrate the most of the discussion

LeonardoCarvalho (Fri, 07 Sep 2018 13:41:45 GMT):
after it goes approved

LeonardoCarvalho (Fri, 07 Sep 2018 13:41:55 GMT):
I can submit the others

LeonardoCarvalho (Fri, 07 Sep 2018 13:41:59 GMT):
What do you think ?

amundson (Fri, 07 Sep 2018 13:42:19 GMT):
we will probably want to branch since we are planning to break backward compatibility with that reorg (and probably many other changes).

amundson (Fri, 07 Sep 2018 13:42:42 GMT):
yes, that is reasonable - what I'm suggesting is don't put functional changes in the same PR as the reorg

LeonardoCarvalho (Fri, 07 Sep 2018 13:42:50 GMT):
sure!

amundson (Fri, 07 Sep 2018 13:44:24 GMT):
can you post a high-level summary of the reorg here for discussion as well? I remember we talked about commons (it's an ill-defined package name, but also common in Java projects, etc.)

LeonardoCarvalho (Fri, 07 Sep 2018 13:44:41 GMT):
Sure!

LeonardoCarvalho (Fri, 07 Sep 2018 13:44:47 GMT):
Would be something like this:

LeonardoCarvalho (Fri, 07 Sep 2018 13:47:18 GMT):
To better acommodate a modularized development, I suggest splitting the Java SDK in maven modules, so tests and updates can be done in parallel. I initially though about 4 modules: - Core or Commons - would host signing, crypto, utils and protobuf related artifacts

LeonardoCarvalho (Fri, 07 Sep 2018 13:47:46 GMT):
- REST Client - to hold REST and HTTP routines and code

LeonardoCarvalho (Fri, 07 Sep 2018 13:48:28 GMT):
Transaction Processor - would hold ZeroMQ and communications with the valiadtors and other servers

LeonardoCarvalho (Fri, 07 Sep 2018 13:48:48 GMT):
sorry , 3 modules

LeonardoCarvalho (Fri, 07 Sep 2018 13:48:55 GMT):
for now

LeonardoCarvalho (Fri, 07 Sep 2018 13:49:11 GMT):
the 4th would be a REST security gateway based in microservices

amundson (Fri, 07 Sep 2018 13:59:04 GMT):
to attempt to recap some of our earlier discussion on REST Client - our current position for the SDKs is to not include a REST client implementation for two reasons 1) don't want to pick favorites with respect to framework; 2) the more sophisticated applications don't use the REST API we ship, they talk directly via 0MQ with their own REST API implementations (supply chain, for example). We discussed changing this and including clients, with the caveat that we can 1) support multiple frameworks (mostly organizational, leaving room for more implementations); and 2) support a 0MQ backend via the same client API

amundson (Fri, 07 Sep 2018 13:59:22 GMT):
@LeonardoCarvalho ^ is that a fair summary

LeonardoCarvalho (Fri, 07 Sep 2018 13:59:34 GMT):
yes

LeonardoCarvalho (Fri, 07 Sep 2018 13:59:41 GMT):
but, well, I did it before that :)

LeonardoCarvalho (Fri, 07 Sep 2018 13:59:53 GMT):
the code can be useful, though

LeonardoCarvalho (Fri, 07 Sep 2018 14:00:09 GMT):
I liked your idea of holding "flavoured" packages

LeonardoCarvalho (Fri, 07 Sep 2018 14:00:40 GMT):
the one I did owuld be sdk-sawtooth-rest-jersey

amundson (Fri, 07 Sep 2018 14:01:36 GMT):
yes, something like that. should sawtooth- come first in package names?

LeonardoCarvalho (Fri, 07 Sep 2018 14:01:52 GMT):
If you prefer, I can change that

amundson (Fri, 07 Sep 2018 14:02:29 GMT):
we probably want to follow conventions, so I'd have to research a bit before having a preference

LeonardoCarvalho (Fri, 07 Sep 2018 14:02:51 GMT):
ok

amundson (Fri, 07 Sep 2018 14:03:36 GMT):
for the initial reorg PR though, we don't have that code so I'd not add that in (we will just know it will be added in a subsequent PR that adds the implementation)

LeonardoCarvalho (Fri, 07 Sep 2018 14:04:03 GMT):
I was thinking about just that

LeonardoCarvalho (Fri, 07 Sep 2018 14:04:46 GMT):
but the maven artifact group would be sawtooth.sdk or sdk.sawtooth?

LeonardoCarvalho (Fri, 07 Sep 2018 14:05:45 GMT):
at this time, it is this way

LeonardoCarvalho (Fri, 07 Sep 2018 14:05:48 GMT):

Clipboard - September 7, 2018 11:05 AM

amundson (Fri, 07 Sep 2018 14:08:15 GMT):
core/commons - I don't think we should have a utils package. signing could its own module. I forget what would be in 'crypto'

LeonardoCarvalho (Fri, 07 Sep 2018 14:08:57 GMT):
configuration of crypto providers, I/O on the files and sockets, etc

amundson (Fri, 07 Sep 2018 14:09:30 GMT):
is that part of signing or does it impact transaction processor stuff too?

LeonardoCarvalho (Fri, 07 Sep 2018 14:09:51 GMT):
part of signing, and is heavily used on the processor

LeonardoCarvalho (Fri, 07 Sep 2018 14:10:17 GMT):
so, commons would hold both crypto and signing, in my POV, because they are very closely related

LeonardoCarvalho (Fri, 07 Sep 2018 14:11:18 GMT):
side by side with protobuf handling. I think that all binary handling would be bttter together

LeonardoCarvalho (Fri, 07 Sep 2018 14:13:21 GMT):
so, indeed, "COMMONS". :)

amundson (Fri, 07 Sep 2018 14:15:22 GMT):
ok, I should take another look at your branch with this topic fresh in mind

LeonardoCarvalho (Fri, 07 Sep 2018 14:16:16 GMT):
sure, please give me all input you see as needed

amundson (Fri, 07 Sep 2018 14:19:52 GMT):
I need to take a break now for a bit though. I wonder if some of the other things in (2) can be done in parallel to this discussion - like java version, checkstyle, etc. we were using sun-style code (because of our old-school nature) and you were using google checkstyle.

LeonardoCarvalho (Fri, 07 Sep 2018 14:20:18 GMT):
surly, I can change that

LeonardoCarvalho (Fri, 07 Sep 2018 14:20:30 GMT):
is there a checkstyle configuration I should take ?

LeonardoCarvalho (Fri, 07 Sep 2018 14:20:44 GMT):
and can we please change it to lines with 120 characters?!?!!? :D

amundson (Fri, 07 Sep 2018 14:21:23 GMT):
https://github.com/checkstyle/checkstyle/tree/master/src/main/resources

amundson (Fri, 07 Sep 2018 14:21:36 GMT):
I think sun_checks.xml

amundson (Fri, 07 Sep 2018 14:23:51 GMT):
I'm personally fine with modifications to it, disabling silly things, whatever. You could also win an argument to use google style if you felt strongly about it.

amundson (Fri, 07 Sep 2018 14:24:20 GMT):
the most important thing there is that we use checkstyle to resolve those style debates and not do it in PRs subjectively

LeonardoCarvalho (Fri, 07 Sep 2018 14:25:46 GMT):
I'm used to that, better a tool that has no passions than people

LeonardoCarvalho (Fri, 07 Sep 2018 14:25:46 GMT):
:D

amundson (Fri, 07 Sep 2018 14:26:07 GMT):
others may have opinions, but I honestly don't know of anyone that is super opinionated on it so they would have to speak up :)

LeonardoCarvalho (Fri, 07 Sep 2018 14:28:30 GMT):
hahahaah

LeonardoCarvalho (Fri, 07 Sep 2018 14:28:36 GMT):
I know some people

LeonardoCarvalho (Fri, 07 Sep 2018 14:28:43 GMT):
usually very young...

LeonardoCarvalho (Fri, 07 Sep 2018 14:28:44 GMT):
:D

amundson (Fri, 07 Sep 2018 14:53:36 GMT):
to be clear, I meant that works on sawtooth and just on this specific topic :)

amundson (Fri, 07 Sep 2018 15:27:58 GMT):
@LeonardoCarvalho what do you use for a development environment? I may try and duplicate it here.

LeonardoCarvalho (Fri, 07 Sep 2018 17:45:24 GMT):
maven and eclipse

LeonardoCarvalho (Fri, 07 Sep 2018 18:10:26 GMT):
and Java 10

LeonardoCarvalho (Fri, 07 Sep 2018 21:20:44 GMT):
That's very, VERY embarassing, but... Where is the context_id set on the client side? I think I broke some IDs yesterday...

LeonardoCarvalho (Fri, 07 Sep 2018 21:20:46 GMT):
:-/

LeonardoCarvalho (Fri, 07 Sep 2018 21:45:19 GMT):
uh, forget that

LeonardoCarvalho (Sat, 08 Sep 2018 12:44:33 GMT):
Ok, created the https://jira.hyperledger.org/browse/STL-1427

LeonardoCarvalho (Tue, 11 Sep 2018 11:27:06 GMT):
Well, looks like using Gitlab and Microsoft Git serves broke my capacity of creating PRs... Can someone help me over?

amundson (Tue, 11 Sep 2018 15:48:41 GMT):
@LeonardoCarvalho not sure how gitlab or ms git stuff... you should be able to push up a PR branch (with whatever feature you are creating the PR for) to your fork (https://github.com/CarvalhoLeonardo/sawtooth-sdk-java/) and a button will then appear in the github UI to create the PR against the hyperledger repo

arsulegai (Tue, 11 Sep 2018 19:01:08 GMT):
Has joined the channel.

LeonardoCarvalho (Tue, 11 Sep 2018 21:20:10 GMT):
Ah, got my mistake

LeonardoCarvalho (Tue, 11 Sep 2018 21:20:15 GMT):
"Do not use the Update Branch button provided by GitHub on the pull request page."

LeonardoCarvalho (Tue, 11 Sep 2018 21:20:29 GMT):
not "Do not use the button provided by GitHub on the pull request page."

LeonardoCarvalho (Tue, 11 Sep 2018 21:27:56 GMT):
Done. Please be gentle. :)

amundson (Wed, 12 Sep 2018 14:28:06 GMT):
@LeonardoCarvalho my first impression is that we need a more granular/focused PR to start with, so it is iterative and focused. I have my dev env. almost re-setup, so I may be able to help divide it up (the next few days are rough though, schedule-wise).

LeonardoCarvalho (Wed, 12 Sep 2018 21:30:04 GMT):
That was my thought as well, I was most free until last month, now I'm on a consulting service that takes most of my time...

LeonardoCarvalho (Thu, 13 Sep 2018 11:11:56 GMT):
Question : is there a way of a registering Transaction Handler inform which types of messages it handles to the Validator?

jsmitchell (Thu, 13 Sep 2018 12:13:35 GMT):
You can provide a list of transaction family names and versions. If you claim to handle a transaction family/version, you have to handle all valid message types for that transaction family.

colincmcc (Thu, 13 Sep 2018 15:48:51 GMT):
Has joined the channel.

colincmcc (Thu, 13 Sep 2018 17:03:37 GMT):
I'm trying to recreate the market transaction processor in JavaScript using the javascript sdk. I'm using sawtooth v1.05 running as several services on Ubuntu, have written a copy of the addresser in JS. I'm only running the settings-tp and my version of the market-tp for processors. It occasionally works, when submitting new accounts over the market-rest-api, but more often than not I get an error with the validator that says "Tried to set address on a read-only context." Where the generated address has the correct namespace prefix and generated body. Where should I be looking for issues? Does it have to do with promise resolution of the getState and setState of the js context api? repo is here: https://github.com/colincmcc/sawtooth-marketplace/tree/master/processor/hamletProcessorJs/src

amundson (Thu, 13 Sep 2018 17:05:39 GMT):
@colincmcc that is a good question for #sawtooth . this channel is for discussion of developing the sdks themselves

colincmcc (Thu, 13 Sep 2018 17:06:04 GMT):
Gotcha, sorry. I posted there as well.

amundson (Thu, 13 Sep 2018 17:06:22 GMT):
no problem, good luck!

LeonardoCarvalho (Fri, 14 Sep 2018 09:57:23 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=9yUcachAsIrcx4UhMJ) @jsmitchell So I need to define the family scope first, and after link my particular handler, right ? I didn't find this particular configuration in the docs, where could I find it ?

LeonardoCarvalho (Fri, 14 Sep 2018 09:59:01 GMT):
I'm thinking about creating a test family, to do some integration/round trip tests, what do you think ?

adamludvik (Tue, 18 Sep 2018 02:23:00 GMT):
Has joined the channel.

LeonardoCarvalho (Tue, 18 Sep 2018 10:58:19 GMT):
Hi all.

LeonardoCarvalho (Tue, 18 Sep 2018 10:58:53 GMT):
is there any plans in code to implement something based on PKI enrollment on Sawtooth?

amundson (Tue, 18 Sep 2018 14:41:25 GMT):
@LeonardoCarvalho can you describe a bit more of what it would do?

LeonardoCarvalho (Tue, 18 Sep 2018 16:04:16 GMT):
Brazil's government is using PKI to handle some of the taxes and government document processes

LeonardoCarvalho (Tue, 18 Sep 2018 16:04:43 GMT):
So, many companies and people got a government issued token

LeonardoCarvalho (Tue, 18 Sep 2018 16:05:14 GMT):
My accountant and another friend asked me about how to use and vinculate the token with the certificates used on Sawtooth

LeonardoCarvalho (Tue, 18 Sep 2018 16:06:27 GMT):
The defacto solution that are being deployed here is based in the CISCO based procedure of certificate enrollment

LeonardoCarvalho (Tue, 18 Sep 2018 16:07:16 GMT):
where a public key (from the token, in the case), would be enrolled on the domain, generating a key pair value.

LeonardoCarvalho (Tue, 18 Sep 2018 16:07:37 GMT):
the private key of the enrollemnt is delivered to the user

LeonardoCarvalho (Tue, 18 Sep 2018 16:08:10 GMT):
and the public key would be stored as (in my view, until now) an identity on sawtooth

LeonardoCarvalho (Tue, 18 Sep 2018 16:10:47 GMT):
I did some tests, and managed to store a private SEC key on my token, side by side with my government-issued certificate

amundson (Tue, 18 Sep 2018 16:25:17 GMT):
solving it at the application layer (smart contracts, etc.) is the right layer. Sawtooth itself isn't opinionated about it. I think the stuff REMME is doing is PKI-based and they are presenting at the next tech forum, so that might be interesting. from an identity standpoint, Indy is also interesting, and I'd like to do a smart contract that brings Indy's approach to Sawtooth. next directory is identity-focused by not PKI, AFAIK. we have some identity stuff going into Sabre but it is not PKI.

LeonardoCarvalho (Tue, 18 Sep 2018 22:21:00 GMT):
sorry about the question.. What's REMME ?

LeonardoCarvalho (Tue, 18 Sep 2018 22:21:30 GMT):
Indy is very interesting, but I prefer use only one platform initially!

LeonardoCarvalho (Wed, 19 Sep 2018 10:38:10 GMT):
ooohhh, this REMME ? https://github.com/Remmeauth

LeonardoCarvalho (Wed, 19 Sep 2018 10:42:52 GMT):
no java implementation, though... :unamused:

manju.ac (Thu, 20 Sep 2018 08:45:44 GMT):
Has joined the channel.

raghav.aneja14 (Thu, 20 Sep 2018 08:46:06 GMT):
Has joined the channel.

fosdick (Thu, 20 Sep 2018 19:11:48 GMT):
Has joined the channel.

boydjohnson (Thu, 20 Sep 2018 19:16:12 GMT):
Has joined the channel.

fosdick (Thu, 20 Sep 2018 19:17:11 GMT):
Hello everyone! I'm curious to know what the roadmap for Sawtooth support in Java looks like. We recently discovered that since the jars are not in Maven, we have to build from scratch or take from source and host it. Can anyone shine some light on when more Java support is coming and what it'll look like?

amundson (Thu, 20 Sep 2018 20:14:32 GMT):
@fosdick we are working on merging @LeonardoCarvalho 's fork of the SDK into the official SDK currently (many good/new features) and hopefully after that we will be working toward a stable 1.0 of that SDK. no ETA on these things though.

fosdick (Thu, 20 Sep 2018 20:27:57 GMT):
Thanks for the info, @amundson!

fosdick (Thu, 20 Sep 2018 20:28:47 GMT):
Can you link me to some info regarding the new features in the fork?

amundson (Thu, 20 Sep 2018 21:12:04 GMT):
@fosdick https://github.com/CarvalhoLeonardo/sawtooth-sdk-java/tree/development

LeonardoCarvalho (Thu, 20 Sep 2018 21:36:43 GMT):
@fosdick feel free to help or give any feedback

LeonardoCarvalho (Thu, 20 Sep 2018 21:37:21 GMT):
My times are a little tight now, because I just started a consulting job

askmish (Fri, 21 Sep 2018 04:31:39 GMT):
Has joined the channel.

LeonardoCarvalho (Fri, 21 Sep 2018 10:24:39 GMT):
oh, and please be aware that the java sdk currently needs this change on the 104 and 105 python core: https://github.com/CarvalhoLeonardo/sawtooth-core/commit/1ce3dea3aaf6075dc738ebf0022b6fde970b3fa2

Lotus (Fri, 21 Sep 2018 12:44:18 GMT):
Has joined the channel.

adamludvik (Fri, 21 Sep 2018 16:27:18 GMT):
@amundson @Dan I would like to propose adding support to the Rust signing library for exporting keys to PEM format in addition to the existing hex format. @knkski has already implemented code to do this in a PR against the seth repo, using the Rust openssl bindings. We already support reading a PEM-encoded key in the SDK, so it makes sense to be able to write one as well. (https://github.com/hyperledger/sawtooth-seth/pull/72/files#diff-4a70525a91c489259875db399c3e15acR28)

knkski (Fri, 21 Sep 2018 16:27:19 GMT):
Has joined the channel.

Dan (Fri, 21 Sep 2018 16:30:55 GMT):
I'm on board with that in master (just clarifying for everyone that this isn't a 1.1 request).

adamludvik (Fri, 21 Sep 2018 16:32:11 GMT):
Yes, this is not a 1.1 feature

amundson (Mon, 24 Sep 2018 14:28:08 GMT):
@adamludvik @knkski sounds fine

thou_shalt (Thu, 27 Sep 2018 09:56:00 GMT):
Has joined the channel.

knkski (Thu, 27 Sep 2018 23:11:57 GMT):
Would a transaction builder helper be useful in the rust sdk? Something like this: https://github.com/hyperledger/sawtooth-core/compare/master...knkski:transaction-builder

amundson (Fri, 28 Sep 2018 02:03:49 GMT):
@knkski we debated it briefly and decided leading up to 1.0 to avoid it. not everyone was convinced that we had the right api and so we punted on it. I think a compelling part for me (maybe because I am a skeptic) would be to see@an example of how it would clean up something like xo or supply chain code. I think if we adopted it we should to it cross language (which we should probably do an rfc for, since the other apis are stable).

zac (Fri, 28 Sep 2018 17:21:17 GMT):
The needs are varied enough that a robust cross-language API that was significantly simpler than just using the protobufs directly really eluded us. It has to support one transaction to one batch to one batchlist, or many transactions/batches, sometimes different inputs/outputs per transaction, sometimes the same prefix based inputs/outputs, etc etc. I would love to see this implemented at some point though if someone came up with the right API. I think there is a lot of demand from the development community to make interacting with Sawtooth faster/simpler. Perhaps the right answer is something opinionated that is a level more abstracted than the SDKs.

zac (Fri, 28 Sep 2018 17:21:20 GMT):
¯\_(ツ)_/¯

rranjan3 (Sat, 29 Sep 2018 01:17:01 GMT):
Has joined the channel.

manojgop (Sat, 29 Sep 2018 08:30:39 GMT):
Has joined the channel.

FrankCastellucci (Sat, 29 Sep 2018 11:22:42 GMT):
Perhaps thinking about it in 'functional composition' versus 'imperative api' may expose the answers you seek... weedhopper :)

zac (Mon, 01 Oct 2018 14:01:29 GMT):
You had me at "functional"

zac (Mon, 01 Oct 2018 14:02:09 GMT):
Though I wonder how multi-language support would be for something like that . . .

zac (Mon, 01 Oct 2018 14:02:13 GMT):
Should probably be okay

adave (Mon, 01 Oct 2018 17:44:47 GMT):
Has joined the channel.

knkski (Mon, 01 Oct 2018 20:14:42 GMT):
@LeonardoCarvalho: @boydjohnson and I would to help get https://github.com/hyperledger/sawtooth-sdk-java/pull/3 merged - wondering if you're ok with us pushing up to that branch at all, or if there's some other way you'd be interested in us helping out

knkski (Mon, 01 Oct 2018 20:59:41 GMT):
@amundson: RE the SDK API, one example where it cleans up code is from the Seth RPC: https://github.com/hyperledger/sawtooth-seth/blob/master/rpc/src/client.rs#L274

knkski (Mon, 01 Oct 2018 21:00:18 GMT):
^^ could get simplified to something like this: ``` let batch_list = TransactionBuilder::new() .family_name("seth") .family_version("1.0") .addresses(vec![SETH_NS, BLOCK_INFO_NS]) .payload(payload) .signer(&account) .build_batch_list() .unwrap(); ```

knkski (Mon, 01 Oct 2018 21:02:02 GMT):
Regularization is another reason why, a lot of projects have somewhat similar code for building transactions, some of which were copy/pasted from other projects with bug fixes applied to the pasted code, and not the copied code

knkski (Mon, 01 Oct 2018 21:03:27 GMT):
@FrankCastellucci: I used the builder pattern in the above prototype since Rust doesn't have keyword arguments, making a more functional approach annoying to work with. I expect that we'd make a macro though that would present a functional api

FrankCastellucci (Mon, 01 Oct 2018 21:04:29 GMT):
@zac - Here is an example (similar to Clojure `comp`) in Python using `functools`: ``` def compose_builder(*functions): """Construct composition""" return functools.reduce( lambda f, g: lambda x: f(g(x)), functions, lambda x: x) ``` I use it to build various TP family Transactions, i.e: ``` def create_utxq(request): """Create utxq transaction""" operation = __validate_operation(request) LOGGER.debug( "Processing UTXQ create with operation => {}".format(operation)) quant = __validate_utxq(request) utxq_build = compose_builder( submit_single_txn, create_transaction, __create_initiate_inputs_outputs, __create_initiate_payload, __create_utxq) utxq_build((operation, quant, request)) ```

knkski (Mon, 01 Oct 2018 21:06:30 GMT):
I've got a Python API prototype example here: https://gist.github.com/knkski/bb95892e9997831d887742535f16bc7d, and I imagine that we'd use Rust macros to present a fairly similar API

FrankCastellucci (Mon, 01 Oct 2018 21:06:35 GMT):
@knkski Yeah, that is the way with Java, Rust, etc... each one of those functions must return the builder which looks good in usage but :( in the implementation

knkski (Mon, 01 Oct 2018 21:09:16 GMT):
It seems like we could support two different API styles, one along the lines of the Python demo in languages that support it, and a builder pattern in languages that don't really

FrankCastellucci (Mon, 01 Oct 2018 21:11:25 GMT):
I have to get my head into Rust soon.... and start moving code

tungdt_socoboy (Tue, 02 Oct 2018 04:47:40 GMT):
Hi guys, i'm tried to import Sawtooth Javascript SDK into React-Native but having issue: `module 'crypto' does not exist in the haste module map` Are there anyone already solved this message?

amundson (Tue, 02 Oct 2018 04:55:47 GMT):
@knkski I am not a fan of that dict API approach.

amundson (Tue, 02 Oct 2018 05:03:19 GMT):
@knkski for the rust example, I think another option besides the builder pattern is simply to remove the direct use of protobuf from the api and define transaction/batch structs with From impls. the benefit of your example is the simplicity of passing things into the functions, not the builder pattern. we might have done this elsewhere for blocks; I know we discussed it. (and maybe it is just a more invisible builder pattern really)

LeonardoCarvalho (Tue, 02 Oct 2018 10:51:06 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=aAjFf2ezDBk2PgASn) @knkski I got badly entangled in git binaries differences on the commands, please refer to my branch while I fix that... :unamused:

LeonardoCarvalho (Tue, 02 Oct 2018 11:24:22 GMT):
I just noticed... Is there a manual to configure the Jenkins build to reflect my changes?

knkski (Tue, 02 Oct 2018 14:01:53 GMT):
@amundson: Are you thinking that just transmuting the dicts into a `Transaction` class would be good, or are you thinking something else?

knkski (Tue, 02 Oct 2018 14:02:12 GMT):
Could do something like this: ``` batch_list = create_batch_list([ Transaction( family_name='foo', family_version='1.0', inputs=['00000', '00001'], outputs=['00001', '00002'], payload=bytes([1, 2, 3]), signer=signer, ) ]) ```

amundson (Tue, 02 Oct 2018 14:38:00 GMT):
@knkski yeah, that's the part I was referring to. if we were to move in the direction where the class isn't just a data class (not sure that's good or not), as implied by 'signer=signer', then you may as well just have Transaction(...).to_batch_list().

amundson (Tue, 02 Oct 2018 14:39:03 GMT):
though, that isn't good in that it can't handle multiple txns per batch

knkski (Tue, 02 Oct 2018 14:39:56 GMT):
we could have both a `create_batch_list` function, as well as a `.to_batch_list()` convenience method on the transaction class

amundson (Tue, 02 Oct 2018 14:41:21 GMT):
yeah, I'm going to withdraw my .to_batch_list() suggestion. it's bad. incentivizes not thinking about batches correctly.

zac (Tue, 02 Oct 2018 14:43:49 GMT):
The pattern I have repeatedly come back to in internal helper functions I have written is four functions: ``` createTransaction(privateKey, payload) createBatch(privateKey, transactions) encodeBatches(privateKey, batches) encodeAll(privateKey, payloads) //combination of the previous three ```

zac (Tue, 02 Oct 2018 14:44:13 GMT):
This is missing some key edge case functionality, but has worked well for quick PoCs

zac (Tue, 02 Oct 2018 14:45:15 GMT):
Also, this is with app-specific logic hard-coded in

zac (Tue, 02 Oct 2018 14:45:20 GMT):
like family name and what not

FrankCastellucci (Tue, 02 Oct 2018 14:45:42 GMT):
@zac However, it was inspirational in my composition building

FrankCastellucci (Tue, 02 Oct 2018 14:45:42 GMT):
@zac However, they were inspirational in my composition building

amundson (Tue, 02 Oct 2018 14:46:02 GMT):
I think though if we moved away from protobuf Transaction/Batch objects, you could just have something like: ```Batch( transactions=[ Transaction( family_name='foo', family_version='1.0', inputs=['00000', '00001'], outputs=['00001', '00002'], payload=bytes([1, 2, 3]), signer=signer, ), ], signer=signer ) ```

amundson (Tue, 02 Oct 2018 14:46:20 GMT):
because the only thing your helper function does is help with signing

amundson (Tue, 02 Oct 2018 14:46:27 GMT):
(i.e. header creation)

amundson (Tue, 02 Oct 2018 14:47:36 GMT):
@zac what does encodeBatches do?

zac (Tue, 02 Oct 2018 14:47:38 GMT):
Yes, and I have done essentially curried versions of `createTransaction` when I wasn't hard-coding: ``` getTransactionCreator(familyName, familyVersion)(inputs, outputs)(payload) ```

zac (Tue, 02 Oct 2018 14:47:51 GMT):
encodeBatches makes a BatchList

zac (Tue, 02 Oct 2018 14:47:51 GMT):
encodeBatches makes a serialized BatchList

zac (Tue, 02 Oct 2018 14:48:44 GMT):
the two `create` functions make protobuf instances

amundson (Tue, 02 Oct 2018 14:49:17 GMT):
if we move away from the limitations of using protobuf as part of the api, I don't think BatchList is interesting at all

amundson (Tue, 02 Oct 2018 14:49:23 GMT):
```[Batch( transactions=[ Transaction( family_name='foo', family_version='1.0', inputs=['00000', '00001'], outputs=['00001', '00002'], payload=bytes([1, 2, 3]), signer=signer, ), ], signer=signer )] ```

zac (Tue, 02 Oct 2018 14:49:38 GMT):
I am not caught up on this discussion

knkski (Tue, 02 Oct 2018 14:50:06 GMT):
@amundson: What creates the batch list protobuf object from that list of Batch objects then?

zac (Tue, 02 Oct 2018 14:50:13 GMT):
but, the goal of the `encode` functions is just to produce serialized data you can send in an HTTP request

zac (Tue, 02 Oct 2018 14:50:19 GMT):
Whatever that looks like

amundson (Tue, 02 Oct 2018 14:50:56 GMT):
@knkski libary code that needs that conversion done

amundson (Tue, 02 Oct 2018 14:51:05 GMT):
i.e. nothing the user of the API can see

knkski (Tue, 02 Oct 2018 14:53:27 GMT):
wondering what library code you mean - at least in the instances that i've seen, we serialize the batch list and then hand it off to an http library, which wouldn't know how to convert the list of batches to bytes itself

amundson (Tue, 02 Oct 2018 14:56:53 GMT):
@knkski yeah, that's a fair point. you would need a function or object to do the serialization.

amundson (Tue, 02 Oct 2018 14:57:41 GMT):
still, it's probably friendlier if you input a natural list [] into a serializer than if you have to work with the more constrained BatchList

amundson (Tue, 02 Oct 2018 14:58:25 GMT):
my overall point here is that if the design is calling for a bunch of helper functions, maybe there is a cleaner approach to solve the problem.

knkski (Tue, 02 Oct 2018 15:01:58 GMT):
how many is too many in your opinion? in the example i've got above, there's `Transaction` (changed from `_create_transaction`), `create_batch`, and `create_batch_list`, which seems like an appropriate number to me (and `create_batch` can be elided in most cases)

amundson (Tue, 02 Oct 2018 15:03:28 GMT):
back to the builder pattern for a second - at it's core, the only real benefit of that pattern is that you can enforce consistency in .build() and return only valid objects or an error. a secondary benefit, which @zac had in the javascript sdk up until 1.0 was to actually have the builder object take some of the fields in it's constructor which served as defaults. so that if you were building many of the same object, there was less repetition because you could exclude family_name and family_version (for example).

amundson (Tue, 02 Oct 2018 15:05:59 GMT):
@knkski well, why have any? (the answer might be it's hard to keep backward compatibility at some point)

amundson (Tue, 02 Oct 2018 15:06:48 GMT):
I would point out that providing alternate constructor functions could just be done in object constructors as I have in the example above.

amundson (Tue, 02 Oct 2018 15:07:47 GMT):
I guess another reason could be "we want to keep the objects dumb data objects, and not have complex constructors and other methods"

zac (Tue, 02 Oct 2018 15:17:11 GMT):
The functions I've written use natural lists. BatchList is just for encoding. The two `create` functions do return Transaction and Batch instances though.

boydjohnson (Tue, 02 Oct 2018 15:49:12 GMT):
@LeonardoCarvalho I broke up the commits in your Java Sdk PR into more granular commits. That level of granularity is probably required for such a large PR. https://github.com/boydjohnson/sawtooth-sdk-java/commits/PR_3

knkski (Tue, 02 Oct 2018 15:50:57 GMT):
@amundson: when you say you don't think we need helper functions, are you making a distinction between helper functions and helper classes and saying you'd prefer classes to functions? I don't have strong opinions strongly either way, but I went with `create_batch_list` vs `BatchList` pretty much for your last reason - using classes just seemed like more machinery than necessary

zac (Tue, 02 Oct 2018 15:52:53 GMT):
^ that is pretty much my opinion on everything

zac (Tue, 02 Oct 2018 15:53:45 GMT):
But OOP is also still very common, and some of the supported languages don't do functional all that well ¯\_(ツ)_/¯

zac (Tue, 02 Oct 2018 15:54:06 GMT):
I could see going either way

amundson (Tue, 02 Oct 2018 15:58:24 GMT):
@knkski not attempting to make that general of an argument. just challenging what about the current api is driving the need for helper functions.

zac (Tue, 02 Oct 2018 15:58:38 GMT):
also, you need to support encoding TransactionLists (another helper?), and none of these signing implementations feel super robust

zac (Tue, 02 Oct 2018 16:00:11 GMT):
maybe there is a way to build a custom signer function (with private key and algo baked in), and you pass that signer rather than the private key

knkski (Tue, 02 Oct 2018 16:00:40 GMT):
@amundson: I think the fact that everyone is creating variations on `create_batch_list` that are different from each other is a good reason (some of the implementations are copy/pasted around, and bugs are fixed in one but not the other)

zac (Tue, 02 Oct 2018 16:03:26 GMT):
Ultimately when I am building a client, 90% of the time I am going to build myself that `encodeAll` function which goes from payload -> bytes, and has all other app logic baked in. I will build that method on top of whatever API the SDK has if it doesn't already have that method.

zac (Tue, 02 Oct 2018 16:04:09 GMT):
(9% of the time I will do (inputs, outputs, payload) -> bytes because I am being good and not relying on prefixes)

amundson (Tue, 02 Oct 2018 16:04:57 GMT):
@knkski i agree thats the problem to solve

zac (Tue, 02 Oct 2018 16:05:02 GMT):
And that function is literally all I will call anywhere else in my client.

zac (Tue, 02 Oct 2018 16:05:02 GMT):
And that one function is literally all I will call anywhere else in my client.

LeonardoCarvalho (Tue, 02 Oct 2018 21:34:04 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=EiXhyMpabcefFf7FL) @boydjohnson Oh boy, many thanks.. I need to start this work on my other branch...

amundson (Wed, 03 Oct 2018 14:40:48 GMT):
@boydjohnson @LeonardoCarvalho @knkski I think we need to break it down by functional or feature change. so for example, we need to review the signing API changes in a separate PR so we can discuss them. if we are deviating from how the other SDKs work, we have to understand why, whether it's a Java-ism or if we are proposing it for the other SDKs as well, etc.

LeonardoCarvalho (Wed, 03 Oct 2018 21:32:42 GMT):
@amundson I think that the problem is that, since is a revamping, there's little room, IMHO, to map the fine points. The effort of @boydjohnson was superb, I will try to do like him in the next days

FrankCastellucci (Thu, 04 Oct 2018 09:36:29 GMT):
@amundson @boydjohnson @LeonardoCarvalho @knkski I think it is realistic, motivating and possibly best to state the contract for the validator/state interactions but leave the implementation up to the SDK developer. Choice of implementation, and features that it may have, opens the market so to speak. Just my 0.02 of course.

LeonardoCarvalho (Thu, 04 Oct 2018 10:42:17 GMT):
@FrankCastellucci I'm doing a work of creating interesting façades and patterns. For an example, there's 3 classes that can be used either for a TP or a Validator node, with no changes. ;)

LeonardoCarvalho (Thu, 04 Oct 2018 10:44:47 GMT):
And, like javascript, java tendos to get a LOT of people thinking "I can do better/different", hehehe

LeonardoCarvalho (Thu, 04 Oct 2018 10:44:47 GMT):
And, like javascript, java tends to get a LOT of people thinking "I can do better/different", hehehe

amundson (Thu, 04 Oct 2018 11:22:45 GMT):
@FrankCastellucci I'd replace "SDK developer" with "SDK maintainers", and to get any PRs through the review process you have to get the maintainers to agree to put green checkmarks on the PRs (and not a red x). Absent granular enough PRs, it is exceptionally difficult to get PRs through the process (as it should be).

LeonardoCarvalho (Thu, 04 Oct 2018 11:24:47 GMT):
Makes sense, the Maintainer would point the direction

amundson (Thu, 04 Oct 2018 11:25:02 GMT):
I also think it is a reasonable principal that all the official SDKs basically use the same APIs, with deviations as it makes sense for the language. That helps with writing docs for all the SDKs that are consistent, and provides a wider base of knowledge.

LeonardoCarvalho (Thu, 04 Oct 2018 11:25:12 GMT):
a developer can choose between many implementantions or architectures

amundson (Thu, 04 Oct 2018 11:28:56 GMT):
There is not "the Maintainer" - there are maintainers, plural, and we all work together to review and approve PRs. Any one of the maintainers can block a PR from being merged by putting on a red x on it. In practice, this usually just causes discussion and iteration until there is agreement.

amundson (Thu, 04 Oct 2018 11:30:22 GMT):
We require two maintainer approvals with no red x in order to merge a PR.

amundson (Thu, 04 Oct 2018 11:32:42 GMT):
Because securing approvals requires time from other maintainers, in the form of review and potentially discussion, focused PRs tend to go in orders of magnitude faster because they are more reviewable.

FrankCastellucci (Thu, 04 Oct 2018 11:36:57 GMT):
My point was that there is a base contract for any SDK creation. There are two types of SDK: Official one's from sawtooth that can follow all the green checkboxes, PRs and maintainer standards, and those developed outside of sawtooth governance.

amundson (Thu, 04 Oct 2018 11:49:03 GMT):
@FrankCastellucci that's already the case

FrankCastellucci (Thu, 04 Oct 2018 11:50:23 GMT):
OK, maybe there is an opportunity to document the SDK developer SDK which I'll gladly put some drafts together if I can free up some time.

amundson (Thu, 04 Oct 2018 11:53:30 GMT):
@FrankCastellucci it's a subset of the 0MQ/Protobuf API in protos/.

FrankCastellucci (Thu, 04 Oct 2018 11:54:04 GMT):
yep

amundson (Thu, 04 Oct 2018 11:54:13 GMT):
otherwise documented by all the existing SDK implementations

FrankCastellucci (Thu, 04 Oct 2018 11:54:34 GMT):
yep

FrankCastellucci (Thu, 04 Oct 2018 11:55:31 GMT):
That is how us early birds figured it out, given the general questions though it would seem that something can reduce the chat traffic as sawtooth popularity grows and others want to extend features at the SDK level

FrankCastellucci (Thu, 04 Oct 2018 11:56:42 GMT):
e.g. In our app we use a lot of encryption, the facade we built is potentially reusable (of course it gets more complex) but just looking at opportunities

amundson (Thu, 04 Oct 2018 11:57:08 GMT):
which language?

FrankCastellucci (Thu, 04 Oct 2018 11:57:20 GMT):
We've also considered extending the validator/merkle-tree implementation to support such behavioral extensions

FrankCastellucci (Thu, 04 Oct 2018 11:57:43 GMT):
today it is python

FrankCastellucci (Thu, 04 Oct 2018 11:57:54 GMT):
we are seriously looking at a rust port though

amundson (Thu, 04 Oct 2018 12:00:07 GMT):
could you provide a high-level overview on the facade and examples of what you mean by behavioral extensions?

zac (Thu, 04 Oct 2018 12:02:42 GMT):
It does seem like there is room for some unofficial tooling. Not sure what the core maintainers' roles are in allowing/encouraging/promoting that sort of work, but any mature ecosystem has third-party tools.

amundson (Thu, 04 Oct 2018 12:02:44 GMT):
@LeonardoCarvalho as a next step, mind if @boydjohnson and I collaborate on a set of maybe 2-3 initial PRs pulling in specific features from your SDK into the official SDK?

LeonardoCarvalho (Thu, 04 Oct 2018 12:02:54 GMT):
I would love to help in the java front

LeonardoCarvalho (Thu, 04 Oct 2018 12:03:16 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=HuZwhXEQwoewWYnBc) @amundson Absolutely, please do, I need to get the gist of the project's ways

LeonardoCarvalho (Thu, 04 Oct 2018 12:04:09 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=XDpAdykscHqSmpHLh) @FrankCastellucci I showed some project details, and a (junior) devops got a heart attack seeing a 1 Tb file in the logs.. hehehe

amundson (Thu, 04 Oct 2018 12:06:47 GMT):
@zac I think mostly in keeping the APIs stable enough to have those tools work without breaking all the time.

amundson (Thu, 04 Oct 2018 12:07:18 GMT):
which, I think we are already doing fairly well for the APIs that matter for that

FrankCastellucci (Thu, 04 Oct 2018 12:32:00 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=uchmZtkHKPpqyvtPs) @amundson Running out to client now but when I return I gladly will

Share718 (Thu, 04 Oct 2018 15:51:30 GMT):
Has joined the channel.

arsulegai (Wed, 10 Oct 2018 02:03:52 GMT):
That's interesting discussion and sorry I'm late commenting on this, the PR from @knkski is similar to what I expected would be present. I faced so many issues when writing my first application (especially the client which I wrote in Go), it wasn't as easy as sawtooth document made it look like. Here's my wish list which could help 1. Header ID is sign of serialised header (similar idea for both transaction/batch). A builder concept here would help. Example: transaction = Transaction.builder().signing_key(/*accepts key*/).header(/*accepts transaction header object*/)....build(); Having such utility will avoid developer errors and provide a default means of constructing transaction and batches. 2. Sawtooth (under transactions and batches) document mentions that headers are to be serialized and developers should be careful when performing serialize/de-serialize operation as it should be consistent across languages. As a first time developer, I was worried with these instructions (have a question as well here, why should it be mentioned when we're using Protobuf to perform these operations). I guess document is influenced by Python language. It would help if somewhere it's also mentioned to make use of Protobuf libraries for serialize/de-serialize operation (infact just highlight this part). In case of Go, Protobuf library has to be explicitly called by passing reference of constructed header, it wasn't mentioned anywhere. I wish for these because there wasn't a way to know which step in my transaction composition has gone wrong. Validator just responds that sent batch list cannot be de-serialized. It was painful to debug !! :(

Dan (Thu, 11 Oct 2018 18:50:53 GMT):
@arsulegai that's really great feedback. I think one root issue is that we don't have a client tutorial for go. Looking at https://sawtooth.hyperledger.org/docs/core/nightly/master/app_developers_guide/go_sdk.html we only have transaction processor documentation. The note on the overview section indicates there's client material but I don't see client documentation (there's links to transactions and batches section of the docs but that doesn't really count). Am I missing something?

boydjohnson (Thu, 11 Oct 2018 22:08:39 GMT):
@LeonardoCarvalho https://github.com/hyperledger/sawtooth-sdk-java/pull/4 Take a look at this PR when you have a chance. It uses your modified sun checkstyle and applies it to the current sdk.

arsulegai (Fri, 12 Oct 2018 01:32:16 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=4xkmua9MekWvPeidv) @Dan You're right, an example for client in Go similar to the section on TP will help. I'm interested in doing this, don't know if somebody else is working on it already. Shall I write XO client in Go and fill up the document section in free time?

LeonardoCarvalho (Fri, 12 Oct 2018 11:59:12 GMT):
Sorry guys, rocketchat logged me off during 4 days..

LeonardoCarvalho (Fri, 12 Oct 2018 12:00:28 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=Baft7WpX5wWNYqNLG) @boydjohnson So, what I need to do ?

boydjohnson (Fri, 12 Oct 2018 12:25:09 GMT):
Just give it a review.

Dan (Fri, 12 Oct 2018 12:56:52 GMT):
@achenette any thoughts on client tutorials? Above @arsulegai is offering to make one for go/xo. I think that would be awesome. We see a lot of questions on how to make clients.

achenette (Fri, 12 Oct 2018 12:56:53 GMT):
Has joined the channel.

dplumb (Mon, 15 Oct 2018 16:19:04 GMT):
Has joined the channel.

dplumb (Mon, 15 Oct 2018 16:20:59 GMT):
@Dan @achenette @arsulegai Part of the problem is that the protobuf API for Go is a lot tricker than the other languages. When I was first working on Seth I remember that part being a huge headache.

dplumb (Mon, 15 Oct 2018 16:21:21 GMT):
It would certainly be nice to have a good Go tutorial

Dan (Mon, 15 Oct 2018 16:21:37 GMT):
I don't think we have any client tutorials.

dplumb (Mon, 15 Oct 2018 16:21:50 GMT):
The app-dev guide has a good format, so that could certainly be used as a template

achenette (Mon, 15 Oct 2018 16:22:40 GMT):
@Dan - The App Dev Guide has client tutorials for Python and JavaScript.

dplumb (Mon, 15 Oct 2018 16:22:42 GMT):
The "building and submitting transactions" section of the app dev guide is a client tutorial

dplumb (Mon, 15 Oct 2018 16:23:03 GMT):
looks like we have a Python version and a JS version

Dan (Mon, 15 Oct 2018 16:23:57 GMT):
Oh, under "Development without an SDK"?

dplumb (Mon, 15 Oct 2018 16:24:28 GMT):
Its under "Python SDK" and "Javascript SDK"

dplumb (Mon, 15 Oct 2018 16:24:29 GMT):
https://sawtooth.hyperledger.org/docs/core/releases/latest/_autogen/sdk_submit_tutorial_python.html

achenette (Mon, 15 Oct 2018 16:24:36 GMT):
Python client tutorial: https://sawtooth.hyperledger.org/docs/core/nightly/master/_autogen/sdk_submit_tutorial_python.html

achenette (Mon, 15 Oct 2018 16:24:57 GMT):
JavaScript client tutorial: https://sawtooth.hyperledger.org/docs/core/nightly/master/_autogen/sdk_submit_tutorial_js.html

Dan (Mon, 15 Oct 2018 16:26:23 GMT):
oh cool beans. missed that.

achenette (Mon, 15 Oct 2018 16:27:02 GMT):
These sections are currently in master only, but will be included in the 1.1 docs for that upcoming release. Note that we dramatically reorganized and rewrote all SDK tutorials in master a few months ago.

dplumb (Mon, 15 Oct 2018 16:28:13 GMT):
Was there ever a Go client tutorial?

achenette (Mon, 15 Oct 2018 16:29:08 GMT):
@Dan - The edX 201 course for Sawtooth Simple Supply also has ~a nice tutorial on creating~ a (very simple) web client as an example. https://github.com/hyperledger/education-sawtooth-simple-supply/blob/master/course_modules/edX%20201%20Module%205%20-%20Simple%20Supply%20-%20Sawtooth%20for%20Application%20Development.pdf

achenette (Mon, 15 Oct 2018 16:29:08 GMT):
@Dan - The edX 201 course for Sawtooth Simple Supply also has a nice tutorial on creating a (very simple) web client. https://github.com/hyperledger/education-sawtooth-simple-supply/blob/master/course_modules/edX%20201%20Module%205%20-%20Simple%20Supply%20-%20Sawtooth%20for%20Application%20Development.pdf

achenette (Mon, 15 Oct 2018 16:29:37 GMT):
@dplumb - No, there was never a tutorial for a Go client for the reason you mentioned above (it's tricky).

dplumb (Mon, 15 Oct 2018 16:30:06 GMT):
Ah

dplumb (Mon, 15 Oct 2018 16:30:13 GMT):
There is no Go CLI for xo either

dplumb (Mon, 15 Oct 2018 16:30:17 GMT):
so that would have to be written

dplumb (Mon, 15 Oct 2018 16:30:22 GMT):
if we want to have that as an example

Dan (Mon, 15 Oct 2018 16:31:40 GMT):
@arsulegai from this discussion it seems like a go client tutorial would be super helpful. using the python or javascript client links above as templates for creating the go client tutorial, and then the recognition of needing a CLI for the go tic tac toe (xo) implementation.

achenette (Mon, 15 Oct 2018 16:32:33 GMT):
+1 (actually, +100000). @arsulegai , thanks for your offer to help with this documentation!

dplumb (Mon, 15 Oct 2018 16:34:47 GMT):
There is a Seth CLI in go which could be used as a reference https://github.com/hyperledger/sawtooth-seth/blob/master/cli-go/src/seth_cli/client/encoder.go

arsulegai (Mon, 15 Oct 2018 17:40:03 GMT):
Awesome, I'll work on it.. :)

arsulegai (Mon, 15 Oct 2018 17:41:52 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=dv6QLC2i2u8nZXMuv) @dplumb Thanks, I tried one simple example few days ago for understanding https://github.com/arsulegai/contentprotection/tree/master/ContentProtectionGoClient

LeonardoCarvalho (Tue, 16 Oct 2018 11:17:16 GMT):
guys, I feel very dumb asking this... But... Do indeed all validator nodes need a identity and settings TPs, and a REST api for it to work properly?

FrankCastellucci (Tue, 16 Oct 2018 12:35:16 GMT):
@LeonardoCarvalho Not necessarily, bare bones would be validator, settings and TPs. Rest is only needed if you don't have your own Application -> Validator pipe for submitting batches and identity is only needed if you want to take advantage of it's capabilities.

LeonardoCarvalho (Tue, 16 Oct 2018 21:56:40 GMT):
I'm trying to create a 3 node setup, and isn't behaving as expected, I think I got all version mixed up

LeonardoCarvalho (Tue, 16 Oct 2018 21:56:41 GMT):
:-/

boydjohnson (Tue, 16 Oct 2018 21:58:44 GMT):
What kind of setup? Ubuntu?

LeonardoCarvalho (Tue, 16 Oct 2018 22:44:24 GMT):
docker

LeonardoCarvalho (Wed, 17 Oct 2018 10:16:10 GMT):
hum, the documentation on running poet emulator seems a little outdated...

LeonardoCarvalho (Wed, 17 Oct 2018 10:17:11 GMT):
simulator, sorry, not enogh caffeine yet...

LeonardoCarvalho (Wed, 17 Oct 2018 10:17:18 GMT):
enough* (dammit)

Dan (Wed, 17 Oct 2018 12:51:01 GMT):
In the nightly docs or in the 1.0.5 docs?

LeonardoCarvalho (Thu, 18 Oct 2018 11:16:11 GMT):
@Dan I think I've built a two node with 1.0.3, months ago, tried to build one with 1.0.5 and read the nightly documentation.

LeonardoCarvalho (Thu, 18 Oct 2018 11:16:18 GMT):
tipical

LeonardoCarvalho (Thu, 18 Oct 2018 11:17:06 GMT):
If sawtooth ever needs a java engineer/architect, please remember, hehehe

boydjohnson (Fri, 19 Oct 2018 21:14:52 GMT):
@LeonardoCarvalho I put up a Java sdk PR that used a method from your PR. I am trying to align the Java sdk signing API with the other sdks. Let me know what you think.

LeonardoCarvalho (Sat, 20 Oct 2018 10:26:31 GMT):
That looks excellent, I've already approved that

LeonardoCarvalho (Sat, 20 Oct 2018 10:26:31 GMT):
That looks excellent, I've already approved it

LeonardoCarvalho (Sat, 20 Oct 2018 14:22:14 GMT):
ok,I definitively think there's some messed up on poet 1.0.5....

LeonardoCarvalho (Sat, 20 Oct 2018 14:22:32 GMT):
`poet-validator-registry-tp -C tcp://validator0:4004`

LeonardoCarvalho (Sat, 20 Oct 2018 14:22:51 GMT):
`Traceback (most recent call last): File "/usr/bin/poet-validator-registry-tp", line 9, in load_entry_point('sawtooth-poet-families==1.0.5', 'console_scripts', 'poet-validator-registry-tp')() File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 542, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2569, in load_entry_point return ep.load() File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2229, in load return self.resolve() File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2235, in resolve module = __import__(self.module_name, fromlist=['__name__'], level=0) File "/usr/lib/python3/dist-packages/sawtooth_validator_registry/validator_registry/processor/main.py", line 116, in main() File "/usr/lib/python3/dist-packages/sawtooth_validator_registry/validator_registry/processor/main.py", line 109, in main processor.start() File "/usr/lib/python3/dist-packages/sawtooth_sdk/processor/core.py", line 265, in start self._process_future(fut) File "/usr/lib/python3/dist-packages/sawtooth_sdk/processor/core.py", line 216, in _process_future self._process(msg) File "/usr/lib/python3/dist-packages/sawtooth_sdk/processor/core.py", line 130, in _process handler.apply(request, state) File "/usr/lib/python3/dist-packages/sawtooth_validator_registry/validator_registry/processor/handler.py", line 504, in apply context=context) File "/usr/lib/python3/dist-packages/sawtooth_validator_registry/validator_registry/processor/handler.py", line 311, in _verify_signup_info hashes.SHA256()) TypeError: verify() takes 4 positional arguments but 5 were given `

LeonardoCarvalho (Sat, 20 Oct 2018 14:23:24 GMT):
The code apparently sends 4 parameters, AFAICT

LeonardoCarvalho (Sun, 21 Oct 2018 15:09:07 GMT):
Forget that, wrong PEM.

boydjohnson (Tue, 23 Oct 2018 21:45:39 GMT):
https://github.com/hyperledger/sawtooth-sdk-java/pull/5 @arsulegai Can you re-review this? I finished the verify method so now everything is implemented.

arsulegai (Wed, 24 Oct 2018 02:39:09 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=6DLLWFpAtqcrafPjk) @boydjohnson Review done, thanks. It looks good :)

LeonardoCarvalho (Thu, 25 Oct 2018 11:40:48 GMT):
About the documentation, it is indeed lacking some info. The PEM to associate is on /etc, but I had to find it by trial and error...

arsulegai (Thu, 25 Oct 2018 12:54:54 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=gqeWZgj3SWzfxKhC2) @LeonardoCarvalho Are you talking about cli registration to validator registry tp?

LeonardoCarvalho (Thu, 25 Oct 2018 22:10:08 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=884b5a70-cae5-498a-a812-e6d9971cf96e) @arsulegai No, about the PoET simulator on the composer, version 1.0.5

LeonardoCarvalho (Fri, 26 Oct 2018 12:04:18 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=CjtkLvfbTwkXnB2Aw) @FrankCastellucci In the 1.0.5, every time I register a TP on a REST node, the other keeps expecting a registration as well. The round-robin got blocked or it should work with only one TP registered ?

fosdick (Fri, 26 Oct 2018 17:12:30 GMT):
I'm attempting to deploy the Sawtooth REST API using Kompose/Kubernetes, but am seeing the following error: `[2018-10-26 16:20:13.534 ERROR rest_api] [Errno 99] error while attempting to bind on address ('10.101.183.174', 8008): cannot assign requested address` Unfortunately, I’m not seeing any other details on why it can’t bind. Any thoughts/insight? Thanks in advance!

fosdick (Fri, 26 Oct 2018 17:13:18 GMT):
```Traceback (most recent call last): File "/usr/lib/python3.5/asyncio/base_events.py", line 958, in create_server sock.bind(sa) OSError: [Errno 99] Cannot assign requested address```

fosdick (Fri, 26 Oct 2018 21:38:59 GMT):
Is there a better room to post this question? ^

danintel (Fri, 26 Oct 2018 23:00:02 GMT):
@fosdick This room is for creating and fixing Sawtooth SDKs. I suggest #sawtooth

danintel (Fri, 26 Oct 2018 23:01:56 GMT):
@fosdick off-hand it seems the address is already being used.... Us there a duplicate or another process using tcp port 8008?

FrankCastellucci (Mon, 29 Oct 2018 10:24:58 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=WXFRiBNMHpjHokCq9) @LeonardoCarvalho Sorry, I'm not understanding. Are you saying that trying to bring up multiple TP on the same validator isn't working?

LeonardoCarvalho (Mon, 29 Oct 2018 12:48:01 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=tLizpDdwnkguvF9Mk) @FrankCastellucci No no, that looks like the round-robin on the N validators expects to have N TPs, and, when that's not the case, the validators keep awaiting and holding transactions

FrankCastellucci (Mon, 29 Oct 2018 14:12:08 GMT):
I believe a validator registers each TP as unique (regardless of whether it is a standalone TP with 1 family/version or one TP with multiple family/version)... if the validators gossip that information to each other then what you are seeing makes sense but it presents serious operational problem as well. Deploying TP changes across multiple nodes can literally stop transactions until 100% deployed?

FrankCastellucci (Mon, 29 Oct 2018 14:13:20 GMT):
We are all very focused on the transactions but in the wake we may be creating a cottage industry for operations

jsmitchell (Mon, 29 Oct 2018 14:42:25 GMT):
whether you run one or one hundred TPs handling a given family attached to a single validator -- the behavior should be the same. There is no communication between nodes about the number of TPs which need to be running.

FrankCastellucci (Mon, 29 Oct 2018 15:08:48 GMT):
Mayhaps I read @LeonardoCarvalho response incorrectly then

DerrickJoseph (Tue, 30 Oct 2018 10:19:36 GMT):
Has joined the channel.

DerrickJoseph (Tue, 30 Oct 2018 10:24:50 GMT):
i have been trying to run tests in _sawtooth-core/sdk/examples/intkey_python/tests/test_tp_intkey.py_ but seems like the event_loop in the MockValidator is spun up by the *TransactionProcessorTestCase.SetUpClass* and the test does not progresses, can someone please help me with running the sample tests in the repository itself, I am not able to understand the purpose of starting the eventloop during the test setup itself, I am using sawtooth version 1.0.1

DerrickJoseph (Tue, 30 Oct 2018 10:24:50 GMT):
i have been trying to run tests in _sawtooth-core/sdk/examples/intkey_python/tests/test_tp_intkey.py_ but seems like the event_loop in the MockValidator is spun up by the *TransactionProcessorTestCase.SetUpClass* and the test does not progresses, can someone please help me with running the sample tests provided in the repository itself, I am not able to understand the purpose of starting the eventloop during the test setup itself, I am using sawtooth version 1.0.1

LeonardoCarvalho (Tue, 30 Oct 2018 10:27:45 GMT):
A little further data on my comment. I've created a 4 validators cluster, with PoET simulator

LeonardoCarvalho (Tue, 30 Oct 2018 10:27:59 GMT):
connecting one Intkey TP, I see this in the console

LeonardoCarvalho (Tue, 30 Oct 2018 10:28:06 GMT):

Clipboard - October 30, 2018 8:28 AM

LeonardoCarvalho (Tue, 30 Oct 2018 10:28:37 GMT):
I run `intkey create_batch -K 50 -c 50`

LeonardoCarvalho (Tue, 30 Oct 2018 10:28:44 GMT):
and load in any validator

LeonardoCarvalho (Tue, 30 Oct 2018 10:28:55 GMT):
it accepts a number of transactions

LeonardoCarvalho (Tue, 30 Oct 2018 10:28:57 GMT):
and stop

LeonardoCarvalho (Tue, 30 Oct 2018 10:29:20 GMT):
I connect another intkey TP, in another node

LeonardoCarvalho (Tue, 30 Oct 2018 10:29:37 GMT):
it processes another set of transactions

LeonardoCarvalho (Tue, 30 Oct 2018 10:30:12 GMT):
and complains (a lot) : Block marked invalid(invalid predecessor)

LeonardoCarvalho (Tue, 30 Oct 2018 10:30:56 GMT):
but, if all 4 validators are connected to 4 TPs (1:1), the process runs smoothly

LeonardoCarvalho (Tue, 30 Oct 2018 10:31:06 GMT):
that's my observation

LeonardoCarvalho (Tue, 30 Oct 2018 10:31:19 GMT):
it's a 1.0.5 cluster

LeonardoCarvalho (Tue, 30 Oct 2018 11:09:08 GMT):
oh, PoET is in parallel mode, is that relevant?

LeonardoCarvalho (Wed, 31 Oct 2018 08:54:26 GMT):
ok, my question have been answered

LeonardoCarvalho (Wed, 31 Oct 2018 08:54:29 GMT):

Clipboard - October 31, 2018 6:54 AM

chainsaw (Wed, 31 Oct 2018 14:31:26 GMT):
Has joined the channel.

amundson (Wed, 31 Oct 2018 14:59:26 GMT):
@LeonardoCarvalho to expand on that - all the nodes in the network use consensus to agree on the current block (called HEAD). they use one of the consensus algorithms to do this (PoET, PBFT, Raft, etc.). Part of that is verifying the block. Each block has a merkle root of state (a hash of state essentially) that each node recreates. The process of recreating that state involves running every transaction (in order as it appears in the block). The actual execution of those transactions is scheduled either using the parallel scheduler or the serial scheduler -- but the result is the same (the parallel scheduler is designed to give the same results as the serial scheduler, only faster). Thus, all nodes need all the relevant transaction processors since they are all verifying and recreating state by running through the transactions.

amundson (Wed, 31 Oct 2018 15:01:38 GMT):
to your comment "PoET is in parallel mode" -- PoET is a consensus algorithm for agreeing on the current block and doesn't have a parallel mode. the parallel scheduler is a separate component from consensus and only involved in determining how to execute the transactions in a block.

boydjohnson (Wed, 31 Oct 2018 22:25:27 GMT):
https://stackoverflow.com/questions/53010200/maven-surefire-could-not-find-forkedbooter-class Those that are working on the java sdk, you might have run into this issue. This stackoverflow post shows a solution to peg the docker image to maven:3.5.3-jdk8.

LeonardoCarvalho (Thu, 01 Nov 2018 09:38:03 GMT):
@amundson Thank you for the clarification on the "parallel" meaning.

LeonardoCarvalho (Thu, 01 Nov 2018 09:39:28 GMT):
A question though. The blocks, by definition, got opaque transactions. So, to recreate them, it needs a TP for replay. Fine.

LeonardoCarvalho (Thu, 01 Nov 2018 09:39:56 GMT):
But this got, at least for some scenarios I am seeing on potential clients

LeonardoCarvalho (Thu, 01 Nov 2018 09:39:56 GMT):
But this got, at least for some scenarios I am seeing on potential clients, some issues.

LeonardoCarvalho (Thu, 01 Nov 2018 09:40:15 GMT):
Where there's TPs that cannot access other validators

LeonardoCarvalho (Thu, 01 Nov 2018 09:40:43 GMT):
(network topology, firewalls, needs for external services for generating the transaction,etc)

LeonardoCarvalho (Thu, 01 Nov 2018 09:41:24 GMT):
Say, I'm working on an SCEP implementation, to create a useful PKI for clients to register and manage private keys

LeonardoCarvalho (Thu, 01 Nov 2018 09:41:36 GMT):
Using government-issued USB tokens

LeonardoCarvalho (Thu, 01 Nov 2018 09:43:01 GMT):
So, to run a distributed network, there's no way to re-run all TPs on all validators, since the hardware will only be available in one physical location.

LeonardoCarvalho (Thu, 01 Nov 2018 09:43:25 GMT):
It means that I cannot implement that in Sawtooth at all ?

LeonardoCarvalho (Thu, 01 Nov 2018 09:44:44 GMT):
I was under an impression that the gossip would guarantee blocks integrity and transaction order without the need to recreate all transactions, so I must pay more attention to this details...

LeonardoCarvalho (Thu, 01 Nov 2018 09:46:37 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=Y9WEmmRyFGCEfhYdi) @boydjohnson Thank you, I'll bookmark it, should it propagate to the current Java SDK as well.

jsmitchell (Thu, 01 Nov 2018 12:53:07 GMT):
A TP should not talk to an external service - a sure recipe for non-determinism

boydjohnson (Thu, 01 Nov 2018 14:52:52 GMT):
https://github.com/hyperledger/sawtooth-sdk-java/pull/7 @LeonardoCarvalho @arsulegai @amundson Would you take a look at this PR? It breaks the java sdk into three modules.

amundson (Thu, 01 Nov 2018 15:46:34 GMT):
@LeonardoCarvalho can the per-site piece be in client code (not TP code)?

arsulegai (Sat, 03 Nov 2018 10:12:11 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=KzYyDpWDY87B9Easd) @boydjohnson Done, major comment is for a duplicate file in the PR which has to be removed.

arsulegai (Sat, 03 Nov 2018 10:14:02 GMT):
Don't know if it's already been discussed, do we need cleanup on protos so that only necessary protobuf are generated in SDK? There are a few protos which do not need to be part of SDK at least.

LeonardoCarvalho (Sun, 04 Nov 2018 14:43:18 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=qoxIGRH1XZDwXWj50A) @jsmitchell I disagree, if the operation is idempotent, we can protect the chain from some eclipse attacks. Would be very useful to apply oracles on some TPs.

LeonardoCarvalho (Sun, 04 Nov 2018 14:45:20 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=xZ5MhbcgiGzQj4j6o) @amundson Yeah, the only way to do that today would be that, but, again, some not so tech savvy clients would complain. And I think that, to create a big cooperation, the need for heterogeneous nodes will arise, IMHO.

LeonardoCarvalho (Sun, 04 Nov 2018 16:12:36 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=xZ5MhbcgiGzQj4j6o) @amundson Expanding my example, imagine that I need to confirm a PGP or SSL key, over some external server... How I could do that in the current topology?

jsmitchell (Sun, 04 Nov 2018 17:36:02 GMT):
You could either bring the raw material for the confirmation onto the chain in the form of transactions submitted (in which case you’d do the validation inside a TP), or you could build a trust model with a client key that is responsible for doing the external check and then submitting a signed transaction indicating the check passed.

LeonardoCarvalho (Sun, 04 Nov 2018 18:48:43 GMT):
Wouldn't that bypass the global validation? I think this is how the smart contracts are enforced right now, or am I mistaken (din't got the time to read about that yet...)

LeonardoCarvalho (Sun, 04 Nov 2018 18:48:47 GMT):
?

jsmitchell (Sun, 04 Nov 2018 20:40:16 GMT):
No...they would still be transactions that are getting validated. The TP would just not be contacting an outside service.

LeonardoCarvalho (Sun, 04 Nov 2018 20:42:39 GMT):
Hm. That probably would suffice. How can I get the documentation on smart contracts on Sawtooth?

jsmitchell (Sun, 04 Nov 2018 20:45:03 GMT):
I’m not sure what you mean

LeonardoCarvalho (Sun, 04 Nov 2018 20:46:13 GMT):
I've read about implementations of smart contracts on Sawtooth, I think it's called Sabre

jsmitchell (Sun, 04 Nov 2018 20:46:22 GMT):
You can do all this within TPs or you can use Sabre to store and invoke wasm bytecode on the chain

jsmitchell (Sun, 04 Nov 2018 20:46:40 GMT):
Which is functionally equivalent to a TP except for the deployment semantics

jsmitchell (Sun, 04 Nov 2018 20:46:58 GMT):
https://sawtooth.hyperledger.org/docs/sabre/releases/latest/

LeonardoCarvalho (Sun, 04 Nov 2018 20:49:44 GMT):
Oh, I must be mistaken, I remember something about using an external blockchain to execute the contracts, and expect to use an external service.

LeonardoCarvalho (Sun, 04 Nov 2018 20:50:45 GMT):
But I think that, using a 3-way trust model, using code to assess the status, I may get a good solution

jsmitchell (Sun, 04 Nov 2018 20:51:07 GMT):
Here be dragons

LeonardoCarvalho (Sun, 04 Nov 2018 20:51:15 GMT):
as always. :)

jsmitchell (Sun, 04 Nov 2018 20:52:30 GMT):
Seriously though, don’t call an external service from a TP. You will be sad.

jsmitchell (Sun, 04 Nov 2018 20:53:56 GMT):
The TP should be a pure state transition function with only current state and the contents of the transaction as inputs

LeonardoCarvalho (Sun, 04 Nov 2018 21:46:13 GMT):
Ok!

boydjohnson (Mon, 05 Nov 2018 19:07:15 GMT):
Hey @arsulegai I removed that unintended file from the PR. I will make the README.md in a separate PR.

boydjohnson (Mon, 05 Nov 2018 19:07:36 GMT):
https://github.com/hyperledger/sawtooth-sdk-java/pull/7 Can you re-review?

arsulegai (Tue, 06 Nov 2018 02:27:22 GMT):
@boydjohnson done

boydjohnson (Tue, 06 Nov 2018 17:12:27 GMT):
Thanks.

arsulegai (Tue, 06 Nov 2018 17:46:09 GMT):
@boydjohnson can you please review this and add others who can review? https://github.com/hyperledger/sawtooth-sdk-go/pull/17

boydjohnson (Wed, 07 Nov 2018 15:47:29 GMT):
Sure, thanks.

boydjohnson (Wed, 07 Nov 2018 15:50:00 GMT):
https://github.com/hyperledger/sawtooth-sdk-go/pull/17 @rberg2 Can you whitelist @arsulegai for the `sawtooth-sdk-go` repo?

rberg2 (Wed, 07 Nov 2018 15:50:00 GMT):
Has joined the channel.

rberg2 (Wed, 07 Nov 2018 15:53:00 GMT):
@boydjohnson @arsulegai had been added already. It looks like I missed restarting that build

boydjohnson (Wed, 07 Nov 2018 15:53:23 GMT):
Cool, thanks.

boydjohnson (Wed, 07 Nov 2018 16:05:44 GMT):
https://github.com/hyperledger/sawtooth-sdk-java/pull/8 @arsulegai @LeonardoCarvalho This adds metadata so the java sdk can be published to the Maven Central Repository. The thing that might cause comment is the group Id needs to be a reverse domain name so I used `org.hyperledger.sawtooth`. I didn't change the package names, so imports will all be the same, but the group id is different.

LeonardoCarvalho (Thu, 08 Nov 2018 10:50:41 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=d4hfDqWZePfWibLJo) @boydjohnson No problems !

LeonardoCarvalho (Thu, 08 Nov 2018 11:34:50 GMT):
Guys, the Java SDK will need this commit to be on the code: https://github.com/hyperledger/sawtooth-core/pull/1858

LeonardoCarvalho (Thu, 08 Nov 2018 11:35:26 GMT):
What is missing on it to be merged?

agunde (Thu, 08 Nov 2018 14:05:07 GMT):
@LeonardoCarvalho I added more reviewers to that PR (you need approvals from two maintainers) and you also need a successful build. Looks like when that PR submitted you were not whitelisted yet. I asked @rberg2 to check if you have been added yet and then the build will be restarted.

rberg2 (Thu, 08 Nov 2018 15:15:44 GMT):
:thumbsup:

agunde (Thu, 08 Nov 2018 15:57:44 GMT):
@LeonardoCarvalho looks like the code in that pr has some lint.

LeonardoCarvalho (Sat, 10 Nov 2018 16:07:47 GMT):
Ok, I'm on it!

LeonardoCarvalho (Sat, 10 Nov 2018 16:20:01 GMT):
(I don't know you, but I find hilarious that on that issue EVERYONE is looking at the left)

boydjohnson (Mon, 12 Nov 2018 21:23:22 GMT):
https://github.com/hyperledger/sawtooth-sdk-java/pull/10 @arsulegai This is the README.md you asked for. Can you review it?

arsulegai (Tue, 13 Nov 2018 03:45:06 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=EmkWGwtAirn5dAepx) @boydjohnson Awesome, so fast. Looks good for beginners.

LeonardoCarvalho (Tue, 13 Nov 2018 10:04:48 GMT):
@agunde How would I solve the 2 issues on the PR? The indentation looks ok on my local copy, and the log is written once for each probe received (i.e., once per probe-enabled TP)

agunde (Tue, 13 Nov 2018 13:36:38 GMT):
You should run lint locally (using `bin/run_lint`) and making any changes requested until it builds successfully. Once that is fixed dan's review will be requested. @LeonardoCarvalho

LeonardoCarvalho (Wed, 14 Nov 2018 11:08:53 GMT):
autopep8 FTW

agunde (Wed, 14 Nov 2018 14:09:50 GMT):
@LeonardoCarvalho looks like you need to rebase that pr to pick up some rust lint that was fixed

LeonardoCarvalho (Fri, 16 Nov 2018 11:53:03 GMT):
ok, just pushed the merge

pschwarz (Tue, 20 Nov 2018 16:31:58 GMT):
We're planning on republishing the Java SDK as a 1.8 jar - this should have a broader deployment base, including many cloud providers and Android.

pschwarz (Tue, 20 Nov 2018 16:32:39 GMT):
Historically, the adoption rate on new JDK's is slow, so it can be quite limiting to base a library jar on the latest release

amundson (Tue, 20 Nov 2018 21:18:52 GMT):
@LeonardoCarvalho @arsulegai ^

arsulegai (Wed, 21 Nov 2018 02:43:14 GMT):
@LeonardoCarvalho brought up few issues with Java 8 in the review here https://github.com/hyperledger/sawtooth-sdk-java/pull/7 which are still required to be considered. And this discussion popped up because of maven version incompatibility with Java 8. I'm ok with changes proposed by @pschwarz, here are my thoughts: > Android may stop supporting at Java 8 > Other workarounds: 1. Use plugins such as toolchains (by using user configured xml change the version) and/or document a way to generate SDK for latest versions and say we have published images for particular version. This would give flexibility to developer as long as we do not bring in Java 11 dependencies in code. 2. If possible publish SDK for different versions, I've never tried/seen it but it appears to be possible.

LeonardoCarvalho (Wed, 21 Nov 2018 08:54:20 GMT):
Hello all. Yeah, I'm aware of the issues, and there's some options like @arsulegai told. An indian guy needed an jdk8 version for this exact reason, and on the poms there's already a profile for this jdk. Is merely the case of: 1- Putting all the different implementations on the specific directory, and any incompatible jars in a dependency declaration 2- During the repository publishing, use the jdk8 classifier.

LeonardoCarvalho (Wed, 21 Nov 2018 08:54:53 GMT):
The code in place already do that, and the indian developer is a happy user

LeonardoCarvalho (Wed, 21 Nov 2018 08:54:54 GMT):
:)

pschwarz (Thu, 22 Nov 2018 00:03:42 GMT):
Is there a specific PR with that in place? Or maybe I'm missing that in the current pom

pschwarz (Thu, 22 Nov 2018 00:04:26 GMT):
> Android may stop supporting Java 8 I don't want to make decisions that prevent people from using it _now_

pschwarz (Thu, 22 Nov 2018 00:05:14 GMT):
Plus, with the recent news that AWS is generating its own supported builds of OpenJDK 8 add's some longevity to the platform

pschwarz (Thu, 22 Nov 2018 00:06:01 GMT):
Many large corporations and government departments are slow to adopt the latest versions due to security audit concerns

pschwarz (Thu, 22 Nov 2018 00:07:12 GMT):
(For example, I was on a project years ago that was stuck on JDK 1.4, and therefore couldn't use any of the fancy 1.6 features, like generics, due to the DoE being very cautious about it's audits

LeonardoCarvalho (Thu, 22 Nov 2018 10:24:06 GMT):
@pschwarz , please see https://github.com/CarvalhoLeonardo/sawtooth-sdk-java/blob/master/sdk-common/pom.xml line 110. It was in the original PR, at least

LeonardoCarvalho (Thu, 22 Nov 2018 10:24:58 GMT):
And yes, we may need to give java-8 stuck enterprises this builds, but the security audits will soon ask for Java 11. There's a lot of security problems in older libraries bound to jdk8

LeonardoCarvalho (Thu, 22 Nov 2018 10:29:19 GMT):
depending on the demand, we can create a module to define APIs and interfaces, based on the .proto files, using only primitives

LeonardoCarvalho (Thu, 22 Nov 2018 10:29:40 GMT):
and split the implementations

aKesav (Sat, 24 Nov 2018 08:26:22 GMT):
Has joined the channel.

bochuxt (Mon, 26 Nov 2018 07:13:46 GMT):
Has joined the channel.

amundson (Tue, 27 Nov 2018 17:29:49 GMT):
@LeonardoCarvalho what is the motivation behind not wanting to use the java 8 build for everything?

LeonardoCarvalho (Tue, 27 Nov 2018 22:32:19 GMT):
Primarily a low level incompatibility with memory, CPU and I/O handling: https://blogs.oracle.com/java-platform-group/java-se-support-for-docker-cpu-and-memory-limits https://royvanrijn.com/blog/2018/05/java-and-docker-memory-limits/ And, as a side effect, the low performance of the Reactor model due to that and other tidbits

LeonardoCarvalho (Wed, 28 Nov 2018 09:45:44 GMT):
OTOH, Jav 8 is being EOLed next year...

pschwarz (Wed, 28 Nov 2018 15:29:43 GMT):
You're conflating jdk1.8 class compatibility with the jvm itself. Being jdk 1.8 compatible jar doesn't mean that the jar is unusable from jdk11

pschwarz (Wed, 28 Nov 2018 15:32:53 GMT):
Plus, I rather have things work broadly now, and we can sort out optimizations by platform in the meantime, before it is actual EOL'd (and that really is only only Oracle's JDK 8, mind you. OpenJDK 1.8 is being EOL late 2020, and will continue to be supported through 2023 on some platforms e.g. RedHat)

pschwarz (Wed, 28 Nov 2018 15:39:37 GMT):
Java 8 on android is recent, and I'm not seeing much about how it will be "going away" (unless you are talking about Fuchsia replacing Android which is a whole different animal)

LeonardoCarvalho (Wed, 28 Nov 2018 21:12:52 GMT):
Surely, but the rationale on preferring JDK 11 is solely on the heavy lifting part, and, IMHO, the profile of the runtimes needing to run JDK 8 would be mostly clients.

pschwarz (Thu, 29 Nov 2018 16:18:03 GMT):
Classes compiled targeting JDK11 only run on JDK11. So compiled artifacts need to be provided that can support both platforms.

fosdick (Thu, 06 Dec 2018 19:03:08 GMT):
I'm seeing the following at the startup of the Sawtooth Identity TP: ```pkg_resources.DistributionNotFound: The 'sawtooth-sdk' distribution was not found and is required by sawtooth-identity``` Is this a known bug?

rbuysse (Thu, 06 Dec 2018 19:39:20 GMT):
is this an ubuntu installation or a docker image?

fosdick (Thu, 06 Dec 2018 19:53:55 GMT):
Docker image

fosdick (Thu, 06 Dec 2018 19:54:16 GMT):
Using the latest tag

fosdick (Thu, 06 Dec 2018 19:54:22 GMT):
1.0.5 is fine

rbuysse (Thu, 06 Dec 2018 20:38:30 GMT):
Interesting! I can reproduce.

rbuysse (Thu, 06 Dec 2018 20:52:38 GMT):
In the short term, it doesn't look like there were any changes that should affect its usage, so you can use the 1.0.5 image

rbuysse (Thu, 06 Dec 2018 20:52:46 GMT):
I'll work on getting an updated version out tomorrow.

rbuysse (Thu, 06 Dec 2018 20:52:51 GMT):
sorry about this!

fosdick (Thu, 06 Dec 2018 21:28:51 GMT):
No worries. Thanks for looking, @rbuysse!

MatthewRubino (Fri, 07 Dec 2018 16:36:20 GMT):
Has joined the channel.

MatthewRubino (Fri, 07 Dec 2018 16:37:09 GMT):
@rbuysse i was getting this error using the block info tp 1.1 docker image as well

MatthewRubino (Fri, 07 Dec 2018 16:38:12 GMT):
```pkg_resources.DistributionNotFound: The 'sawtooth-sdk' distribution was not found and is required by sawtooth-block-info```

rbuysse (Fri, 07 Dec 2018 17:05:39 GMT):
I've got a PR up to resolve that issue.

rbuysse (Fri, 07 Dec 2018 17:05:52 GMT):
in the meantime, you can use the 1.0.5 image

MatthewRubino (Fri, 07 Dec 2018 18:49:45 GMT):
yep, just making sure both were aware. and thanks!

javier322 (Fri, 07 Dec 2018 20:22:24 GMT):
Has joined the channel.

nhrishi (Mon, 10 Dec 2018 17:23:18 GMT):
Has joined the channel.

amolk (Mon, 10 Dec 2018 18:06:29 GMT):
@tomislav we have some customers asking for the dot-net SDK. Do you know if it's been tested recently with Sawtooth?

tomislav (Mon, 10 Dec 2018 18:09:24 GMT):
I’ve been contacted by couple of guys with questions on specific usage. I’m not aware of any broader use, but I havent heard of any bugs either.

tomislav (Mon, 10 Dec 2018 18:10:44 GMT):
I did push a new package version to NuGet that had updated model based on the protos, but this didn’t require source code change.

tomislav (Mon, 10 Dec 2018 18:12:59 GMT):
I should do a broader testing now with 1.1 out and maybe add some dockerized tests.

sanjeet.kumar (Wed, 19 Dec 2018 06:36:17 GMT):
Has joined the channel.

merq (Sat, 22 Dec 2018 03:42:03 GMT):
Has joined the channel.

JonasM (Mon, 14 Jan 2019 16:07:06 GMT):
Has joined the channel.

rbuysse (Wed, 16 Jan 2019 16:31:44 GMT):
Hello everyone! I opened PR# 1999 yesterday to remove the Rust SDK and the Devmode consensus engine from the sawtooth-core git repo. In order to minimize disruption to anyone using the Rust SDK, I wanted to provide some heads-up and lead time for people to update their projects to use the new locations before the PR is merged. If you're specifying the dependency in your Cargo.toml files with the line: sawtooth-sdk = { git = "https://github.com/hyperledger/sawtooth-core.git" } You must update this line to point to the new Rust SDK location: sawtooth_sdk = { git = "https://github.com/hyperledger/sawtooth-sdk-rust.git" } Or you can use the 0.1.0 version of the Rust SDK that is published to crates.io: sawtooth-sdk = "0.1.0" I plan to merge this PR next Wednesday, 1/23/2019, at around 3pm CDT. Please have your updates complete before then. Links: PR# 1999: https://github.com/hyperledger/sawtooth-core/pull/1999 Sawooth Rust SDK: https://github.com/hyperledger/sawtooth-sdk-rust Sawtooth Devmode Consensus Engine: https://github.com/hyperledger/sawtooth-devmode Sawtooth SDK on crates.io: https://crates.io/crates/sawtooth-sdk

colincmcc (Thu, 17 Jan 2019 14:00:11 GMT):
Hello Everyone! I've been attempting to compile the rust intkey example on Windows x64 running Windows 10 Home Edition from the rust sdk for a couple of days now and am stuck on this error ``` note: Creating library C:\work\hamlet-loyalty\sawtooth-backend\hamlet-tp\code\target\debug\deps\bin_hamlet-0ea65bf0fac40859.lib and object C:\work\hamlet-loyalty\sawtooth-backend\hamlet-tp\code\target\debug\deps\bin_hamlet-0ea65bf0fac40859.exp liblib_hamlet-11ab42cb68683cbf.rlib(lib_hamlet-11ab42cb68683cbf.kt6hgwgrb5264u5.rcgu.o) : error LNK2019: unresolved external symbol ldexpf referenced in function _ZN4cbor7decoder3ffi8c_ldexpf17h3dc28d6acd4dd4c1E C:\work\hamlet-loyalty\sawtooth-backend\hamlet-tp\code\target\debug\deps\bin_hamlet-0ea65bf0fac40859.exe : fatal error LNK1120: 1 unresolved externals ``` I have OpenSSl and the proper libzmq files. `sawtooth-zmq-0.8.2-dev5` and `sawtooth-sdk 0.1.0` (from crates.io) compile fine. It's only on the last step and I can't find anything relating to `ldexpf`. Can anybody point me to how I may be able to fix this? Thank you for any help! Atm, I'm running my code on a Linux VM to get around it, but I'd like to solve this issue. It was not easy to get to this point.

amundson (Thu, 17 Jan 2019 16:41:42 GMT):
@colincmcc many of us use macs or just do development using the docker containers, so you may be exploring uncharted territory

jsmitchell (Thu, 17 Jan 2019 16:52:43 GMT):
i believe `ldexpf` is a built in function (provided by the compiler). Sounds like an OS/compiler issue. Also, it looks like it is being used by cbor. A couple of thoughts: consider not using floats in your TP - representations may be non-deterministic across architectures, consider not using cbor. We generally use protobuf across the board for transaction payload and state representation. I'm not saying you won't run into other compilation issues, but you might want to give that a try.

jsmitchell (Thu, 17 Jan 2019 16:52:43 GMT):
i believe `ldexpf` is a built in function (provided by the compiler). Sounds like an OS/compiler issue. Also, it looks like it is being used by cbor. A couple of thoughts: consider not using floats in your TP - representations may be non-deterministic across architectures. Also, consider not using cbor. We generally use protobuf across the board for transaction payload and state representation. I'm not saying you won't run into other compilation issues, but you might want to give that a try.

colincmcc (Thu, 17 Jan 2019 18:25:53 GMT):
@amundson @jsmitchell Thank you for the advice! I'll attempt to migrate away from cbor. Floats have hurt me in the past too, specifically with the JS SDK. If I do get it working on Windows, I'll post how. Although, with the amount of steps it took me to get to this point, it's probably not worth it. I'll probably just develop inside a docker container/vm, like how @amundson mentioned.

amundson (Thu, 17 Jan 2019 21:30:02 GMT):
@colincmcc are the difficulties inherent with Windows development, or are there things we are doing that make it hard?

colincmcc (Fri, 18 Jan 2019 02:38:31 GMT):
@amundson all the difficulties lie with Windows development

danintel (Fri, 18 Jan 2019 02:39:26 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=imkLXXuJEtkPqCHdJ) @colincmcc I use docker on virtualbox with ubuntu on windows 10

colincmcc (Fri, 18 Jan 2019 02:43:03 GMT):
@danintel That's what I ended up doing.

colincmcc (Fri, 18 Jan 2019 03:12:04 GMT):
So, I did end up getting it to compile in the end. Cbor was the culprit. I'm familiar with protoc, so I'll just move that direction. In case anybody encounters this issue in the future, here are a couple of tips: 1. Download libzmq from https://github.com/zeromq/libzmq and compile from source using cmake. One option is to follow the steps in the .appveyor.bat file in the `sawtooth-zmq-0.8.2-dev5` folder, located in your `.crates` folder. It contains appropriate cmake and msbuild commands, which may save some time, rather than try to follow the INSTALL instructions that come with libzmq. Windows binaries stop after something around 4.04 and you need 4.2. 2. Download OpenSSl and install. A dependency `rust-openssl` states that it will autolocate your ssl installation, but that was not the case for me. You'll have to set the location as an environment variable. 3. Download protoc and set in your path `https://github.com/protocolbuffers/protobuf/releases` 4. Set these environment variables `OPENSSL_DIR`, `LIBZMQ_INCLUDE_DIR`, `LIBZMQ_PREFIX`, `LIBZMQ_LIB_DIR` 5. After all of this I still faced a missing dll error. Though it wouldn't specify which one I was missing. I had to go directly to the failed build script exe and run it, which presented more info. One of the dependencies needs libzmq.dll and will not look for it under any of those set variable locations. I first put it directly in the build script folder as a test (which worked), but then eventually put it in a folder in one of my Environment Paths (which also worked).

colincmcc (Fri, 18 Jan 2019 03:12:04 GMT):
So, I did end up getting it to compile in the end. Cbor was the culprit. I'm familiar with protoc, so I'll just move that direction. In case anybody encounters this issue in the future, here are a couple of tips: 1. Download libzmq from https://github.com/zeromq/libzmq and compile from source using cmake. One option is to follow the steps in the .appveyor.bat file in the `sawtooth-zmq-0.8.2-dev5` folder, located in your `.crates` folder. It contains appropriate cmake and msbuild commands, which may save some time, rather than try to follow the INSTALL instructions that come with libzmq. Windows binaries stop after something around 4.04 and you need 4.2. EDIT: I believe you also need to rename the build lib file from `libzmq.lib` to `zmq.lib` 2. Download OpenSSl and install. A dependency `rust-openssl` states that it will autolocate your ssl installation, but that was not the case for me. You'll have to set the location as an environment variable. 3. Download protoc and set in your path `https://github.com/protocolbuffers/protobuf/releases` 4. Set these environment variables `OPENSSL_DIR`, `LIBZMQ_INCLUDE_DIR`, `LIBZMQ_PREFIX`, `LIBZMQ_LIB_DIR` 5. After all of this I still faced a missing dll error. Though it wouldn't specify which one I was missing. I had to go directly to the failed build script exe and run it, which presented more info. One of the dependencies needs libzmq.dll and will not look for it under any of those set variable locations. I first put it directly in the build script folder as a test (which worked), but then eventually put it in a folder in one of my Environment Paths (which also worked).

colincmcc (Fri, 18 Jan 2019 03:12:04 GMT):
So, I did end up getting it to compile in the end. Cbor was the culprit. I'm familiar with protoc, so I'll just move that direction. In case anybody encounters this issue in the future, here are a couple of tips: 1. Download libzmq from https://github.com/zeromq/libzmq and compile from source using cmake. One option is to follow the steps in the .appveyor.bat file in the `sawtooth-zmq-0.8.2-dev5` folder, located in your `.crates` folder. It contains appropriate cmake and msbuild commands, which may save some time, rather than try to follow the INSTALL instructions that come with libzmq. Windows binaries stop after something around 4.04 and you need 4.2. EDIT: I believe you also need to rename the built lib file from `libzmq.lib` to `zmq.lib` 2. Download OpenSSl and install. A dependency `rust-openssl` states that it will autolocate your ssl installation, but that was not the case for me. You'll have to set the location as an environment variable. 3. Download protoc and set in your path `https://github.com/protocolbuffers/protobuf/releases` 4. Set these environment variables `OPENSSL_DIR`, `LIBZMQ_INCLUDE_DIR`, `LIBZMQ_PREFIX`, `LIBZMQ_LIB_DIR` 5. After all of this I still faced a missing dll error. Though it wouldn't specify which one I was missing. I had to go directly to the failed build script exe and run it, which presented more info. One of the dependencies needs libzmq.dll and will not look for it under any of those set variable locations. I first put it directly in the build script folder as a test (which worked), but then eventually put it in a folder in one of my Environment Paths (which also worked).

colincmcc (Fri, 18 Jan 2019 03:12:04 GMT):
So, I did end up getting it to compile in the end. Cbor was the culprit. I'm familiar with protoc, so I'll just move that direction. In case anybody encounters this issue in the future, here are a couple of tips: *Sawtooth Rust SDK Windows Development * 1. Download libzmq from https://github.com/zeromq/libzmq and compile from source using cmake. One option is to follow the steps in the .appveyor.bat file in the `sawtooth-zmq-0.8.2-dev5` folder, located in your `.crates` folder. It contains appropriate cmake and msbuild commands, which may save some time, rather than try to follow the INSTALL instructions that come with libzmq. Windows binaries stop after something around 4.04 and you need 4.2. EDIT: I believe you also need to rename the built lib file from `libzmq.lib` to `zmq.lib` 2. Download OpenSSl and install. A dependency `rust-openssl` states that it will autolocate your ssl installation, but that was not the case for me. You'll have to set the location as an environment variable. 3. Download protoc and set in your path `https://github.com/protocolbuffers/protobuf/releases` 4. Set these environment variables `OPENSSL_DIR`, `LIBZMQ_INCLUDE_DIR`, `LIBZMQ_PREFIX`, `LIBZMQ_LIB_DIR` 5. After all of this I still faced a missing dll error. Though it wouldn't specify which one I was missing. I had to go directly to the failed build script exe and run it, which presented more info. One of the dependencies needs libzmq.dll and will not look for it under any of those set variable locations. I first put it directly in the build script folder as a test (which worked), but then eventually put it in a folder in one of my Environment Paths (which also worked).

colincmcc (Fri, 18 Jan 2019 03:12:04 GMT):
So, I did end up getting it to compile in the end. Cbor was the culprit. I'm familiar with protoc, so I'll just move that direction. In case anybody encounters this issue in the future, here are a couple of tips: *Sawtooth Rust SDK Windows Development* 1. Download libzmq from https://github.com/zeromq/libzmq and compile from source using cmake. One option is to follow the steps in the .appveyor.bat file in the `sawtooth-zmq-0.8.2-dev5` folder, located in your `.crates` folder. It contains appropriate cmake and msbuild commands, which may save some time, rather than try to follow the INSTALL instructions that come with libzmq. Windows binaries stop after something around 4.04 and you need 4.2. EDIT: I believe you also need to rename the built lib file from `libzmq.lib` to `zmq.lib` 2. Download OpenSSl and install. A dependency `rust-openssl` states that it will autolocate your ssl installation, but that was not the case for me. You'll have to set the location as an environment variable. 3. Download protoc and set in your path `https://github.com/protocolbuffers/protobuf/releases` 4. Set these environment variables `OPENSSL_DIR`, `LIBZMQ_INCLUDE_DIR`, `LIBZMQ_PREFIX`, `LIBZMQ_LIB_DIR` 5. After all of this I still faced a missing dll error. Though it wouldn't specify which one I was missing. I had to go directly to the failed build script exe and run it, which presented more info. One of the dependencies needs libzmq.dll and will not look for it under any of those set variable locations. I first put it directly in the build script folder as a test (which worked), but then eventually put it in a folder in one of my Environment Paths (which also worked).

colincmcc (Fri, 18 Jan 2019 03:12:04 GMT):
So, I did end up getting it to compile in the end. Cbor was the culprit. I'm familiar with protoc, so I'll just move that direction. In case anybody encounters this issue in the future, here are a couple of tips: *Sawtooth Rust SDK Windows Development* 1. Download libzmq from https://github.com/zeromq/libzmq and compile from source using cmake. One option is to follow the steps in the .appveyor.bat file in the `sawtooth-zmq-0.8.2-dev5` folder, located in your `.crates` folder. It contains appropriate cmake and msbuild commands, which may save some time, rather than try to follow the INSTALL instructions that come with libzmq. Windows binaries stop after something around 4.04 and you need 4.2. EDIT: I believe you also need to rename the built lib file from `libzmq.lib` to `zmq.lib` 2. Download OpenSSl and install. A dependency `rust-openssl` states that it will autolocate your ssl installation, but that was not the case for me. You'll have to set the location as an environment variable. 3. Download protoc and set in your path `https://github.com/protocolbuffers/protobuf/releases` 4. Set these environment variables `OPENSSL_DIR`, `LIBZMQ_INCLUDE_DIR`, `LIBZMQ_PREFIX`, `LIBZMQ_LIB_DIR` EDIT: It's been working for me by only setting the `OPENSSL_DIR` and `LIBZMQ_PREFIX`. I have ` libzmq.dll` in my system32 folder, so I'm not sure if that makes a difference or not. 5. After all of this I still faced a missing dll error. Though it wouldn't specify which one I was missing. I had to go directly to the failed build script exe and run it, which presented more info. One of the dependencies needs libzmq.dll and will not look for it under any of those set variable locations. I first put it directly in the build script folder as a test (which worked), but then eventually put it in a folder in one of my Environment Paths (which also worked).

colincmcc (Fri, 18 Jan 2019 03:12:04 GMT):
So, I did end up getting it to compile in the end. Cbor was the culprit. I'm familiar with protoc, so I'll just move that direction. In case anybody encounters this issue in the future, here are a couple of tips: *Sawtooth Rust SDK Windows Development* 1. Download libzmq from https://github.com/zeromq/libzmq and compile from source using cmake. One option is to follow the steps in the .appveyor.bat file in the `sawtooth-zmq-0.8.2-dev5` folder, located in your `.crates` folder. It contains appropriate cmake and msbuild commands, which may save some time, rather than try to follow the INSTALL instructions that come with libzmq. Windows binaries stop after something around 4.04 and you need 4.2. EDIT: I believe you also need to rename the built lib file from `libzmq.lib` to `zmq.lib` 2. Download OpenSSl and install. A dependency `rust-openssl` states that it will autolocate your ssl installation, but that was not the case for me. You'll have to set the location as an environment variable. 3. Download protoc and set in your path `https://github.com/protocolbuffers/protobuf/releases` 4. Set these environment variables `OPENSSL_DIR`, `LIBZMQ_INCLUDE_DIR`, `LIBZMQ_PREFIX`, `LIBZMQ_LIB_DIR` EDIT 02/03/2019 : It's been working for me by only setting the `OPENSSL_DIR` and `LIBZMQ_PREFIX`. I have ` libzmq.dll` in my system32 folder, so I'm not sure if that makes a difference or not. 5. After all of this I still faced a missing dll error. Though it wouldn't specify which one I was missing. I had to go directly to the failed build script exe and run it, which presented more info. One of the dependencies needs libzmq.dll and will not look for it under any of those set variable locations. I first put it directly in the build script folder as a test (which worked), but then eventually put it in a folder in one of my Environment Paths (which also worked). NOTE 02/03/2019: If you move the zmq dependencies from the path previously specified or you make a mistake setting the path and run a build, you must run `cargo clean` before rebuilding. Despite setting the variables to the correct location, building will continue to look in the previous builds environment for the location of the zmq files.

colincmcc (Fri, 18 Jan 2019 03:13:25 GMT):
However, I work off multiple machines and will probably just use the custom Docker file I built. It just adds a little to the build time, but at least I know it will work across environments.

colincmcc (Fri, 18 Jan 2019 03:17:42 GMT):
I appreciate everyone's help though in trying to figure this out. At least you now know it is possible to develop on Windows with Rust. Hopefully, it's easier in the future.

pschwarz (Mon, 21 Jan 2019 22:27:12 GMT):
That might be an interesting addition to the Sawtooth FAQ...

robinrob (Wed, 30 Jan 2019 19:42:44 GMT):
Has joined the channel.

colincmcc (Sun, 03 Feb 2019 16:38:36 GMT):
I updated the steps with a couple of things I've learned working in Rust and using the Rust SDK.

colincmcc (Sun, 03 Feb 2019 16:38:36 GMT):
@danintel I updated the steps with a couple of things I've learned working in Rust and using the Rust SDK. I'll make a pull request with the changes

danintel (Sun, 03 Feb 2019 22:55:53 GMT):
@colincmcc Yes. please file a PR. Thanks for documenting the steps.

prabu3192 (Mon, 04 Feb 2019 06:00:11 GMT):
Has joined the channel.

arsulegai (Mon, 04 Feb 2019 10:35:30 GMT):
Question: Is it intentional to skip inclusion of *.pb.h files in deb package https://github.com/hyperledger/sawtooth-sdk-cxx/blob/0f9fca09d136fc86fcc31824db2c13f63af5de91/CMakeLists.txt#L57 ?

arsulegai (Mon, 04 Feb 2019 16:29:30 GMT):
@amundson @pschwarz ^

arsulegai (Mon, 04 Feb 2019 16:29:30 GMT):
@rberg2 @rbuysse

arsulegai (Mon, 04 Feb 2019 16:29:30 GMT):
@rberg2 @rbuysse @amundson ^

tomislav (Tue, 05 Feb 2019 22:53:26 GMT):
Small update to the dotnet sdk with instructions to build SDK locally - https://github.com/hyperledger/sawtooth-sdk-dotnet/pull/6

arsulegai (Thu, 07 Feb 2019 17:03:50 GMT):
@rberg2 @rbuysse @amundson if it's not intentional, shall I plan to expose generated protobuf as part of SDK? I've a feature change to be done in CXX SDK which requires one of enum from protobuf exposed to TP

amundson (Thu, 07 Feb 2019 17:13:15 GMT):
@arsulegai I believe any exposure of external libraries (including protobuf objects) in our APIs was/is a mistake.

amundson (Thu, 07 Feb 2019 17:14:27 GMT):
so, for Rust, we are going to remove the protobuf stuff from the API. but the replacement objects have all the relevant data, there is just some conversion between protobufs and the structs used in the API

arsulegai (Thu, 07 Feb 2019 17:19:52 GMT):
I understood what you meant by removal of protobuf in another thread now.. Sure then I'll not expose them, but they'll be duplicate enum for now.

amundson (Thu, 07 Feb 2019 17:23:13 GMT):
yeah, sorry, more of replacing it with a very similar struct than changing the API much

amundson (Thu, 07 Feb 2019 17:24:12 GMT):
I don't really want to do super disruptive changes to the Rust SDK, we have a lot of code that uses it, but we have to do some of these prior to a 1.0 version.

LeonardoCarvalho (Mon, 18 Feb 2019 12:02:56 GMT):
guys, good morning/afternoon/night

LeonardoCarvalho (Mon, 18 Feb 2019 12:03:11 GMT):
I got a nifty opportunity to evolve Sawtooth based on some specific customers

LeonardoCarvalho (Mon, 18 Feb 2019 12:03:15 GMT):
they asked a little demo

LeonardoCarvalho (Mon, 18 Feb 2019 12:03:40 GMT):
And I can run XO and Int, but the Small Bank demo isn't helping much...

LeonardoCarvalho (Mon, 18 Feb 2019 12:03:59 GMT):
which version is better suited to a quick demo, the Go or Rust version?

LeonardoCarvalho (Mon, 18 Feb 2019 12:04:16 GMT):
Go 1.1 is giving me weird "TpStateGetResponse.AUTHORIZATION_ERROR" errors with valid addresses

pschwarz (Mon, 18 Feb 2019 15:07:45 GMT):
Is the rust version handling them appropriately?

LeonardoCarvalho (Mon, 18 Feb 2019 22:33:55 GMT):
I'll test tomorrow morning

LeonardoCarvalho (Tue, 19 Feb 2019 09:58:31 GMT):
found the issue, the addresses to be set need to be in input, output *AND* dependent addresses of the transaction request.

amundson (Tue, 19 Feb 2019 14:50:03 GMT):
@LeonardoCarvalho the dependencies field is not for addresses, but for a list of transactions

LeonardoCarvalho (Wed, 20 Feb 2019 10:27:52 GMT):
Indeed, but the TP isn't accepting this field as null, I'll try as an empty list...

LeonardoCarvalho (Wed, 20 Feb 2019 11:46:05 GMT):
well, Iḿ at a loss

LeonardoCarvalho (Wed, 20 Feb 2019 11:46:06 GMT):
sawtooth-smallbank-tp-go-default | 2019/02/20 11:43:35.406431 handler.go:56: [DEBUG] smallbank txn 2dda64568e9011d76055fa91857c089ae516acd095a44c548beda811973c3866479790263e39558faf5021c7a4b275d77d60b0b32c3adb6401f5f310891de48d: type CREATE_ACCOUNT sawtooth-smallbank-tp-go-default | 2019/02/20 11:43:35.408981 worker.go:84: [WARN] (8a848803-a2fd-49d7-88a1-411536ff15d4 ) Authorization exception: Tried to get unauthorized address: [3325148151b869447a0877231a9d89be41fe9f49b55f16deee22d2c1b6328cb36f07b2]

LeonardoCarvalho (Wed, 20 Feb 2019 11:46:23 GMT):
cannot create accounts using the REST endpoints

LeonardoCarvalho (Wed, 20 Feb 2019 11:46:27 GMT):
no messages at all

LeonardoCarvalho (Wed, 20 Feb 2019 11:46:37 GMT):
I'll try to run the rust image

danintel (Thu, 21 Feb 2019 08:01:56 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=qArFuGphbTydoE4at) @LeonardoCarvalho What works for me is a list of one item... A zero length string. This means a wildcard... Accept all addresses. Better yet... List the addresses you read and write for parallelism. i did this for Python... I assume it can be done in Rust. Maybe

danintel (Thu, 21 Feb 2019 08:01:56 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=qArFuGphbTydoE4at) @LeonardoCarvalho What works for me is a list of one item... A zero length string. This means a wildcard... Accept all addresses. Better yet... List the addresses you read and write for parallelism. I did this for Python... I assume it can be done in Rust. Maybe

LeonardoCarvalho (Thu, 21 Feb 2019 11:03:02 GMT):
yay, I didn't tried that!

LeonardoCarvalho (Thu, 21 Feb 2019 11:12:11 GMT):
no dice, putting a list with an empty string got me this error: lmdb.BadValsizeError: mdb_cursor_get: MDB_BAD_VALSIZE: Unsupported size of key/DB name/data, or wrong DUPFIXED size

LeonardoCarvalho (Thu, 21 Feb 2019 11:14:03 GMT):
oh right, on the addresses, not transactions ! Thanks, that worked!

LeonardoCarvalho (Thu, 21 Feb 2019 11:14:15 GMT):

Clipboard - February 21, 2019 8:14 AM

danintel (Thu, 21 Feb 2019 16:41:05 GMT):
@LeonardoCarvalho That gets it working, but for the long term, it would be better to have the addresses the transaction modifies. At the very least add the 6-hex character transaciton family prefix. If this is the `smallbank` TF I know about, the prefix is `332514`. Listing the inputs and outputs (or at least the prefix) allows parallelism and avoids errors from TPs accessing global state objects outside their address space or unexpected objects

LeonardoCarvalho (Sat, 23 Feb 2019 14:07:45 GMT):
@danintel you're right, but I don't know why, the Go TP isn't accepting the addresses, and the Rust TP isn't on the docker repo. The demo apparently got the "Whoa Factor" I expected to get, so this will be talked about in a future talk. :)

danintel (Sat, 23 Feb 2019 14:41:31 GMT):
Ok. Can you file a jira ticket for this with your. Souce code changes for your workaround?

LeonardoCarvalho (Sat, 23 Feb 2019 15:16:24 GMT):
sure!

agunde (Mon, 25 Feb 2019 14:13:47 GMT):
Rust SDK PR https://github.com/hyperledger/sawtooth-sdk-rust/pull/12 has been merged. It makes TransactionContext a Trait, switches methods to use references, fixes get_state to correctly return Vec<(address, data)> for multiple address. It also deprecates get_state in favor of get_state_entry (one address) and get_state_entries (multiple addresses). Remember if you do not which to update Rust TP to match master, as further breaking changes are planned, you can set `sawtooth-sdk = "0.2"` in your Cargo.toml file

eloafran (Tue, 26 Feb 2019 18:37:55 GMT):
Has joined the channel.

satelander (Tue, 26 Feb 2019 18:38:50 GMT):
Has joined the channel.

rbuysse (Wed, 27 Feb 2019 20:34:44 GMT):
FYI: the Python SDK has been moved out of core and into its own repo. https://github.com/hyperledger/sawtooth-sdk-python.

RealDeanZhao (Fri, 15 Mar 2019 05:52:45 GMT):
Has joined the channel.

rbuysse (Fri, 15 Mar 2019 20:57:54 GMT):
I merged a pull request (PR 3) on Tuesday into the sawtooth-sdk-python repository that changed the way the python3-sawtooth-signing module is packaged and this may have implications for applications built using the Python SDK. Going forward, python3-sawtooth-signing will no longer be available as a standalone package. The signing module will be included in the python3-sawtooth-sdk package. This change will not be backported, so if you're using the 1.1(bumper) branch, the section below does not apply to you. If you have any projects that depend on python3-sawtooth-signing, they should be updated to depend on python3-sawtooth-sdk instead. If you have projects that depend on both python3-sawtooth-sdk and python3-sawtooth-signing, the signing dependency should be removed, otherwise you may see errors like: dpkg: error processing archive /tmp/apt-dpkg-install-lhXvZy/155-python3-sawtooth-sdk_1.2.2~dev11-1_all.deb (--unpack): 00:08:51.811 trying to overwrite '/usr/lib/python3/dist-packages/sawtooth_signing/__init__.py', which is also in package python3-sawtooth-signing 1.2.2~dev5-1

danintel (Fri, 15 Mar 2019 23:37:03 GMT):
@rbuysse I got that annoying message and was wondering about it. Thanks.

rbuysse (Sat, 16 Mar 2019 14:43:00 GMT):
Sorry I I didn't get an email out sooner!

MatthewRubino (Wed, 03 Apr 2019 13:26:05 GMT):
Has left the channel.

kodonnel (Fri, 19 Apr 2019 17:28:11 GMT):
Has joined the channel.

kodonnel (Fri, 19 Apr 2019 19:01:24 GMT):
So I'm looking at putting a PR together to to expand out the checkstyle on sawtooth-java-sdk to the rest of that repository (it's not everywhere just yet). @Dan mentioned in @sawtooth-governance about google style, which works for me and is used in the examples poms already. Anyone have opinions about switching to those checks rather than our own checkstyle?

kodonnel (Fri, 19 Apr 2019 19:02:03 GMT):
I don't feel stongly about it other than there should be style checks on the whole project

amundson (Fri, 19 Apr 2019 19:03:20 GMT):
it used to be sun coding standards, which are subjectively better

kodonnel (Fri, 19 Apr 2019 19:03:56 GMT):
I said to @Dan as long as it is one true brace style I'm flexible.

kodonnel (Fri, 19 Apr 2019 19:04:25 GMT):
which sun and google are both

kodonnel (Fri, 19 Apr 2019 19:05:46 GMT):
there are some additional checks in the current sun style https://raw.githubusercontent.com/checkstyle/checkstyle/master/src/main/resources/sun_checks.xml

Dan (Fri, 19 Apr 2019 19:05:52 GMT):
is sun pretty actively maintaining that style?

amundson (Fri, 19 Apr 2019 19:06:06 GMT):
look

kodonnel (Fri, 19 Apr 2019 19:06:15 GMT):
last change Apro; 10,2019

amundson (Fri, 19 Apr 2019 19:06:19 GMT):
we can't have this checkstyle discussion every time there is a commit in the repo

Dan (Fri, 19 Apr 2019 19:06:34 GMT):
lol

amundson (Fri, 19 Apr 2019 19:06:49 GMT):
if you flip it back and forth, it makes a messy git history and it's not worth it

kodonnel (Fri, 19 Apr 2019 19:06:50 GMT):
My main concern is just getting it run against the main sdk, which it isn't currently, I assume that isn't controversial

amundson (Fri, 19 Apr 2019 19:07:02 GMT):
so we should pick whatever is the least amount of change to the current code IMO

kodonnel (Fri, 19 Apr 2019 19:07:04 GMT):
I'm fine with the current one too actually

Dan (Fri, 19 Apr 2019 19:07:31 GMT):
i don't think either of us care. i suggested google simply because i didn't see the checkstyle for sun was there

amundson (Fri, 19 Apr 2019 19:07:54 GMT):
I'd rather see the actual author in the git blame than whoever last got the checkstyle bug

Dan (Fri, 19 Apr 2019 19:07:58 GMT):
and because when the PR went up no lint checker caught stuff so it seemed like it was a gap in the process

amundson (Fri, 19 Apr 2019 19:08:56 GMT):
I'm not sure why that's not setup. Maybe a Jenkinsfile issue?

kodonnel (Fri, 19 Apr 2019 19:09:30 GMT):
no, jsut not in the transaction processor's jar's pom is all. not a big deal, but it caught me unawares

Dan (Fri, 19 Apr 2019 19:13:15 GMT):
@pschwarz I think you caught the PR betwixt rebases should just have the 2 commits now

kodonnel (Fri, 19 Apr 2019 19:14:52 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=BeWpaL9o5KTexR3KX) @Dan @pschwarz but I get what you mean about naming which I expected :)

Dan (Fri, 19 Apr 2019 19:15:20 GMT):
meaning the zmqcontext name?

kodonnel (Fri, 19 Apr 2019 19:15:32 GMT):
yeah

kodonnel (Fri, 19 Apr 2019 19:31:48 GMT):
Pulling convo with @amundson in here... Which sdk is roughly the gold standard? Happy to do some work synchronizing the java api up

kodonnel (Fri, 19 Apr 2019 19:32:34 GMT):
I'm guessing either rust or Python

pschwarz (Fri, 19 Apr 2019 19:48:25 GMT):
Rust and Python

pschwarz (Fri, 19 Apr 2019 19:49:12 GMT):
Though, the stream stuff in python is probably closer to the Java SDK right now

jsmitchell (Fri, 19 Apr 2019 19:59:03 GMT):
@pschwarz how about from a concurrency standpoint?

kodonnel (Fri, 19 Apr 2019 20:04:50 GMT):
I took a quick look through, and the main differences of the Java api are a)Context is missing equivalents of delete_state,add_receipt_data, and add_event and b) consensus unsurprisingly has no implementation

kodonnel (Fri, 19 Apr 2019 20:07:33 GMT):
Only other comment I would make is that the stream stuff clashes a bit with idiomatic Java.

kodonnel (Fri, 19 Apr 2019 20:07:52 GMT):
but I get why you'd want to keep the code pretty similar across SDK's

pschwarz (Fri, 19 Apr 2019 20:07:56 GMT):
They are about the same, concurrency-wise

kodonnel (Fri, 19 Apr 2019 20:08:39 GMT):
easy enough to implement those missing methods

pschwarz (Fri, 19 Apr 2019 20:09:02 GMT):
Right, it's not quite up-to-date context api-wise, as well as very easy to implement

kodonnel (Fri, 19 Apr 2019 20:09:43 GMT):
I'll take a swipe at it, unless there is some reason not to

jsmitchell (Fri, 19 Apr 2019 20:09:45 GMT):
oh, does the java sdk support parallel execution?

kodonnel (Fri, 19 Apr 2019 20:11:13 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=Hq4q7AAnEWigwzbpd) @jsmitchell @jsmitchell meant to ask about that actually, its a single threaded message loop at the moment. Didn't know whether that was on purpose or not

kodonnel (Fri, 19 Apr 2019 20:11:13 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=Hq4q7AAnEWigwzbpd) @jsmitchell meant to ask about that actually, its a single threaded message loop at the moment. Didn't know whether that was on purpose or not

jsmitchell (Fri, 19 Apr 2019 20:12:13 GMT):
this is what I was asking @pschwarz , @kodonnel

pschwarz (Fri, 19 Apr 2019 20:20:59 GMT):
No

jsmitchell (Fri, 19 Apr 2019 20:21:04 GMT):
@pschwarz is a wily foe

pschwarz (Fri, 19 Apr 2019 20:21:25 GMT):
It's the same as the Python SDK, concurrency-wise

jsmitchell (Fri, 19 Apr 2019 20:21:36 GMT):
and

pschwarz (Fri, 19 Apr 2019 20:21:38 GMT):
Currently

jsmitchell (Fri, 19 Apr 2019 20:22:14 GMT):
technically correct -- the best kind of correct

jsmitchell (Fri, 19 Apr 2019 20:22:46 GMT):
@pschwarz what sdk's should @kodonnel use as guidance regarding adding concurrency support to the Java SDK?

pschwarz (Fri, 19 Apr 2019 20:22:59 GMT):
The Go SDK

jsmitchell (Fri, 19 Apr 2019 20:23:14 GMT):
I know how much that hurt to type

pschwarz (Fri, 19 Apr 2019 20:23:46 GMT):
It supports the concurrency hints in the signup

pschwarz (Fri, 19 Apr 2019 20:24:06 GMT):
I think the java one could support this relatively easily

pschwarz (Fri, 19 Apr 2019 20:24:20 GMT):
The `Stream` class supports this

kodonnel (Fri, 19 Apr 2019 20:30:23 GMT):
took a quick look at the go, which is not my best by any means - but it looks roughly like what I would do with java8: A worker pool, and some queues for in and out.

kodonnel (Fri, 19 Apr 2019 20:30:44 GMT):
i'll add it to the to-do after the extra methods

LeonardoCarvalho (Fri, 19 Apr 2019 20:31:19 GMT):
@kodonnel please take a peek on my fork, there's some work with streams to parallelize the processing

kodonnel (Fri, 19 Apr 2019 20:32:22 GMT):
@LeonardoCarvalho sure, any particular branch?

kodonnel (Fri, 19 Apr 2019 20:32:59 GMT):
Ah I see. you've got Reactive in there

kodonnel (Fri, 19 Apr 2019 20:33:19 GMT):
which occurred to me as well - question for the room - are we sticking to any particular level of Java compliance?

LeonardoCarvalho (Fri, 19 Apr 2019 20:33:24 GMT):
there's 2, I couldn't evolve much in the last month, migrating a veeeeeeeeeeery old codebase from a big company from java 6 and 7 to 8...

LeonardoCarvalho (Fri, 19 Apr 2019 20:34:07 GMT):
I strongly suggest 11. It is spetacularly good for parallel processing

LeonardoCarvalho (Fri, 19 Apr 2019 20:34:23 GMT):
there's a profile for java 8 and other for java 11

kodonnel (Fri, 19 Apr 2019 20:35:02 GMT):
@LeonardoCarvalho when I get there, we'll talk :)

kodonnel (Fri, 19 Apr 2019 20:35:02 GMT):
@LeonardoCarvalho when I get to working on it, we'll talk :)

LeonardoCarvalho (Fri, 19 Apr 2019 20:36:09 GMT):
Be my guest. I will see if there's something missing a push on my local code tomorrow

LeonardoCarvalho (Fri, 19 Apr 2019 20:38:29 GMT):
by the way, I've requested a LinkedIn connection sooner today. ;)

pschwarz (Fri, 19 Apr 2019 20:39:10 GMT):
One thing to note with the Go SDK, is it uses ZMQ channels internally to communicate between threads, instead of the platform channels

pschwarz (Fri, 19 Apr 2019 20:39:51 GMT):
Java 8, so that we can keep Android support for the client-related API's

kodonnel (Fri, 19 Apr 2019 20:43:42 GMT):
Yeah saw that on the channels, any particular reason?

kodonnel (Fri, 19 Apr 2019 20:50:59 GMT):
The signing and the protos should definitely stay java8,. Maybe a little more debatable on the processor and consensus. Easier just to stick with java8 for now though

kodonnel (Thu, 25 Apr 2019 14:09:49 GMT):
So I'm probably going to dif in a bit more into the sawtooth-sdk-java this 2 week period. Looking at your stuff, there's a lot of changes there - most of which I generally agree with, but it will be difficult to get it all in in one go.

kodonnel (Thu, 25 Apr 2019 14:09:49 GMT):
@LeonardoCarvalho So I'm probably going to dif in a bit more into the sawtooth-sdk-java this 2 week period. Looking at your stuff, there's a lot of changes there - most of which I generally agree with, but it will be difficult to get it all in in one go.

kodonnel (Thu, 25 Apr 2019 14:11:48 GMT):
I suggest we take it in steps, using doing up some good unit testing stuff as the drive

DavidAEdwards (Thu, 25 Apr 2019 14:27:57 GMT):
Has joined the channel.

LeonardoCarvalho (Fri, 26 Apr 2019 10:55:35 GMT):
Sure !

LeonardoCarvalho (Fri, 26 Apr 2019 10:56:40 GMT):
I still need to find the time and energy to develop on the code base, should be some silly and one or another horrendous mistakes, but feel free to contact me with any questions!

kodonnel (Fri, 26 Apr 2019 16:50:39 GMT):
so pulling in a conversation with @pschwarz into here. We were talking about other gap areas of the java sdk. That last PR I did covers all of the Context/State related functionality, Next up on my list to take care of multithreading on the TP.

kodonnel (Fri, 26 Apr 2019 16:52:10 GMT):
The next obvious missing area of the Java SDK is the consensus API, looks like the rust implementation is fairly complete. Wouldn't be too hard to synch it up, but it warrants a good java based consensus to implement on top of it

kodonnel (Fri, 26 Apr 2019 16:52:54 GMT):
Other thing I noticed is that the CXX sdk is missing a few things along the lines of the Java SDK.

kodonnel (Fri, 26 Apr 2019 16:53:59 GMT):
looks like there are open pulls which bring CXX up to date though

kodonnel (Fri, 26 Apr 2019 16:55:18 GMT):
this one https://github.com/hyperledger/sawtooth-sdk-cxx/pull/12 at least adds the addEvent method

kodonnel (Fri, 26 Apr 2019 16:55:33 GMT):
needs just the transaction receipt method for completeness

Dan (Fri, 26 Apr 2019 18:09:32 GMT):
maybe message in consensus dev and see if there's anyone working on java

Dan (Fri, 26 Apr 2019 18:09:43 GMT):
if not I say don't bother with consensus

DavidAEdwards (Mon, 29 Apr 2019 07:12:59 GMT):
Isn't multi-threading essentially taken care of by creating multiple TP instances?

pschwarz (Mon, 29 Apr 2019 14:33:19 GMT):
That is one way to get some of the SDK's TP implementations to use multiple cores

pschwarz (Mon, 29 Apr 2019 14:34:03 GMT):
In some cases (like with the JVM) there's benefit to using the platforms threads to reduce memory usage

pschwarz (Mon, 29 Apr 2019 14:34:03 GMT):
In some cases (like with the JVM) there's benefit to using the platform's threads to reduce memory usage

DavidAEdwards (Mon, 29 Apr 2019 14:38:24 GMT):
Ahh I see. Good to know.

Dan (Tue, 30 Apr 2019 14:07:12 GMT):
@danintel any chance I can sign you up to create unit tests in the cxx sdk? :D

Dan (Wed, 01 May 2019 13:38:39 GMT):
Ok, danintel has his hands full with some other stuff. If anyone else would like to add a unit test framework that would be great. Google Test is the most predominant tooling right now. Catch might also be a good choice since our testing needs for the SDK are pretty simple. https://github.com/catchorg/Catch2 I have no experience with Catch though, so my preference would be Google Test.

kodonnel (Wed, 01 May 2019 17:23:40 GMT):
So regarding https://github.com/hyperledger/sawtooth-sdk-cxx/pull/14 - the discussion there has moved a bit beyond the CXX sdk I think. In particular exceptions across the SDKs. Apart from rust, the SDK's mostly overload the InvalidTransactionException and InternalError exceptions using them to mean errors in the Context as well. Rust has a clear semantic separation. Seems like the discussion on that pull suggests they all should follow that exception model in the rust-sdk. I agree actually, but I thought I'd ask the gang.

kodonnel (Wed, 01 May 2019 19:22:35 GMT):
``` So @pschwarz and I have been having a discussion about a specific commit in PR-23 of sawtooth-sdk-java, which adds threading support. https://github.com/hyperledger/sawtooth-sdk-java/pull/23/commits/a467a33029f338f751d8c36ca92325262290196c. In that commit, the addHandler method is interpreted as valid to call after the processor thread has started, and as a result the TP will reregister all of its handlers. There aren't any statements saying that is not ok anywhere that I am aware of, but the name addHandler suggests it is valid. That raised two questions which need to be answered: 1) _Is the validator idempotent with regard to registrations, i.e. if a TP sends multiple TP_REGISTER_REQUESTS for the same family, is that a problem?_ 2) _Should it be valid to addHandler after the processor has started? _If so, then perhaps the other SDK's should be updated similarly. If not, then I would suggest that the addHandler should throw an error, or other indication if called after start ```

kodonnel (Wed, 01 May 2019 19:22:35 GMT):
So @pschwarz and I have been having a discussion about a specific commit in PR-23 of sawtooth-sdk-java, which adds threading support. https://github.com/hyperledger/sawtooth-sdk-java/pull/23/commits/a467a33029f338f751d8c36ca92325262290196c. In that commit, the addHandler method is interpreted as valid to call after the processor thread has started, and as a result the TP will reregister all of its handlers. There aren't any statements saying that is not ok anywhere that I am aware of, but the name addHandler suggests it is valid. That raised two questions which need to be answered: 1) _Is the validator idempotent with regard to registrations, i.e. if a TP sends multiple TP_REGISTER_REQUESTS for the same family, is that a problem?_ 2) _Should it be valid to addHandler after the processor has started? _If so, then perhaps the other SDK's should be updated similarly. If not, then I would suggest that the addHandler should throw an error, or other indication if called after start

pschwarz (Wed, 01 May 2019 19:25:32 GMT):
Or, if the latter is "no", the processor should accept all handlers at creation time

pschwarz (Wed, 01 May 2019 19:25:50 GMT):
(across all SDK's)

kodonnel (Wed, 01 May 2019 20:13:09 GMT):
meaning drop the addHandler entirely in favor of a contstructor arg or similar?

pschwarz (Wed, 01 May 2019 20:33:52 GMT):
Right

LeonardoCarvalho (Wed, 01 May 2019 22:29:30 GMT):
round robin

LeonardoCarvalho (Wed, 01 May 2019 22:31:03 GMT):
I got this discussion some time ago... https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=sFLMKdag6EEMDeWwE

amundson (Fri, 03 May 2019 03:25:01 GMT):
@kodonnel correct behavior should be to only register the handler that is new. in other words, upon starting, register all the ones added before starting. after having started, only register the ones that are newly added.

amundson (Fri, 03 May 2019 03:27:50 GMT):
the SDK should not send duplicate register requests... I'm not sure the validator behavior, but it would seem like incorrect SDK behavior.

amundson (Fri, 03 May 2019 03:31:02 GMT):
re:addHandler vs. constructor - even if the constructor approach would have been better (not sure), not worth the breaking API change or inconsistencies between the SDKs

kodonnel (Fri, 03 May 2019 12:26:01 GMT):
@amundson OK. It will still be good to get a concrete answer about the behavior of the validator on re-register, even the SDK as it stands now potentially re-registers existing handlers under certain error conditions. Also - the behavior you describe is definitely not the behavior in the other SDK's since the rest don't support adding handlers after start at all - the call works, but it doesn't do anything

Dan (Fri, 03 May 2019 12:55:42 GMT):
what is the use case for adding a handler to an already running TP process?

kodonnel (Fri, 03 May 2019 13:16:43 GMT):
I have no use case in mind, but it is implied by having an addHandler on a thread - which doesn't throw an error if used after start.

kodonnel (Fri, 03 May 2019 13:17:48 GMT):
Thinking about it on the principle of "in an SDK if it looks like you should be able to do it, people will do it" also "folks do the darndest things"

Dan (Fri, 03 May 2019 13:18:34 GMT):
if this is the only SDK to have that feature, I'd say kill the feature. Unless someone knows why that's there?

kodonnel (Fri, 03 May 2019 13:19:07 GMT):
they all have some version of addHandler, and they all use a thread for the processor though.

kodonnel (Fri, 03 May 2019 13:19:36 GMT):
And if we kill it, that means either addHandler should really throw an error after start - or it should be a one time thing handled in constructor

kodonnel (Fri, 03 May 2019 13:20:20 GMT):
Shouldn't just be a no-op which only takes effect after a connection error - which is how the current java sdk and the rust one works

kodonnel (Fri, 03 May 2019 13:20:20 GMT):
Shouldn't just be a no-op which only takes effect after a connection error - which is how the current java sdk and the rust one (probably the others too, I haven't looked specifically) work,

DavidAEdwards (Fri, 03 May 2019 13:29:52 GMT):
Usually, if a method (such as addHandler) isn't supposed to be called, I would expect it to throw an IllegalStateException or similar. Or at least log an error. I'm not sure how much of that is actually the case, as I use the example as a template. ``` val transactionProcessor = TransactionProcessor(validator) transactionProcessor.addHandler(MyTransactionProcessor(publickey)) val thread = Thread(transactionProcessor) thread.start() ```

kodonnel (Fri, 03 May 2019 13:38:29 GMT):
@DavidAEdwards IllegalStateException - just what I was thinking, in the case of if we don't support it

amundson (Fri, 03 May 2019 14:12:02 GMT):
I think there are two likely reasons I did that design. One is so that you could monitor the filesystem and dynamically load handlers as they were added. (We used to have dynamic loading of python modules in 0.7.) The other is more historical, but it is possible this that TransactionProcessor was an abstract class initially.

amundson (Fri, 03 May 2019 14:13:07 GMT):
The dynamically loading handlers thing would actuallybe pretty cool in Java since it could scan for jar files that contained handlers.

amundson (Fri, 03 May 2019 14:13:07 GMT):
The dynamically loading handlers thing would actually be pretty cool in Java since it could scan for jar files that contained handlers.

LeonardoCarvalho (Fri, 03 May 2019 14:14:27 GMT):
I agree, using OSGI can be used to add more processing threads later on, for an example

amundson (Fri, 03 May 2019 14:16:10 GMT):
I think it should either be implemented to work properly or throw the IllegalStateException if not. I don't think we should deviate from the API because we can't change the API of all of the other SDKs because of backward compatibility concerns and we could leave room for it to be implemented in the future.

amundson (Fri, 03 May 2019 14:16:49 GMT):
Sounds like the Rust SDK is broken in this respect if it's silent.

kodonnel (Fri, 03 May 2019 14:21:07 GMT):
personally I like being able to add only the fly over time. But either way works, so long as it is consistent across

kodonnel (Fri, 03 May 2019 14:21:07 GMT):
personally I like being able to add on the fly over time. But either way works, so long as it is consistent across

amundson (Fri, 03 May 2019 14:21:31 GMT):
We've been discussing a related-ish topic of how to get Sabre contracts to be registered the same way as TPs so we can get rid of the Sabre wrapper in the transaction. We will probably solve this in Transact so it's Sawtooth 2.0-level stuff, and there are some issues that make it complex (per-schedule dispatching, dealing with dependencies, etc.)

amundson (Fri, 03 May 2019 14:24:57 GMT):
Compiled-in TPs are going to have first-order support in Transact (probably preferred over a separate process for a lot of use cases), and so the idea of dynamically adding handlers via dynamic linking may grow as a result.

amundson (Fri, 03 May 2019 14:28:15 GMT):
It's an interesting idea conceptually because if the Java TP can dynamically load, then you can consider that a general capability "run the Java TP to add Java handler support", which makes it more of a piece of sawtooth than a piece of an application.

amundson (Fri, 03 May 2019 14:28:33 GMT):
(We would really only need one TP for all Java handlers.)

LeonardoCarvalho (Fri, 03 May 2019 14:29:17 GMT):
My view for the Java SDK is exactly that

amundson (Fri, 03 May 2019 14:29:29 GMT):
That wouldn't necessarily be desirable for languages that could kill the entire TP process.

DavidAEdwards (Fri, 03 May 2019 14:43:27 GMT):
Speaking of the Java SDK, is this a valid way to enable a parallel processing? : ```kotlin val transactionProcessor = TransactionProcessor(validator) transactionProcessor.addHandler(SnowdenTransactionProcessor(publickey)) val executor = Executors.newFixedThreadPool(6) for(i in 1 .. 6) { executor.submit(transactionProcessor) } executor.shutdown() ```

DavidAEdwards (Fri, 03 May 2019 14:44:07 GMT):
Or must the TransactionProcessor object itself be created multiple times?

DavidAEdwards (Fri, 03 May 2019 14:44:41 GMT):
For example: ```kotlin val executor = Executors.newFixedThreadPool(6) for(i in 1 .. 6) { val transactionProcessor = TransactionProcessor(validator) transactionProcessor.addHandler(SnowdenTransactionProcessor(publickey)) executor.submit(transactionProcessor) } executor.shutdown() ```

DavidAEdwards (Fri, 03 May 2019 14:46:06 GMT):
Actually, nevermind. Silly question. It's the second one.

kodonnel (Fri, 03 May 2019 15:42:26 GMT):
@DavidAEdwards so, the second is better, but you will end up effectively reregistering the handler in that case, which - see the earlier conversation - isn't desirable. Also, it would be dependent on the handler implementation if it was acceptable to reuse it. The first one is definitely currently wrong, since there is a currentMessage field in v0.1.2 that isnt threadafe. See PR-23 for work being done on getting threading support in

kodonnel (Fri, 03 May 2019 15:46:39 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=RYqvrSF8jt2QeiWTq) @amundson That's pretty much how I interpreted the TransactionProcessor class's intent. You get into a bit of a slippery slope with expanding that functionality too much.

kodonnel (Fri, 03 May 2019 15:46:39 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=RYqvrSF8jt2QeiWTq) @amundson That's pretty much how I interpreted the TransactionProcessor class's intent. But you get into a bit of a slippery slope with expanding that functionality too much.

paul.sitoh (Fri, 10 May 2019 09:01:14 GMT):
Has joined the channel.

paul.sitoh (Fri, 10 May 2019 09:09:05 GMT):
Folks I was wondering if it might be useful to have the sdk codes (such as https://github.com/hyperledger/sawtooth-sdk-java and https://github.com/hyperledger/sawtooth-sdk-go) contains only SDK aspects and for example codes to be held in separate git repos. The example codes, could have a different governance -- requiring examples to include end-to-end -- and a governance that is more suitable for discussion related to application development as opposed to core level discussion. Application development has a very different concern from core. It's about delivering solution to provide business value (how user of apps would interact with each other without the need to be concerned with say protobufs.

paul.sitoh (Fri, 10 May 2019 09:17:12 GMT):
If you split the codes into different concerns it allows for reviews to be more focus.

paul.sitoh (Fri, 10 May 2019 09:18:26 GMT):
Plus it'll probably make the build process -- especially docker build -- for SDK much more focus (the Java SDK looks complex)

ascatox (Fri, 10 May 2019 09:23:13 GMT):
Has joined the channel.

BillBarnhill (Fri, 10 May 2019 11:26:07 GMT):
Has joined the channel.

VishalBatra (Sat, 11 May 2019 07:30:03 GMT):
Has joined the channel.

Nish (Mon, 13 May 2019 06:18:24 GMT):
Has joined the channel.

cheeky (Thu, 16 May 2019 15:08:03 GMT):
Has joined the channel.

wkatsak (Wed, 31 Jul 2019 15:13:49 GMT):
Hello everyone, some of you have been chatting with me occasionally about various Sawtooth issues. I work for a small startup called Taekion. We have been using Sawtooth as the basis for a bunch of our stuff, and in the course of that, we have developed a sort of "general purpose" client sdk/library for Golang.

wkatsak (Wed, 31 Jul 2019 15:15:56 GMT):
We've decided to open this up to the community in case anyone else might have use for it.

wkatsak (Wed, 31 Jul 2019 15:16:21 GMT):
The URL is https://github.com/taekion-org/sawtooth-client-sdk-go

wkatsak (Wed, 31 Jul 2019 15:17:35 GMT):
Essentially, this library takes care of all of the stuff related to transaction/batch creation/signing/submission, as well as checking status and waiting for batches.

wkatsak (Wed, 31 Jul 2019 15:18:12 GMT):
Additionally, we've abstracted the Sawtooth interface into a "Transport" layer. Our public GitHub has a single transport implementation, for the Sawtooth REST API.

wkatsak (Wed, 31 Jul 2019 15:19:00 GMT):
We have provided an implementation of an alternative intkey client library and cli that uses the SDK to show how it simplifies things.

wkatsak (Wed, 31 Jul 2019 15:22:16 GMT):
We are currently working on two extensions: a) Adding an API to register callbacks for events via the REST API (implemented using web sockets) b) An alternative transport implementation that skips the REST API and uses ZMQ to talk to the validator directly.

wkatsak (Wed, 31 Jul 2019 15:23:17 GMT):
@amundson I think I told you about this client sdk effort a while back.

wkatsak (Wed, 31 Jul 2019 15:29:17 GMT):
We would appreciate comments to gauge interest in something like this. We believe that this should help alleviate a lot of the pain involved in getting started with Sawtooth.

jamesbarry (Wed, 31 Jul 2019 16:26:05 GMT):
Has joined the channel.

amundson (Wed, 31 Jul 2019 16:28:21 GMT):
@wkatsak awesome.

amundson (Wed, 31 Jul 2019 16:37:03 GMT):
historically, we resisted writing client SDKs against the REST API because we were concerned about the amount of overhead in maintaining them. however, now that the APIs are more stable, I think we should change that approach and integrate client SDKs into our SDKs.

amundson (Wed, 31 Jul 2019 16:38:41 GMT):
another issue we need to consider is that there are multiple frameworks that we might use, depending on language, and what that means in terms of code/repo organization and dependencies introduced, etc.

wkatsak (Wed, 31 Jul 2019 16:38:53 GMT):
I had also thought that something like this more or less belongs in the individual language SDK packages.

wkatsak (Wed, 31 Jul 2019 16:39:17 GMT):
I’m also thinking that a ZMQ transport may need to be versioned.

wkatsak (Wed, 31 Jul 2019 16:39:40 GMT):
But, the abstraction we have put in should help with this.

amundson (Wed, 31 Jul 2019 16:39:47 GMT):
not any more versioned than the rest api, really.

amundson (Wed, 31 Jul 2019 16:40:30 GMT):
but, it would be nice to be able to have multiple backends for sure - REST API, 0MQ, eventually transact's direct TCP/SSL supported

amundson (Wed, 31 Jul 2019 16:41:15 GMT):
the pieces that don't include the REST API (batch/transaction building) could actually go to Hyperledger Transact as well

amundson (Wed, 31 Jul 2019 16:41:43 GMT):
especially Go, because we already know there is going to be a Go SDK for Transact

amundson (Wed, 31 Jul 2019 16:43:04 GMT):
@wkatsak you may find this interesting - https://github.com/hyperledger/transact/tree/master/libtransact/src/protocol/ -- specifically, transaction.rs and batch.rs

amundson (Wed, 31 Jul 2019 16:44:35 GMT):
we've been making heavy use of these and so far like the builder pattern. the reason we have gone down that path is that we don't want to expose the protobuf libraries to the users of the Transact library. we weren't careful enough about that within the existing Sawtooth SDKs.

amundson (Wed, 31 Jul 2019 16:45:32 GMT):
at some point, we will rewrite the sawtooth rust sdk to use the above

wkatsak (Wed, 31 Jul 2019 16:45:36 GMT):
@amundson Thanks! I’ll have a look. We are very open to any commentary about how to organize this, and we would really like to see something eventually merged.

amundson (Wed, 31 Jul 2019 16:46:44 GMT):
for the things that we should agree upon across all SDKs, we should write up RFCs explaining it for reference by all the SDK developers.

wkatsak (Wed, 31 Jul 2019 16:57:50 GMT):
Agree

arsulegai (Wed, 31 Jul 2019 17:03:36 GMT):
@wkatsak nice work

Michael8086 (Wed, 31 Jul 2019 17:53:04 GMT):
Has joined the channel.

wkatsak (Thu, 01 Aug 2019 07:07:25 GMT):
@arsulegai thanks!

wkatsak (Thu, 01 Aug 2019 07:16:46 GMT):
@amundson I also thought about exposing the protobufs to users of the library and opted to implement my own versions of the structs. For the REST API it was possible to directly map the fields from JSON, but for ZMQ I anticipated similar code to what you linked, to convert a protobuf into our structs.

amundson (Thu, 01 Aug 2019 21:30:24 GMT):
@wkatsak thoughts on the next step? do you want to contribute the batch/transaction building stuff to transact? the could jump-start that sdk.

wkatsak (Fri, 02 Aug 2019 05:21:05 GMT):
@amundson I think we are going to look at doing exactly that. Then, we will need to reconsider how the client SDK should be structured with respect to transaction building.

amundson (Fri, 02 Aug 2019 05:25:41 GMT):
ok, I will work on getting a repository setup for a transact go sdk then

wkatsak (Fri, 02 Aug 2019 05:29:21 GMT):
This will also solve the inconsistency between the updating and reading APIs. I guess we will have an official non-protobuf structure to represent each type (Block, Batch, Transaction, etc)

amundson (Fri, 02 Aug 2019 14:30:07 GMT):
@wkatsak yeah, exactly

LeonardoCarvalho (Thu, 22 Aug 2019 11:46:02 GMT):
Guys, while getting up to speed on my sdk development, I got an interesting thought/doubt

LeonardoCarvalho (Thu, 22 Aug 2019 11:47:29 GMT):
reading \href{https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture/transactions_and_batches.html#dependencies-and-input-output-addresses}{\the docs}

LeonardoCarvalho (Thu, 22 Aug 2019 11:47:40 GMT):
(damn)

LeonardoCarvalho (Thu, 22 Aug 2019 11:48:07 GMT):
I've unknowingly created a DoS on a particular address

LeonardoCarvalho (Thu, 22 Aug 2019 11:48:45 GMT):
because the deps got a wildcard, and I was submitting a lot of txs to other address

LeonardoCarvalho (Thu, 22 Aug 2019 11:48:59 GMT):
not related, but with the same prefix

LeonardoCarvalho (Thu, 22 Aug 2019 11:49:36 GMT):
how this kind of conflict is dealt in other SDKs?

LeonardoCarvalho (Thu, 22 Aug 2019 11:50:43 GMT):
and, related, how a TP is supposed to store the "waiting" queue ?

arsulegai (Thu, 22 Aug 2019 15:10:55 GMT):
The dependencies are handled in the validator. I didn't get your question

pschwarz (Thu, 22 Aug 2019 15:33:51 GMT):
There is a field in the TP registration message that gives a parallelism hint, based on how many transactions you can accept

pschwarz (Thu, 22 Aug 2019 15:34:16 GMT):
You could pipe your messages into an queue and supply backpressure that way

amundson (Thu, 22 Aug 2019 16:10:46 GMT):
@LeonardoCarvalho if you use a lot of wildcard inputs/outputs, it will reduce parallelism. so to that extent, the clients can decrease scheduler parallelism by bad behavior. not necessarily a big concern for permissioned networks, but there is a validator setting (don't recall the name) that can be used to further restrict state for specific TPs.

LeonardoCarvalho (Fri, 23 Aug 2019 10:35:36 GMT):
"The domain-specific Transaction Processor makes get(address) and set(address, data) calls against a version of state that the validator provides. get(address) returns the byte array found at that address and set(address, data) sets the byte array stored at that address. " I've found scenarios, on Integer TP for an example, where the _add_ operation is done on a not _set_ address, for an example. The TP asks for the address value, and fails. So, I've used the dependencies field on the TP, and would start applying some backpressure like @pschwarz suggested. But I think that I am lost in my interpretation of this two particular concepts..

LeonardoCarvalho (Fri, 23 Aug 2019 10:37:20 GMT):
Yeah, I was thinking to re-read the python code to get that better in my mind. But i think that the TP needs to verify the permissioning on the input, dependencies and output addresses being sent on the transaction, right ?

LeonardoCarvalho (Fri, 23 Aug 2019 10:38:03 GMT):
Oh, please note that for dependencies, I mean also inputs and outputs addresses on the transaction

LeonardoCarvalho (Fri, 23 Aug 2019 11:00:33 GMT):
Yeah, this is why I've asked about how to store it locally, I'm thinking about how to recover from some failure with a full queue.

LeonardoCarvalho (Wed, 25 Sep 2019 11:45:49 GMT):
hey guys, do we got a mock validator in any language?

Dan (Thu, 26 Sep 2019 07:31:13 GMT):
it's been a while since I've looked but I'm pretty sure the python SDK has some mocks. iirc it's not a super simple mock.

Dan (Thu, 26 Sep 2019 07:31:13 GMT):
it's been a while since I've looked but I'm pretty sure python has some mocks. iirc it's not a super simple mock.

Dan (Thu, 26 Sep 2019 07:34:56 GMT):
ok actually the sdk doesn't have a ton. looks like it's mostly around zmq. There's more in sawtooth-core `sawtooth-core/validator/tests` but maybe not what you are looking for.

LeonardoCarvalho (Thu, 26 Sep 2019 10:06:43 GMT):
Maybe I can create something using that as base, I've asked to avoid unnecessary rework or repeating simple mistakes.

danintel (Mon, 28 Oct 2019 15:57:17 GMT):
Has left the channel.

paul.sitoh (Wed, 30 Oct 2019 05:26:47 GMT):
Folks, I am getting this error on macOS ```In file included from ../../../../go/pkg/mod/github.com/hyperledger/sawtooth-sdk-go@v0.1.2/signing/pem_loader.go:23: ./../c/loader.c:22:10: fatal error: 'openssl/bio.h' file not found #include ```

paul.sitoh (Wed, 30 Oct 2019 05:26:47 GMT):
Folks, I am getting this error on macOS using the go sdk ```In file included from ../../../../go/pkg/mod/github.com/hyperledger/sawtooth-sdk-go@v0.1.2/signing/pem_loader.go:23: ./../c/loader.c:22:10: fatal error: 'openssl/bio.h' file not found #include ```

paul.sitoh (Wed, 30 Oct 2019 05:27:25 GMT):
I have set $CPPFLAGS to point to my brew installed openssl but still no lucj

paul.sitoh (Wed, 30 Oct 2019 05:27:25 GMT):
I have set $CPPFLAGS to point to my brew installed openssl but still no luck

paul.sitoh (Wed, 30 Oct 2019 05:27:25 GMT):
I have set $CPPFLAGS to point to my brew installed openssl but still no luck. Has anyone encountered similar problem?

paul.sitoh (Wed, 30 Oct 2019 05:27:25 GMT):
I have set $CPPFLAGS to point to my brew installed openssl but still no luck. Has anyone encountered similar problem? And has a solution to the problem?

paul.sitoh (Wed, 30 Oct 2019 17:09:39 GMT):
Is hyperledger sawtooth go sdk compatible with go 1.13 modules?

paul.sitoh (Wed, 04 Dec 2019 19:17:37 GMT):
Folks, I am in the process of helping fix/refactor the sawtooth-sdk-go. I have proposed some changes to the protos https://github.com/hyperledger/sawtooth-sdk-go/pull/41 but we also need a wider discussion name: ```Firstly, in terms of protos, please review if it is ok to go with the direction I have presented so far. Secondly, do we want to remove the c/c++ dependencies related to PEM file processing? Thirdly, do we want to work towards adopting this layout https://github.com/golang-standards/project-layout.```

paul.sitoh (Wed, 04 Dec 2019 19:18:57 GMT):
I am hoping to get feedback from the community for what they would like to have before I go further with proposing changes. Please feel free to suggest

paul.sitoh (Wed, 04 Dec 2019 19:18:57 GMT):
In terms of managing `protos`, I would have liked them to be centralised but it seemed there is no consensus on this. So it looks like we'll have to do with "copying-and-pasting" from sawtooth-core.

dplumb (Wed, 04 Dec 2019 22:18:15 GMT):
Haven't seen that openssl PEM file error, but I'm not sure if I've run that stuff on a Mac recently. Can you enumerate the steps to reproduce?

dplumb (Wed, 04 Dec 2019 22:20:45 GMT):
Also what happens when you run `brew doctor`? I wonder if there is some issue with your openssl installation

paul.sitoh (Thu, 05 Dec 2019 08:27:36 GMT):
You mean building the code?

paul.sitoh (Thu, 05 Dec 2019 08:29:25 GMT):
my `brew doctor` simply says brew is installed

paul.sitoh (Thu, 05 Dec 2019 08:30:28 GMT):
It is quite problematic building with mac as the openssl library on works with Linux so you can only build with docker container

paul.sitoh (Thu, 05 Dec 2019 08:31:11 GMT):
It is problematic only if you decide to build natively for multiple platforms.

paul.sitoh (Thu, 05 Dec 2019 08:33:24 GMT):
I am happy to find an alternative solution if there is a consensus for it.

paul.sitoh (Thu, 05 Dec 2019 08:34:26 GMT):
I guess the rationale for a cross-platform native app would be for anyone wanting to write their own cli or native apps connecting to validators.

wkatsak (Thu, 05 Dec 2019 17:53:27 GMT):
Hello everyone, as some of you might know, my company, Taekion, maintains a package (https://github.com/taekion-org/sawtooth-client-sdk-go) to make it easy to build a "client library" for your sawtooth app.

wkatsak (Thu, 05 Dec 2019 17:54:10 GMT):
The idea is that it lets you build a golang api around the sawtooth calls for doing commits and reads, and hides all of the transaction signing, serialization, and other messiness.

wkatsak (Thu, 05 Dec 2019 17:54:57 GMT):
Initially, this abstracted the REST API calls internally, so all you had to do was point it to an http address, and you were good to go.

wkatsak (Thu, 05 Dec 2019 17:55:45 GMT):
We have now pushed some patches that add a ZMQ transport alternative. So, your apps can now code to our client sdk, but when setting up the connection, you can choose to talk to sawtooth over either REST API, or directly to the validator with ZMQ.

wkatsak (Thu, 05 Dec 2019 17:56:32 GMT):
If there is any interest or questions, please reach out.

wkatsak (Thu, 05 Dec 2019 17:57:26 GMT):
I'm also working on the beginnings of a Go module for Transact, will factor out some of this functionality (the data and structure handling) into Transact itself, much like is done on the rust side

amundson (Thu, 05 Dec 2019 18:41:19 GMT):
@wkatsak any thoughts on adopting that project-layout for Transact's repo?

paul.sitoh (Fri, 06 Dec 2019 10:50:01 GMT):
@wkatsak are you planning to roll that project under Hyperledger umbrella?

wkatsak (Fri, 06 Dec 2019 13:37:35 GMT):
@amundson which layout?

wkatsak (Fri, 06 Dec 2019 13:38:26 GMT):
@paul.sitoh yes it would be our preference for our client SDK to be under hyperledger somehow. It should be quite possible to implement the same paradigm in each supported language as well.

amundson (Fri, 06 Dec 2019 13:38:29 GMT):
the one paul is suggesting above

wkatsak (Fri, 06 Dec 2019 13:39:04 GMT):
I will look closer and let you know

paul.sitoh (Fri, 06 Dec 2019 13:49:53 GMT):
@wkatsak good to know. Is there a reason it is not yet proposed to the community? Maybe it could replace the need to continue with sawtooth-sdk-go.

wkatsak (Fri, 06 Dec 2019 14:15:42 GMT):
Mostly because we are manpower limited. :)

wkatsak (Fri, 06 Dec 2019 14:16:02 GMT):
But, actually rather than replacing, I could see it becoming part of SDK-go

wkatsak (Fri, 06 Dec 2019 14:17:00 GMT):
SDK go gives the protos etc + ZMQ helpers and all the stuff for TPs

wkatsak (Fri, 06 Dec 2019 14:17:39 GMT):
This project leverages all of that just makes it much easier to build your client library.

wkatsak (Fri, 06 Dec 2019 14:18:01 GMT):
You can look at the intkey example in our package for an example of how simple it becomes.

amundson (Fri, 06 Dec 2019 16:05:06 GMT):
@wkatsak re:complexity - you might be interested in some of the 'simple smart contract' stuff we are doing in the sabre sdk - https://github.com/hyperledger/sawtooth-sabre/pull/90

paul.sitoh (Sun, 08 Dec 2019 08:54:51 GMT):
I am going to raise a topic for debate here. So I can get a sense of the directions to go with sawtooth SDK strategies. Let me start with a potentially controversial statement so people can shoot it down or support it or come up with a nuance response. The statement is: "Maybe we should let so call market forces decides on the shape of SDKs -- i.e. other languages can create they own outside Hyperledger but govern by protobuf and Hyperledger SDK strategy should only confined to supporting one official language binding".

paul.sitoh (Sun, 08 Dec 2019 08:54:51 GMT):
I am going to raise a topic for debate here. So I can get a sense of the directions to go with sawtooth SDK strategies. Let me start with a potentially controversial statement so people can shoot it down or support it or come up with a nuance response. The statement is: "Maybe we should let so call market forces decides on the shape of SDKs -- i.e. other languages can create they own outside Hyperledger but govern by a common protobuf and Hyperledger SDK strategy should only confined to supporting one official language binding".

paul.sitoh (Sun, 08 Dec 2019 08:58:13 GMT):
The reason I am asking is to get, for me personally, a sense of demand for "official" sawtooth-go-sdk and in the tradition of lean principles make sure stuff that I am volunteering to help build has demand. I am thinking in cases where there is specialised demand for a specific binding it might be better to have stuff done outside Hyperledger?

paul.sitoh (Sun, 08 Dec 2019 09:02:34 GMT):
What is the community views on this?

paul.sitoh (Sun, 08 Dec 2019 09:02:34 GMT):
What is the community's views on this?

arsulegai (Sun, 08 Dec 2019 14:01:35 GMT):
@paul.sitoh Perhaps collaborate with @wkatsak , the API builder paradigm he showed earlier was good.

arsulegai (Sun, 08 Dec 2019 14:17:59 GMT):
Regarding the SDKs, here are my views: one of the factor for the success of the project adoption is freedom for the developers to choose the language, ofcourse for quick prototyping. We can decide on top 2 or 3 languages for the feature releases along with the framework. The issue with "only" unofficially (outside Hyperledger) maintaining a SDK is that there's no binding on keeping it up to date, hard to get developers work on that. However, I don't see any issue maintaining an unofficial SDK version.

paul.sitoh (Sun, 08 Dec 2019 15:57:32 GMT):
The issue is not about collaborating. I could collaborate within the context of his repo outside Hyperledger or inside the Hyperledger umbrella.

arsulegai (Mon, 09 Dec 2019 03:43:20 GMT):
Sure, my comment was on that aspect

arsulegai (Mon, 09 Dec 2019 03:43:20 GMT):
Sure, my next comment was on that aspect

paul.sitoh (Mon, 09 Dec 2019 08:52:17 GMT):
The only thing that is common to any project interacting with SDK are the protobufs. I guess as long as anyone developing SDK or anything relies on protobuf to maintain compatibility.

paul.sitoh (Mon, 09 Dec 2019 08:53:31 GMT):
At the moment, the SDK appears to be primarily to support or hide the need for dev to deal directly with protobuf when creating custom TP

paul.sitoh (Mon, 09 Dec 2019 08:53:31 GMT):
At the moment, the SDK appears to be primarily to support or hide the need for dev to deal directly with protobuf when creating custom TP. Based on what I can tell.

paul.sitoh (Mon, 09 Dec 2019 09:02:59 GMT):
Maybe the "official" SDK should just focus on providing this capability?

jamesbarry (Mon, 09 Dec 2019 18:29:27 GMT):
@paul.sitoh I firmly believe you need to provide more than the protobuff layer for the official SDK. Merely transorting strucured data does not encourage use by larger companies who need to be involved int he project. After doing Open Source for 3 decades, I believe for a project to get legs you need to have a fully encapsulated version for use in multiple languages for easy first time/protoyping use. What happens if you tell corporate lawyers (I have gone through this at ADP & IBM) that you will use a project from one source, and a piece (in this case an SDK) from another source, you have a headache to be approved, even if its just your tech manager. Much better to get from a single source. So I would advote as @arsulegai that we should have the top 2-3 languages in the SDK. By the way I work with @wkatsak

amundson (Mon, 09 Dec 2019 19:50:07 GMT):
Long term (Sawtooth 2), we should consider deprecating the TP SDK portions in favor of Transact's SDKs for smart contract engines. Same for Batch/Transaction building. This leaves the Sawtooth SDKs to be more about client submission concerns (which Transact doesn't cover).

lawkim (Fri, 13 Dec 2019 03:05:33 GMT):
Has joined the channel.

paul.sitoh (Fri, 13 Dec 2019 08:43:27 GMT):
Apologies for not responding as I am still stuck on my day job duties. Will come back to address this at a later date

jamesbarry (Fri, 13 Dec 2019 17:39:50 GMT):
@amundson Is there a thread about thoughts around Sawtooth 2.0?

amundson (Fri, 13 Dec 2019 17:51:58 GMT):
best place to discuss it is #sawtooth-core-dev

jamesbarry (Fri, 13 Dec 2019 17:53:45 GMT):
@amundson Sounds good. I look forward to ideas around 2.0 emerging

arsulegai (Tue, 31 Dec 2019 21:21:56 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-sdk-dev?msg=L5npumj2ZJroda4fL) I understand the problem you're facing on Mac. I faced the same issue with the missing header file during build.

arsulegai (Tue, 31 Dec 2019 21:23:19 GMT):
Ideally letting the pkg-config handle finding the packages would work on any platform, makes it easy seamless.. I will look into the issue which @amundson mentioned and see if using pkg-config can be an option here.

arsulegai (Tue, 31 Dec 2019 21:25:00 GMT):
Alternatively, you may try as a workaround for now `export CGO_CPPFLAGS=-I/path/to/your/openssl/include` & export CGO_LDFLAGS=-L/path/to/your/openssl/lib` before the native build.

arsulegai (Tue, 31 Dec 2019 21:25:00 GMT):
Alternatively, you may try as a workaround for now `export CGO_CPPFLAGS=-I/path/to/your/openssl/include` & `export CGO_LDFLAGS=-L/path/to/your/openssl/lib` before the native build.

arsulegai (Tue, 31 Dec 2019 21:25:06 GMT):
It works!

amundson (Fri, 03 Jan 2020 17:54:50 GMT):
for those interested in sdk design, we are starting up a transact sdk for javascript and plan to use some of the things we learned doing the recent Rust sdk like using builder patterns for transaction/batch creation. watch for PRs here - https://github.com/hyperledger/transact-sdk-javascript

paul.sitoh (Tue, 14 Jan 2020 12:34:57 GMT):
Folks, still stuck on day job duties. Will look come back to this when done.

arsulegai (Tue, 14 Jan 2020 12:36:36 GMT):
Sure, try setting CGO env variables until then.. That unblocks using the Go SDK.. We will also discuss the protobuf file organization when you're available

LeonardoCarvalho (Tue, 04 Feb 2020 12:18:40 GMT):
@amundson my take on the Java SDK got wild, and I am thinking about publishing it as a related project, I think I will use this project as blueprint for me...

arsulegai (Tue, 04 Feb 2020 19:12:01 GMT):
@paul.sitoh how about continuing the pending PR in the Go SDK?

ltseeley (Tue, 11 Feb 2020 14:56:40 GMT):
I'd like to request a new Rust SDK release (v0.4.1) to make changes from https://github.com/hyperledger/sawtooth-sdk-rust/pull/39 and https://github.com/hyperledger/sawtooth-sdk-rust/pull/40 available

amundson (Tue, 11 Feb 2020 17:55:08 GMT):
@ltseeley can you move that request to #sawtooth-release?

rbuysse (Fri, 14 Feb 2020 19:59:02 GMT):
A new version (0.4.1) of the sawtooth-rust-sdk has been released. You can view the release notes at https://github.com/hyperledger/sawtooth-sdk-rust/blob/v0.4.1/RELEASE_NOTES.md

LeonardoCarvalho (Mon, 30 Mar 2020 11:55:17 GMT):
Hello everyone. I am getting a strange error on Rust Devmode, whenever I submit a batch, I got a correct response, my batch appears on http://localhost:8008/batch_statuses?id=... as pending

LeonardoCarvalho (Mon, 30 Mar 2020 11:55:32 GMT):
but I see a stack trace: st-devmode-engine-rust_1_2 | thread '' panicked at 'Unable to route new message: "SendError(..)"', src/libcore/result.rs:997:5 st-devmode-engine-rust_1_2 | stack backtrace: st-devmode-engine-rust_1_2 | 0: st-devmode-engine-rust_1_2 | 1: st-devmode-engine-rust_1_2 | 2:

LeonardoCarvalho (Mon, 30 Mar 2020 11:56:05 GMT):
and I am unable to submit any new batches. And, weirdly enough, my TP keeps answering the heartbeat with no issues

LeonardoCarvalho (Mon, 30 Mar 2020 11:56:16 GMT):
how can I trace this failure ?

arsulegai (Mon, 30 Mar 2020 13:35:23 GMT):
Any information from the validator service?

pschwarz (Mon, 30 Mar 2020 16:59:55 GMT):
Looks like devmode may have had an internal error of some kind - that failure is here: https://github.com/hyperledger/sawtooth-sdk-rust/blob/5e46e844d5c0615dfd05b3b885980c42e09c9a69/src/messaging/zmq_stream.rs#L185 which should only occur if the Receiver end has dropped

pschwarz (Mon, 30 Mar 2020 17:00:18 GMT):
Are there any other log messages before that panic?

pschwarz (Mon, 30 Mar 2020 17:00:55 GMT):
Your batch queue is probably filling up because you can't start or validate any new blocks

pschwarz (Mon, 30 Mar 2020 17:01:08 GMT):
hence, no new batch submission

LeonardoCarvalho (Tue, 31 Mar 2020 11:16:43 GMT):
nope, only the panic and a persistent state of failure

LeonardoCarvalho (Tue, 31 Mar 2020 11:17:11 GMT):
like, anytime I connect the TP, all messages different of PING gets stuck

LeonardoCarvalho (Tue, 31 Mar 2020 11:17:20 GMT):
I know have a hint of what may be wrong on the TP

LeonardoCarvalho (Tue, 31 Mar 2020 11:17:45 GMT):
but yet, this kind of failure can lead to some ugly instabilities

LeonardoCarvalho (Tue, 31 Mar 2020 11:18:40 GMT):
would be nice to get a way to verbose logging this kind of issues!

super-scrooge (Mon, 27 Apr 2020 11:39:38 GMT):
Has joined the channel.

jmbarry (Mon, 04 May 2020 18:18:21 GMT):
Has joined the channel.

rajesh_kumar_p (Thu, 04 Jun 2020 14:32:33 GMT):
Has joined the channel.

Will_Gluwa (Tue, 14 Jul 2020 23:31:46 GMT):
Has joined the channel.

Dan (Fri, 07 Aug 2020 15:32:28 GMT):
@KevinODonnell can you sanity check https://github.com/hyperledger/sawtooth-sdk-cxx/pull/20 ?

KevinODonnell (Fri, 07 Aug 2020 15:32:29 GMT):
Has joined the channel.

kodonnel (Fri, 07 Aug 2020 15:39:36 GMT):
that is odd... let me look a bit deeper

arsulegai (Fri, 07 Aug 2020 15:42:47 GMT):
I never faced this issue

kodonnel (Fri, 07 Aug 2020 15:43:16 GMT):
Nor us

Dan (Fri, 07 Aug 2020 15:44:55 GMT):
yeah I don't remember hearing anyone else run into it, but I can't discern how things work without this change. There's nothing I see on the sawtooth-core side that would separately read that message length, and when I spot checked the other SDKs I didn't see analogous message length param. .. I think I looked at the zmq api pages back when I reviewed this and didn't get why we had message length in there either.

arsulegai (Fri, 07 Aug 2020 15:46:00 GMT):
This is what I found about that method https://zeromq.github.io/zmqpp/classzmqpp_1_1message.html#adfaad230be5c3d3831b7d68aecc9783a

arsulegai (Fri, 07 Aug 2020 15:53:16 GMT):
Seems like the size is getting pushed to the part of the message that is sent https://github.com/zeromq/zmqpp/blob/3b613db0c285139563136cf7a9d4282ac1f2c5d6/src/zmqpp/message.hpp#L143

kodonnel (Fri, 07 Aug 2020 15:59:00 GMT):
So that error would only possible ever trigger on the send...

kodonnel (Fri, 07 Aug 2020 15:59:23 GMT):
but we literally use this sdk every day and have never seen this message

kodonnel (Fri, 07 Aug 2020 16:01:12 GMT):
I mean zmq supports this call pattern, so it should be fine. I am more curious about under what conditions it triggers the error, since we've not seen it.

kodonnel (Fri, 07 Aug 2020 16:02:54 GMT):
My concern is that this change actually just covers over a problem in the validator

arsulegai (Fri, 07 Aug 2020 16:03:31 GMT):
Here's the extraction of the error pointed there `too many values to unpack (expected 2)`

arsulegai (Fri, 07 Aug 2020 16:03:58 GMT):
Doesn't it mean it is expecting 2 values?

kodonnel (Fri, 07 Aug 2020 16:04:21 GMT):
yeah and presumably getting three

kodonnel (Fri, 07 Aug 2020 16:10:12 GMT):
based on the core side exception this is 1.1 at the latest

kodonnel (Fri, 07 Aug 2020 16:20:34 GMT):
wish I had a full stack trace from the validator side

arsulegai (Fri, 07 Aug 2020 16:42:21 GMT):
Right, I will try to block the PR and ask for the data which generated this

arsulegai (Fri, 07 Aug 2020 16:43:13 GMT):
Ok, it didn't consider my block.. (not a maintainer on this repo)

arsulegai (Fri, 07 Aug 2020 16:44:06 GMT):
BTW, thanks for the raw_txn_header feature check! Should have been done long back.

arsulegai (Fri, 07 Aug 2020 16:44:06 GMT):
BTW, thanks for the raw_txn_header feature check! Should have been done long back. Jan 2019 to Aug 2020 :)

LeonardoCarvalho (Sat, 08 Aug 2020 11:49:20 GMT):
@kodonnel I am working on a port of Netty + ZMTP of a abandomned project, and I think that is due to different protocol versions. The \href{https://rfc.zeromq.org/spec/23/}{\Spec} has some info on details.

LeonardoCarvalho (Sat, 08 Aug 2020 11:50:56 GMT):
zmtp protocol 3.0

kodonnel (Sat, 08 Aug 2020 15:07:15 GMT):
That's actually the direction I was headed with my digging around, something isn't matching up

Will_Gluwa (Sat, 08 Aug 2020 16:35:32 GMT):
I'll have our devs review the code and check that the protocol versions match. Thanks

wkatsak (Wed, 07 Oct 2020 20:37:38 GMT):
Hello, I’m having a look at the go sdk to see if I can do any modernization, particularly, i am considering converting to modern go module versioning

wkatsak (Wed, 07 Oct 2020 20:37:57 GMT):
I wanted to touch base, and see if there is any existing policy in place for protobuf versioning, etc.

wkatsak (Wed, 07 Oct 2020 20:38:25 GMT):
I’m wondering about the wisdom of having the protos live directly in the language specific sdk repos\

wkatsak (Wed, 07 Oct 2020 20:39:54 GMT):
Is anyone actively working on the go sdk right now?

amundson (Wed, 07 Oct 2020 22:23:27 GMT):
@wkatsak the protos are distributed across repos because it means we can update the protos (adding fields, renaming fields, whatever) without breaking all the repos -- updates need to be explicit and paired with updating the code that interacts with the auto-generated code. stated another way, the protos checked into each repo are the ones supported by that repo. and because of how protobuf versioning works its completely ok to get skew across the repos if the validator version started to change.

amundson (Wed, 07 Oct 2020 22:26:16 GMT):
it will be obvious how wise this strategy is when we start massively changing the definition of Transaction and Batch in backward-compatible ways and things continue to compile and work

amundson (Wed, 07 Oct 2020 22:26:37 GMT):
specifically, deprecating all the string fields that should have been bytes

amundson (Wed, 07 Oct 2020 22:33:57 GMT):
it might be a good starting place to update the structure of https://github.com/hyperledger/transact-sdk-go first, then use Transaction and Batch from there

wkatsak (Wed, 07 Oct 2020 22:53:22 GMT):
@amundson Thanks! I’ll have a look.

wkatsak (Fri, 09 Oct 2020 17:56:32 GMT):
@amundson I have an observation about the generated go code for the sdk.

wkatsak (Fri, 09 Oct 2020 17:56:53 GMT):
As far as I can tell, you can’t use the sdk without doing the ‘go generate’ phase

wkatsak (Fri, 09 Oct 2020 17:58:58 GMT):
I looked at the docs for best practices with protobufs

wkatsak (Fri, 09 Oct 2020 17:59:25 GMT):
And it seems that this phase should only be done by a dev that updates protos

wkatsak (Fri, 09 Oct 2020 17:59:40 GMT):
And the resulting generated code should be committed

amundson (Fri, 09 Oct 2020 18:07:34 GMT):
@wkatsak the intent was certainly to commit them - https://github.com/hyperledger/sawtooth-sdk-go/pull/38

wkatsak (Fri, 09 Oct 2020 18:11:27 GMT):
Ok, thanks. I do see this now. Can you give some insight on the logic for “hiding” the protobuf compiled apis from the SDK “user”?

wkatsak (Fri, 09 Oct 2020 18:14:49 GMT):
Certainly, at the very least, processor_pb2 is necessary to access from every go-implemented TP

wkatsak (Fri, 09 Oct 2020 18:15:12 GMT):
Due to being used in the Apply() method signature

wkatsak (Fri, 09 Oct 2020 20:01:22 GMT):
@amundson Is there some formal policy regarding concealing the protobuf APIs from the SDK users?

amundson (Tue, 13 Oct 2020 14:08:13 GMT):
not formal as written up, but overall we've been avoiding exposing any dependency (protobuf, whatever) in library APIs for new things

erivlis (Wed, 13 Jan 2021 00:29:22 GMT):
Has joined the channel.

LeonardoCarvalho (Thu, 04 Mar 2021 11:41:29 GMT):
hello all, is there a sequence diagram for the 0MQ and Gossip messages operations somewhere?

amundson (Thu, 04 Mar 2021 19:10:26 GMT):
I possibly have some, but the designs are old enough at this point I might have a hard time digging it up

wkatsak (Wed, 10 Mar 2021 20:43:12 GMT):
Hello, I've finally come back to fixing up the `sawtooth-sdk-go` package

wkatsak (Wed, 10 Mar 2021 20:43:30 GMT):
@amundson, we had some discussion on this a while back

wkatsak (Wed, 10 Mar 2021 20:44:38 GMT):
I have some questions before I submit a pull requests

wkatsak (Wed, 10 Mar 2021 20:44:38 GMT):
I have some questions before I submit a pull request

wkatsak (Wed, 10 Mar 2021 20:45:21 GMT):
There is a significant difference between `master` and `v0.1.3`

wkatsak (Wed, 10 Mar 2021 20:45:51 GMT):
@rberg2 moved the compiled protobufs to `src/protobuf` after `v0.1.3` was cut

wkatsak (Wed, 10 Mar 2021 20:46:23 GMT):
So, any code that referred to `github.com/hyperledger/sawtooth-sdk-go/protobufs` is broken against `master`

wkatsak (Wed, 10 Mar 2021 20:46:23 GMT):
So, any code that referred to `github.com/hyperledger/sawtooth-sdk-go/protobuf` is broken against `master`

wkatsak (Wed, 10 Mar 2021 20:47:06 GMT):
Also, the `go generate` scripts still generate the protobufs in `protobuf` instead of `src/protobuf`

wkatsak (Wed, 10 Mar 2021 20:48:58 GMT):
And all of this breaks go modules pretty soundly

wkatsak (Wed, 10 Mar 2021 20:49:56 GMT):
I've done a set of patches that fixes `go generate` to generate the protobufs in `src/protobuf`

wkatsak (Wed, 10 Mar 2021 20:50:05 GMT):
and replaces all relative imports with absolute imports

wkatsak (Wed, 10 Mar 2021 20:50:22 GMT):
tests run, i've successfully generated and commited a `go.mod`

wkatsak (Wed, 10 Mar 2021 20:50:34 GMT):
The only thing im concerned about is the path change of protobuf

wkatsak (Wed, 10 Mar 2021 20:51:07 GMT):
I and everyone else who linked against it seems to have to change their code now. Was this the intention @rberg2 ?

rberg2 (Wed, 10 Mar 2021 20:53:25 GMT):
no I did not intend to make people change their code

wkatsak (Wed, 10 Mar 2021 20:53:54 GMT):
I was also not clear if we expect users to run `go generate` before using the library

wkatsak (Wed, 10 Mar 2021 20:54:08 GMT):
or if they should use the commiteed compiled protobufs

wkatsak (Wed, 10 Mar 2021 20:54:08 GMT):
or if they should use the committed compiled protobufs

rberg2 (Wed, 10 Mar 2021 20:55:07 GMT):
There were discussions about that and if I remember correctly it was decided we did not want to commit the generated code to the repo making the `go generate` necessary

wkatsak (Wed, 10 Mar 2021 20:56:12 GMT):
I saw this discussion https://github.com/hyperledger/sawtooth-sdk-go/pull/38

wkatsak (Wed, 10 Mar 2021 20:57:21 GMT):
I thought it concluded with having the generated committed

wkatsak (Wed, 10 Mar 2021 20:57:21 GMT):
I thought it concluded with having the generated code committed

wkatsak (Wed, 10 Mar 2021 20:57:29 GMT):
and indeed, the code exists in several branches

wkatsak (Wed, 10 Mar 2021 21:00:22 GMT):
Also, strangely, the `gen.sh` script updates the protobufs generated to use full paths to refer to each other

wkatsak (Wed, 10 Mar 2021 21:00:28 GMT):
and the committed versions DONT have this

wkatsak (Wed, 10 Mar 2021 21:00:43 GMT):
ive always had to `go generate` even with `v0.1.3`

wkatsak (Wed, 10 Mar 2021 21:01:20 GMT):
I can and will produce patches to fix whatever, I just want to make sure what I am doing is reasonable.

wkatsak (Wed, 10 Mar 2021 21:32:00 GMT):
I'm guessing that you moved them into `src` in order to have them statically available for something, maybe tests?

wkatsak (Wed, 10 Mar 2021 21:32:12 GMT):
and `go generate` created a new set in `protobuf`

wkatsak (Wed, 10 Mar 2021 21:32:16 GMT):
so no one noticed

wkatsak (Wed, 10 Mar 2021 21:32:58 GMT):
now, `go mod` doesn't have a nice time with them

wkatsak (Wed, 10 Mar 2021 22:33:56 GMT):
@rberg2 what if, we keep the semantic where people need to use `go generate` before they use the library

wkatsak (Wed, 10 Mar 2021 22:34:13 GMT):
and move the pre-generated ones into a `vendor` directory

wkatsak (Wed, 10 Mar 2021 22:34:23 GMT):
this might fix the issues with `go mod`

wkatsak (Wed, 10 Mar 2021 22:35:01 GMT):
This might be an abuse of vendoring

wkatsak (Wed, 10 Mar 2021 22:35:05 GMT):
but it could world

wkatsak (Wed, 10 Mar 2021 22:35:05 GMT):
but it could work

wkatsak (Wed, 10 Mar 2021 22:42:01 GMT):
I am basing this on the assumption that you need pre-generated ones for some reason (tests?)

rberg2 (Wed, 10 Mar 2021 22:42:18 GMT):
@wkatsak It seems like the best thing to do is put up the PR so the rest of the team can discuss.

wkatsak (Wed, 10 Mar 2021 22:42:35 GMT):
Ok, sure, I am ok with that

wkatsak (Wed, 10 Mar 2021 22:42:47 GMT):
I am very hesitant to keep the `src/protobuf` though

wkatsak (Wed, 10 Mar 2021 22:42:58 GMT):
I would rather propose that we go back to having them in root

rberg2 (Wed, 10 Mar 2021 22:43:37 GMT):
kk. Sorry about that I have been working on another project so I am not the very up to date with whats going on with the sdks

wkatsak (Wed, 10 Mar 2021 22:43:37 GMT):
I guess what i am asking is if you care

wkatsak (Wed, 10 Mar 2021 22:43:47 GMT):
since you are the one who moved it into `src`

amundson (Wed, 10 Mar 2021 23:54:51 GMT):
@wkatsak likely you will not get many objections to fixing the Go sdk stuff, so you should use your best judgement about what makes it more natural for Go developers and do that

wkatsak (Thu, 11 Mar 2021 00:15:07 GMT):
@amundson Roger. Thanks!

wkatsak (Thu, 11 Mar 2021 15:46:58 GMT):
@rberg2 @amundson I've created a PR for the go sdk. https://github.com/hyperledger/sawtooth-sdk-go/pull/43

wkatsak (Thu, 11 Mar 2021 15:47:10 GMT):
@jmbarry

pschwarz (Thu, 11 Mar 2021 17:48:21 GMT):
@wkatsak looks like you have some lint on that PR

wkatsak (Thu, 11 Mar 2021 19:07:58 GMT):
@pschwarz Thanks, I'll revise.

wkatsak (Fri, 12 Mar 2021 14:35:04 GMT):
@amundson Thanks for merging the PR. Can you create a new tag `v0.1.4`?

wkatsak (Fri, 12 Mar 2021 14:35:15 GMT):
This is important for go modules to pick this up as the current

rbuysse (Fri, 12 Mar 2021 16:19:00 GMT):
@wkatsak Thanks a ton for fixing things up! I'll tag the repo this afternoon!

wkatsak (Fri, 12 Mar 2021 19:07:10 GMT):
@rbuysse No problem. This has been a thorn in my side for a while as this library links into just about everything we have. No more local patched copy!

rbuysse (Mon, 15 Mar 2021 18:31:23 GMT):
@wkatsak ok, the repo's tagged. sorry that took a little longer than I though.

rbuysse (Mon, 15 Mar 2021 18:31:23 GMT):
@wkatsak ok, the repo's tagged. sorry that took a little longer than I thought.

wkatsak (Tue, 16 Mar 2021 01:00:32 GMT):
@rbuysse Thanks!

rafaelmelo (Tue, 01 Jun 2021 12:50:57 GMT):
Has joined the channel.

pushkarb (Thu, 10 Jun 2021 12:15:12 GMT):
Has joined the channel.

pushkarb (Fri, 11 Jun 2021 11:09:49 GMT):
Hello everyone, I need some help. I am trying to make changes to the intkey transaction family. I have cloned the sawtooth python sdk. The problem I am facing is that if I make changes to the intkey code present in ``\sawtooth-sdk-python\sawtooth-sdk-python-main\examples\intkey_python\sawtooth_intkey\client_cli``, the changes aren't reflecting in the binaries that I am building using docker. What am I missing?

LeonardoCarvalho (Fri, 02 Jul 2021 11:06:07 GMT):
Hello everyone. I am trying to get back to help developing the Java SDK and create some AWS assets as well, but I would need to be professionally engaged. Is there anyone that can indicate me for a position to make this possible ?

pschwarz (Tue, 01 Feb 2022 16:51:35 GMT):
We will be publishing a release of sawtooth-sdk-rust soon (https://github.com/hyperledger/sawtooth-sdk-rust/pull/77) It is a patch release with updated dependencies.

rjones (Wed, 23 Mar 2022 17:36:01 GMT):