----- Today January 23rd, 2017 -----

weeds [06:32] A few people are meeting to talk about the status
               of the Master code base.  I am slacking the information as a
               result- this is real time discussion 

      [06:35]  There are multiple lists on the board-- these are
               all the stuff we want to walk through and determine where we are
               specifically-- TLS, validation message and TX, replay attacks,
               replication MSPs for gossip, anchor peers, channel leaders, HSM
               (key generation), chaincode return object, chaincode endorsement
               policy, revisit events, chaincode life-cycle (deploy/init
               upgrade,.. and policy), ERror handling, bootstrap with
               pre-defined channels, custom TX, CLI accepts multiple peers,
               application crypto library, system Chaincode refactor (location)
               and Chaincode calling chaincode 

      [06:36]  For SDK- (node.js, and Java)- Java only : create
               "official"branch, events support (example: rejection in
               blockchain), chain  join ( creation basically done), REST
               wrapper, anything left in MSP, Java Chaincode, TCERt private key
               derivation, query on ledger

      [06:38]  For SDK- add RSA , escc, vscc

      [06:40]  For Docs- high level overview- ferris; technical
               overview- Josh; remove version 0.6 material; docker compose- 3
               configs; ordering configs, CA configs- Keith ; APIs- Jz, SDK- JZ,
               policies- Murali; channels- murali

      [06:40]  For Docs- end to end Barry/Ramesh

      [06:42]  For Fabric - CA: Docs- API doc /swagger; readme;
               read the docs,... CLI simplification; TCERt- BCCSP integration/.
               option 2 (HSM friendly) support; HSM support- BCCSP or lets
               ecnrypt PrSCH; BCCSP for auth. header; Intermediate CA support? ;
               Test

      [06:42]  For BDD- RSA, P384, Deploy CC, Mutlichannel

      [06:42]  That is what is currently on the board...

      [06:43]  Binh- let's quickly review this list and anything
               else we can add on, but these are the items that we want to
               target for alpha for the end of this month

      [06:43]  (items are being added that I will try to add
               here)

      [06:44]  For Doc- Couddb/ledger- Dave

      [06:46]  For Ledger- finish couch Miscellaneous items
               (versioning, deletes); Query expose to application chaincode;
               history of key values(level db) - add to QSCC, expose to
               application chaincode; Chaincode examples- table replacement,
               query, history

      [06:46]  for DOC- Gossary of terms- Nick, SCC- Murali

      [06:47]  ----------------------here is where discussion has
               started-------------------------------------------

      [06:48]  To original list- experation of MSP certs

      [06:50]  what else on the list before we go through? (binh
               asked)

      [06:50]  Gari suggesting we go through first pass and
               eliminating pieces we should not go after

      [06:51]  let's do the list starting with TLS first and then
               Ledger, then SDK, fabric CA and whatever we decide will effect
               the docs

      [06:51]  TLS- the server side works and you can dynamically
               add certificates to it incrementally and that's all checked
               in---- Under BDD we added TLS

      [06:52]  Validation of messages and transactions- this is
               Ale's items, this is almost done

      [06:54]  Replay Attacks- Angelo indicated what we have
               committers check the transaction id is duplicated- only the
               committers, but we have to generate the transaction id, which we
               don't- so we had long discussion.. we agreed to generate a nonce
               and generate with creater's id and hash that.. that part is
               important. whether we can create the replay attacks or not may
               not be completed

      [06:55]  The discussion we had with murali is what if
               legacy software is using for application related- so generating
               for nonce of creator might not be accepted.

      [06:58]  Today- we need to solve replay attacks and mine
               the transaction id to the identity of the creator.  We need to
               use the TX-ID generator- this is equal to the creator plus the
               nonce.. this has to be done prior to preventing replay.. SDK is
               already generating a transaction id,.. but it's not done in the
               way that is highlighted here.  There as to be an adapter into a
               question- some event comes out- you call api and you can map the
               transaction id.. if you want to track it- pass it in as a
               parameter.   The question is for doing it- if we are going to be
               consistent on the SDKs and you agree and creator + nonce- it's
               not a hard piece of work. are we going to do it or not?  We do
               generate an ID today... the id is nonce so we have creator

      [06:59]  we will not do this for end of the month on
               transactionj id generator- creator + nonce

      [07:00]  Replication MSPs for gossip- basically we
               formatted a final document at end of last week, we need to close
               some edgers, but if enough time to talk with Elli, I will like
               Gari/Binh to review and after that- we can finish this out

      [07:02]  Anchor peers- upon channel creation, anchor is
               there, and we checked manually it works.  I hav enot seen code
               that deels with configuration of stuff in peer when new
               configuration blocks comes from ordering service. and the
               adjacent manager config transaction is not in the peer.  Jeff
               added that yesterday in BDD... he added the anchor peers in BDD.
               BUT we don't have a configuration handler on the peer side-
               without that, we can not deal with the configurations that are
               not associated with channel creation..... We also need to do
               extra work in the peer.   We need to combine jeff's work.

      [07:03]  Board changes- Anchor config block with handler;
               BDD

      [07:03]  Channel Leader- basically the code that elects the
               leader is inside and has been merged since beginning of last
               week. the only thing missing is plugging into gossip.  I have a
               chainset that I need to code review for this

      [07:04]  HSM (key generation)- Vlad said we need on key
               derivation... our proposal is to remove this from end of January.

ashutoshkumar [07:05] last sentence is not clear.

weeds [07:07] Chaincode Rerturn Object- We have a merge conflict
               and Murali is checking it right now.. we need to leave this here,
               but it's pretty close . WE are returning an object from protos
               that we effined a long time ago- now we are returning an object
               that we are returning code where we use HTTP return status code
               where 100's 200's 500's and a message in there and a payload
               (which is a byte array).  This gives more flexibility for
               chaincode to return what is needed.  If you ask me to endorse
               something and I need to kick off a workflow- I will return code
               saying incomplete,etc,.. ; SDK list is being updated

      [07:07]  SDK: added Update CC return object

      [07:08]  @ashutoshkumar we are making decisions on what we
               are going to get done for end of January for our Alpha/Beta code-
               we will not try to tackle completing the HSM work is the net.
               Clearly if open source team has it complete- we can relook at the
               decision, but we're trying to make sure we prioritize as we want
               to get very clean Docker images and compose scripts for members
               of the community who want to program and play with version 1.0

      [07:08]  I'm currently taking notes on the discussions here
               on what we should focus on among several people in community

      [07:09]  (not everyone is attending, so we are going to be
               looking for feedback to go to @binhn  .. this is a first cut
               proposal)

ashutoshkumar [07:09] thanks @weeds

weeds [07:12] We need to add some additional work on chaincode
               return object- the remaining work after we merge this latest
               piece is to take the work Jim has done and completing it writing
               it down to the ledger.  Why would you write the response down to
               the ledger?  Not in the state base, but we would write in the
               transaction, so we can record the response code.  We store events
               from chaincode into the ledger- so the worry was that we are
               getting all tehse responses and we are not saving it or
               persisting it.   So it's not in the signed part of the block?
               The events are not in signed part of the block- yes they are in
               signed part of the block.  Is it important to persist this
               information?  If it's part of transaction and app is using it to
               make decisions, then it seems like it is important.  In the query
               - we never send that so it really does not matter there.  So if
               transaction id- what was the response?  that one piece of
               information- we store everything in transaction, that could be
               important for auditing like chaincode events... Added
               "Transaction proto should contain repsonse"

      [07:14]  Chaincode endorsement policy: what kind of
               policies are we going to provide?  My understanding is that you
               can specify bv VSCC in lifecycle chaincode- if you give complex
               policies- code validating is there... the code in CLI/SDK is
               not... you send request, at time of commitment, the code is there
               to query the lifecycle chaincode and to validate that all the
               people are signing off.  Are we using same policy that we are in
               protos?  We use one policy specification that Jason defined.
               When we complete whatever work in runtime and by specifying in
               SDK and SLI- that doe effect the SDK which we titled ESCC/VSDD..
               When you do specify it, you have to serailze it into Jason's
               format.  We should do this by Alpha.

      [07:15]  We need to check back with Ale  on this

      [07:17]  Revisit Events- this is from Pat (community
               member).  we need to do events from chain channels and hook it up
               for channels and hook it up with MSP.  So we added Revisit events
               (channel &MSP) We should add security restriction because he's
               not authorized.. depends on how far we want to go.  We need to
               confirm with Pat. @pmullaney  We need to check with Pat and
               verify with him if we need to specify any additional policy or we
               use policy from the channel. The easiset thing is if we have read
               permission on channel, you get events.  Based on my experience on
               how fast it works- the best we can hope for- backend he has
               chaincode and block events.. and he's working on SDK.  i don't
               know if he can get the rejection events in and support for SDK.
               WE don't need rejection events.  In 0.6 we had this- because
               invalid transactoins were not part of block- but now they are
               part of block and we have bit array that marks invalid
               transactions

      [07:18]  We do need to add the channel ID-- we don't think
               we will be able to do any security on revisit events in 8 days

      [07:18]  You have block come in- list of transaction. if
               they fail in MVCC/VSCC,.. we still add a bit aray filter that
               points to location of which ones were invalid.  Basically means
               that we did not process a state change

      [07:19]  We do have ability to check for false/invalid
               transactions.  that is always just there

      [07:19]  Do chaincode events get set for invalid
               transactions? Murali says today it is.. we should probably
               revisit this.

      [07:20]  He builds in handler, the api that does it-- on
               the orderer side- it has to have the exact same logic of whether
               you are on channel or not.. and it will process signature from
               MSP list.  When Jason/Kostas gets that code and we can take the
               handler code and use it for the events.  Jason and Kostas and
               that team will be able to probably do that faster for Pat

      [07:20]  to utilize

      [07:22]  Jim Zhang said we need to filter out the events
               for invalid transactions otherwise it may be really confusing...
               it is absolutely possible. the simplest way is that fabric won't
               send chaincode events. block has chaincode events. and SDK will
               do the parsing. SDK is already doing that today. events by
               transaction ids.. so you move that , Basically Jim will have to
               map for transaction id- you find out what #numberit was in the
               ordere and you check in bit array.

      [07:22]  We  need to do post processing on the SDK

      [07:23]  Do we have a size limit? i know we have number of
               transactions, but do we have a size limit-- we have preferred max
               bytes and max bytes.  it's 512K that's the preferred. I know it's
               north of 7 Megabytes... we need to revisit the block payload
               because it travels through the events like that. Pat is actually
               filtering out the deploy transaction and removing that and does
               not touch the other stuff yet and we need to make sure he's
               aware. I would prefer only transaction ids and events, but then
               they have to go back due to security.

      [07:25]  Chaincode lifecycle- do we want to redo the
               deployment and upgrade?  We need to make a decision on this today
               or tomorrow. the policy is done- Kostas said he needs to ask
               Jason . this is chaincode policy who can deploy and manipulate
               the lifecycle when creating the channel .   It is the deployment
               of the chaincode- who can deploy chaincode on the channel? We
               have some control on who can deploy and upgrade on the chaincode?

      [07:27]  There is a proposal on how we deploy chaincode-
               and we need to decide.  There are two parts of it,.. so we are
               highlighting chaincode life-cycle as a quesiton mark.

      [07:28]  Error handling- we have the base, but everyone
               needs to use this.  The base - we have code at the right place to
               encapsulate the stack trace.. if there is an error- and that
               error code indicates the components .. so you know this is
               chaincode error, or this is peer error, or this is orderer. The
               framework is done but not all components has used it.  Peer has
               done some of this. - define error codes for component

      [07:29]  Error handling is going to happen from now until
               GA honestly

      [07:29]  (GA is a relative word here,.. but it's when the
               fabric is stabilized for production use, which is dependent on
               quality work being completed)

      [07:33]  Bootstrap with predefined channel-- We have
               hardcoded in our code that we start up with a channel,.. but I'd
               rather do that as configuraiton out of the code. if we specify
               the configuration and we start it up with a configuration versus
               bake it into the code. In other words you don't create cli or
               SDK... you look at config- they need channel test id to start up
               and then we create it. rather than we have it in the code.  This
               assumes that we have ability in orderer and predefine in channel
               and genesis block and use with the peer.  We have to have block
               from orderer.  The orderer has to start the config block and they
               need to know members.. We just need to have a default thing that
               people start with.  This whole process is security based.. we
               haven't configured the orderers MSPs properly. . In our code we
               automatically create test channel-- that is the point. If that
               needs to go, we need to startup with channel for programming. We
               need to come up with dev mode kind of thing..  Easy to say create
               channel in peer, but I also need channel in orderer.  This is
               where the complication is.  The current feature will bootstrap
               system in 4 seconds. having a test id channel- the user test - i
               would just get rid of everything and it confuses everything.  We
               need to come up with a way- a nice simple way in the
               bootstrapping feature scenario how we have a system come up for
               people that is working,.. and we can do that.

      [07:34]  BDD has a lot of this

weeds [07:36] I worked hard on this- we should not shortcut
               ever-- for developers, to bring up system, we can't tell them to
               run BDD. But we can make that easier to do. So what we want is a
               CLI to bring up a system for development.. jeff stated tweeksk
               knobs parameters is pretty complex 27 steps- and there is a tweek
               in everything orderer, peer id, the signers, the developers,..
               then creation policy, who are your anchors... someone is going to
               write it just like feature file.. but our test could just be the
               script.  This is a full blown interactive... WE are going to
               hackfest and we want people to have a simple way to do this

      [07:37]  The test chain id has to be in orderer- and this
               is bad part- having hard coded test chain id in orderer is bad..
               in dev environment, we need to prime it in dev environment and
               not hardcoded in environment.  So we are getting in design
               discussions..

      [07:38]  let's take this off line-- we are going through
               this list, but we want people to do something on the 31st-
               orderer comes up and peer comes up- create channel api and I get
               you default certificate, create channel, and add one org and the
               stuff should just work-- that is what is a development system..

      [07:39]  ARe we telling developers that they ned to set up
               our system- vagrant and everything to run BDD-- NO.. Behave stuff
               only requires docker compose period... there are a million ways
               to do this-- so we want to get to prove this out and where this
               is consumable is to eliminate hard coded stuff and if it doesn't
               work, then we need to go fix it...

      [07:40]  Bootstrap with a channel for dev- Jeff Garrat is
               going to do this and work with Gari/Jim...

      [07:40]  there are simplist- CLI,. SDK .. the usre wants to
               do something more complex with BDD.. the test chain id we need to
               remove and make it simple

      [07:40]  I worry about concept of having a separate network
               that is for developer mode- i think those days are gone.  in that
               case you provide sample ceritifcates and run through the process.
               no more shortcuts--

      [07:41]  all keys loaded from files,etc,.. even SDK is
               doing that now... Jeff made important point there are 2 main
               places we are hard coding- test chain code id... certs was
               hardcoded- we still have a sample out there- we generate using
               bdd and this is directory or use directory already shipping

      [07:42]  Custom Transactions- not for end of Jan

      [07:42]  CLI accepts multiple peers; we need this to test
               endorsement policy

      [07:42]  App crypto lib- this is a run at for alpha

      [07:42]  system chaincode refactor- this is eash given
               Ale's work

      [07:42]  Chaincode calling chaincode- we have addresswed
               the query case

      [07:43]  QUERY CASE only on CC calling CC

      [07:43]  Exsperiation MSP certs- we will not address this
               for alpha

      [07:43]  ------------------------------------

      [07:43]  For SDK (node.js, Java)

      [07:44]  The master is still on 0.6.,engaging with DTCC- we
               have created a 1.0 branch that we want to be master.

      [07:44]  We are having to merge this.

      [07:44]  Between DTCC and those on phone- there is also
               another guy from Fujitsu we need to merge everything

      [07:45]  Java only: create "official" branch.  #1 does not
               have to be done by end of htis month, but we do need to "clean"
               the directories up

      [07:45]  and that is being worked on to ensure we have
               clean consolidation

      [07:45]  Events support- Jim Zhang needs to talk about the
               eventing piece with Pat (see discussion above )

      [07:46]  Rest Wrapper- we have now handed off to the team
               that has joined the community in Hursley to do this

      [07:46]  GRPC for Join is in there- Brett has committed
               that- but we have trouble with MSP definitions

      [07:46]  it fails at that point- but we are getting all the
               way through the GRPC aspect

      [07:47]  ChainQuery on Ledger- The api is available in GO
               code is there, but it is not there for GRPC.. pass through query

      [07:47]  chaincode join- synce it's system chaincode call
               you can copy a lot of logic on query on ledger to complete this

      [07:48]  Remove RSA and HSM for SDK goal for end of month

      [07:50]  We have the Go implementationfor TCERT- we have
               the TCERT derivation form the last implementation is there.  It
               takes a key derivation on the SDK side and it's exactly the
               same.. we can maybe get there and Gari Singh can help that

      [07:50]  ESCC/VSCC- we need to add reference to a name in
               the proposal and we can do that

      [07:51]  For query on ledger- this is just AP that you
               already call on channel join, but we are down to 2 1/2 to 3
               developers.. on priority list query on ledger seems low. can't
               clients call system chaincode on any special thing on SDK.. they
               can also do from query CLi and get it

weeds [07:51] Jim is probably going to x out query on ledger

      [07:52]  SDK already accepts multiple peers (this was a
               question).

      [07:53]  --------

      [07:53]  For ledger- finishing couch misc items (versioningk deletes)

      [07:53]  Query APi is already exposed, but need to do work
               related to application chaincode-

      [07:53]  WE are in middle of history of key values (level
               db)

      [07:53]  We started doing the work on couch for history of
               key values and pushed down into level so that everyone can have
               the history not juts couch people

      [07:54]  For couch- we do not support remote- we will only
               support local to the peer

      [07:54]  Finalize QSCC block/tran structure that gets
               returned to client has to be discussed between Binh/Dave.. we
               definitely won't get through examples, but we may try to go
               through table replacement/query as we can before end of next week

      [07:54]  @manish-sethi  wanted to make sure you are reading
               the channel here- see all up above and start of conversation

      [07:55]  maybe Mohan can help with examples possibly?

      [07:55]  -------------------

      [07:55]  For fabric- CA

      [07:55]  comments on the list from up above

      [07:55]  Keith is trying to generate the swagger

      [07:57]  We need to decide on whether we do something on
               HSM support or later-- I think we decided that we are not
               committing HSM for alpha but HSM support (BCCSP or let's ecnrypt)
               - the way i'm leveraging- i want to use BCCSP integration
               throughout and then get HSM support through BCCSP. there are
               multiple places for private keys- signing of CSR request, singing
               of authoization header, signing of TCERts.. thing that is where
               we need to do the integration.  We already have BCCSP config
               integrated in.  The thing unclear right now is can we assume if
               we have BCCSP integration then we do have HSM support or no?

      [07:57]  Vlad is going to have to clarrify

      [07:58]  We want to do HSM support on BCCSP

      [07:58]  Vlad had done CFFSL has their own layer of singer
               on top

      [07:59]  @vpaprots  see above

      [07:59]  you have to send future request, they are
               authenticated in authorization header that covers certificate..
               and it contains sig, the sig contains the signature and the body.
               we need to do the signing wiht VSCSP..

      [07:59]  the signing in our CLI client

      [08:00]  if we did on the server side- it does not mean
               that yo uhave to do at the same time as the SDK side

      [08:01]  It comes down to request and re-enroll . On the CA
               side, the CA is some refactoring but perspective of using it, it
               works.  so we need to finish the register from SDK- we have
               almost ready to check in,.. by default we use SHA384 (only
               register/reneroll for off token),.. we would have register and
               create new users, enroll already works beautifully (Jim
               integrated it).. we enroll and get cert back.. no more work on
               SDK side for that.

      [08:02]  We just need to finish register and re-enroll.. do
               we take a cut. if you want to do a few things to clean up the
               document, it does not stop doing additional work. and we just
               take a cut of the CA before. so we can merge stuff after that..
               and CA is in very good shape.

      [08:03]  The only thing that is merged with HSM support for
               BCCSP.. BCCSP you can configure but it's not being used for HSM
               yet.  Just like HSM is out of the peer. You know that the default
               you changed to 256- so this is hard coded.. I di dnot change I
               implemented to SHA 384.. it's hard coded today so we can't change
               it.

      [08:04]  Intermediate CA support- I assume that is
               something that could wait, but i put that up there because the
               place where this is nice- if you set up a cluster of cop servers
               or fabric ca servers and you want to get enrollment certs
               distributed for them. you can start a root ca and cluster of
               intermediate servers that enroll with it.. I may be overly
               optimistic- this is 1 day's worth of work. it's not a big effort.
               Binh is saying this is very useful for testing out  multiple MSP
               concept. it will be nice to have a single ca and generate
               something intermediate.  IT's also nice to reknew a CA
               certificate ultimately.

      [08:05]  if you do the first thing with Swagger doc.. and
               top list. if we are willing that SDk is not complete- you can use
               ecerts we have that working.. we have ability to node sdk to
               enroll, we finish register api, cop is up- you can get
               certificates fo rany # of peers for encorsement and for joining
               channels and connecting.  We can use what Keith gets done. but we
               can take CA and build that out today and use that for the 31st.

      [08:05]  If we don't have TCERT support throughout- that's
               fine

      [08:06]  --------------

      [08:06]  For documentation

      [08:08]  We should have remove the version 0.6,... we are
               already started on high level overview, high level architecture,
               glossary of terms, how to get docker up and running with
               compose,.. and how developers program against chaincode -- which
               includes APIs, channels, couchdb/ledger and chaincode.

      [08:08]  Binh asking how much more we need to help on doc
               based on where we are- i need the apis and how to program against
               chaincode with Murali... Murali will sit with a couple of hours
               to step through all that stuff

      [08:09]  need to have some prebuilt things- x number of the
               MSP- -we should at minimum in policy have that... for the
               docuementation things like query system chaincode, config system
               chaincode,

      [08:10]  docker compose is self descriptive instead of
               reams of documentation-- just explain like was done before

      [08:10]  @nickgaski  @joshhus

      [08:11]  Today we have sample config- we should have
               sifferent sample config and put them-- and use docker compose

      [08:11]  and we generate the sample config

      [08:11]  What does it mean to have identity to invoke
               chaincode?  ours is a permissioned ledger.. this is important
               concept.. but we need to at least need to highlight that.. wecan
               go into details in MSP, but at minimum this should be outlined.

      [08:11]  How can I use to invoke chaincode?

      [08:12]  How about we have one config and config has
               identities that are pre-generated and we describe how we got
               identities and the places we are going to use

      [08:13]  This is trying to explain the initial set for end
               of this month and starts to be the framework- i agree that a high
               level description of how membership is enforced- explain
               permissions are organization based, we will have notion of
               membership defined via crypto mechanisms and x509 based support
               and here is a simple paragraph on that

      [08:14]  We then at end of this month- you want multiple
               orgs- each has x509 certificate- here is what you need to gather
               and we have worked out in api the config transaction for create
               channel has that MSP config struct. we make it simple at high
               level that the basics have MSP name plus the pem certificate and
               this is how it works. Then we can add more as we go along- it
               gives you the basic framework to start wtih

      [08:14]  In addition with that- we do some configurations
               for reference- we provide with 3 organizaitons and here is 3 root
               certificate authorities and an MSP policy that is 2 out of 3 for
               endorsement and have at it. @bmos299

      [08:15]  Angelo indicated that we already have a lot of
               this written up- so Nick and Josh can pick up from the dock from
               Elli and team

      [08:15]  ----------------------------

      [08:16]  What I want to do- put your name on the items on
               the board and you work on it-- I want to have a standup scrum at
               3pm today where I will transcript again here on the fabric-dev
               channel.  We will only do 2 things- what are the things
               preventing you from progressing? we will then keep people who
               need.

      [08:16]  we will do this at 9:30 and 3pm and will post on
               the channel

      [08:17]  if there is feedback from any of  the items above
               from those not involved in discussion (where there were many)-
               please get with squad laters or Gari Singh or Binh Nguyen

      [08:19]  With Clayton- we will take a quick break- we want
               to have discussion with Keith, Jim, and Binh so we talk about the
               scenario on how we use this- what is it that we expect to do on
               February 1st

      [08:19]  This may further refine the list up above- again
               we should ask that the community contribute to what we have
               written here

      [08:19]  ----------------------

weeds [08:26] @markparz  highlighting that you need to read the
               channel

      [08:27]  -----------------------

      [08:28]  We have drawn a  pic on the board

      [08:29]  Boxes are fabric-ca, orderer(solo), peer, SDK/App

      [08:29]  We want someone to be able to program and use the
               fabric at end of month

      [08:31]  Solo needs to come up- so someone needs to call
               create channel. There has to be a CA/Id that the orderer has to
               trust

      [08:32]  From SDK you must be able to create channel
               (orderer) and join channel (peer)

      [08:33]  Let's assume that we have multiple peers/cc 's

      [08:33]  We have multiple peers/cc

      [08:33]  Org1 peer, org 2peer, org 3peer

      [08:35]  in orderer- you have config block (chain name,
               address of orderer, msp config- cert/anchor peer.. cert/anchor,.
               cert/anchor)

      [08:36]  if we agree to this- the end scenario is that your
               application to prove out more than our single endorser..

      [08:37]  We have definition of create channel and taking in
               MSP config is in there.. but the orderer is not reading it; for
               create channel- the orderer takes what SDK channel takes so we
               have to come up with the right materials... jeff has it on the
               screen as he worked it.  The only thing missing orderer is not
               taking generated MSP information- i already do it on the peer
               side.

      [08:38]  Does the peer itself write to the block? yes..
               does the peer load any of the information and loads into the
               channel MSP config and utilize for cert config

      [08:38]  Current policy one of all members of the channel

      [08:38]  Then why do we have to do any additional work for
               January 31st?

      [08:39]  The local MSP for orderer.. do i care if orderer
               signs messages... the high level scenario write chaincode, deploy
               chaincode, and use basic policy that is more than one guy
               endorsing it.. 1 of MSP configured for channel

      [08:39]  All the info is in messages ...

      [08:39]  If you don't need access control- then we are done

      [08:40]  simple scenario that works-- all the stuff
               surrounding it that we need to have some level of code, because
               in February we really need to start testing.

      [08:40]  If I want to have someone use this thing- is it
               useable now and prove out basics of system. What is missing?
               should we just do doc improvement on this scenario?

      [08:41]  WE can work on  how we integrate the CA into
               scenario.. and process of SDK can utilize what Jeff did in his
               script already showing this scenario work.

      [08:41]  If changes to from last week- too many merges can
               happen... and can hurt us

      [08:42]  We should probably have ability to create multiple
               channels---

      [08:42]  (this works)

      [08:42]  @bmoss299 we should make sure that this scenario
               up above is what is documented by Nick/Josh

      [08:43]  Do we want to show negative checking? do we need
               to verify endorsements?  it would be trivial to add a user that
               is not signed by cas that is not accepted by channel creation and
               that works-

      [08:43]  for SDK to do the precheck- we need MSP on backend
               to be done and we do need work on SDK

      [08:44]  Brett seems to be working on join channel... we
               need to publish those as mpms alpha version. you want to have a
               sample

      [08:44]  on sample i would separate out deploy/invoke- here
               is how you create/join channel and here's how you deploy and
               invoke chaincode.

      [08:44]  It can fail any one of those processes, but it
               helps to see those steps.  we are in better shape than thought.
               We should take this same scenario

      [08:45]  now we decide we add TLS or add authentication by
               ordering side and we should then iterate... we use the images
               from what we have

      [08:45]  we could tag a version of master and build the
               images from there

      [08:45]  ----------

      [08:45]  Current behave images- effectively the top part is
               the CA definition- you can see defined order nnetwork (only
               signle organization)

      [08:46]  we have process a subject, a context, and a
               signer.. even though different verbiage we have admin tuple- cert
               from subject for context given an org

      [08:46]  this guy orderer0signer, order0o, orderorg() this
               is cert that puts under orderer when it starts- we can pass the
               yaml file to orderer. you will have local MSPs

      [08:46]  all that information is passed around

      [08:46]  ordererOrg()- this points to org that points to
               pem file with self sgining

      [08:47]  in scenario- we can decide if we do 3 cops- we can
               integrate that into scenario.. we can use ca for short

      [08:47]  this minimizes and nick can improve on docs...
               Jeff feels he can generate docs dynamically

      [08:48]  on volume- i'm going to output all the key
               artifacts

      [08:48]  so organization- all key organizations you want to
               define, ie peer org2

      [08:48]  So now you have afccess to the organization-
               orderer generates the GUId- so ordersystemcainid... so we utilize
               this name

      [08:49]  then bootstram creates chain policy- so basically
               i'm creating policy so thhree orgs can create channels , ie peer
               org0, 1/3

      [08:49]  so now signed items are created-- and now we have
               to create the msp using that policy (chaincreate policy 1)

      [08:49]  Now you have to create the genesis block for that
               chain id using policy solo and  referencing all tehse policies
               and associated names

      [08:50]  chain creator does enforce that in that msp based
               on whatever that policy is

      [08:50]  that creates the genesis block

      [08:51]  We are missing a step instead of guy creating a
               block- the guy has to create the block data and collects
               signature on the orderer just like developer- orderer has to get
               the sigs if there is one org or multiple org in orderer. but we
               have to add that

      [08:51]  But none of that is enforced today- no, but I
               don't want to miss it

      [08:51]  so you tell that story- how we have to
               incrementally plug those features in

      [08:51]  couple of other things- and this thing i'm
               defining th e peer network- this generates signer certs to each
               peer and peer starts with right  local msp

      [08:52]  i gave peer 0 to peerorg0 but peer 2 and 3 peer 2
               in org 1, peer 3 in org 1

      [08:52]  this is template stuff--

      [08:52]  the next thing we do is identify developer for
               peer organization- give a subject and give context chaincreate
               policy1 (the one we gave to orderer)

      [08:52]  this is like giving developer access to a space-
               because I don't want anyone using the peer certs .. this gives
               sdk it's own identity as example

      [08:53]  peer org signs and devleoping in this space which
               we call chain create policy1

      [08:53]  I need identities for organization- so i chose
               peerorg0 and peerorg1 and this is subset of the genesis block- I
               could limit my channels to single org or subset of the org-

      [08:54]  if you have create chain policy- you can add any
               org you want.. because it has to be in the orderers- right now it
               does.. how can they validate it. how can they verify the sig.
               they do verify sigs. you verify signatures of public but it has
               to be in trusted root

      [08:54]  if i have create chain- theat everybody in this
               list-everyone has to sign it- so you have signature across the
               bytes, but remember these are the peerorgs you are asking for
               endorsement from

	       cft ordering system- there has to be at simplest-
               you have to then decide continue certs .. so you have to have one
               guy must add a bunch of root cas of who can do a create channel .
               now I am allowed to create channels i should not have list and
               should go out and pick 15 other people as long as signed by those
               CAs ...

      [08:56]  acceptance of block- i inspect,... or never join
               acceptance without signing. at what point will orderer enforce
               his certification. On broadcast

      [08:56]  IN this scneario- we are defining the peer
               organizations before we bootstrap the orderer. the reason we are
               doing that is we don't support the reconfiguration. so now who
               are the endorsements and particpate in the channel i'm going to
               create

      [08:57]  i create peer anchor set and I'm saying my anchor
               is from peer org 0, peer 2 from peer org 1 so I'm picking 1 out
               of each group

      [08:57]  i crate signed envelope- i have to reference
               channel, template, chain creation policy name and the anchor

      [08:58]  Thetemplate is a reference to the ones I'm going
               to use that i defined,.. chaincreate policy1 is a logical name
               must be used in all channel creation

      [08:59]  So now i get my signed config envelope- the
               orderer should ask all the order to sign before genesis block-
               org 0 collects signatures ...

      [08:59]  now create config transaction using signed above

      [08:59]  i save as configtx1 and broadcast to orderer

      [08:59]  I wait

      [09:00]  then i connect to deliver fucnation and seek
               request with those properties with chainid

      [09:00]  i should get delivery from order0 in 1 block
               within 1 second

      [09:00]  i then request to join using genseis block on peer
               0 with result

      [09:00]  I am calling api on system chaincode

      [09:00]  then let's say it works (which it deos

      [09:01]  now i'm delivering waiting and what does happen-
               we got a 200 response from peer

      [09:02]  for information on immediate up above Jeff Garrat
               can help

      [09:02]  the only thing that is not there orderer is not
               using the cert available to it (peer does this already so similar
               code)

      [09:02]  I just need to deploy and have code in deploy and
               ask for multiple endorsements at the same time

      [09:03]  lot of steps to get network up and running

      [09:03]  my docker network is running and you can use cli

	       but developer should not run bdd- they should just
               run docker compose

      [09:03]  it's more involved than that, because under the
               covers, i'm creating genesis file dynamically and also generating
               the local msp

      [09:03]  so i create ca certs, pstore and parameterized

      [09:04]  docker compose can bring up entities unles syou
               hard code- so now you need scripts to link them together

      [09:04]  We have to do the work on SDK sde to make this
               work and they should replicate this

      [09:04]  ARe you saying angelo we support one of msp policy
               today- we do on VSCC

      [09:05]  do you define that at the ESCC side? they do have
               to match but we have the one of

      [09:05]  and does that work when you deploy chaincode- we
               have to work that- which is chaincode lifecycle

      [09:05]  which is in the list

      [09:05]  we have everything to joined channel and we can
               inject deployment

      [09:05]  but deployment not ready yet

	       to deploy chaincode- you need one of policy--- we
               need that

      [09:06]  if we expect people to not break apis' we probably
               need chaincode return object

      [09:06]  it is implemented but  merged and committed and
               documented

      [09:06]  you need deploy transaction and need in SDK to
               specify the ESCC policy

      [09:07]  Jeff- if i look at the log for gossip peer- which
               is peer 1- i see something that is concerning-

      [09:07]  there is "no such channel" on the anchor

	       i would tag master and build and go through 20
               steps and everything provisioned

      [09:10]  there is a mismatch in gossip and way we are
               encoding

      [09:10]  VSCC would only check to see if one of members is
               singing

      [09:12]  Things for absolute minimum- chaincode return
               object, chaincode endorsement policy, escc/VSCC, events support
               (includ rejection ), chainjoin (creation basically needs to get
               done)

      [09:15]  The rest of the other items should progress- but
               we know what the most important it is

      [09:16]  The other piece we MUST decide on is chaincode
               lifecycle
               
   ry [09:21]  @weeds @ghaskins that will be on the wiki soon

      [09:25]  @weeds what is the context for this?

      [09:54] https://wiki.hyperledger.org/community/fabric-notes

weeds [10:33] @ry Binh met with several people that develop on the fabric

      [10:34]  We already have docker images that people can utilize (not
               sure it's all checked in), but we wnat to make sure for the
               hackfest that we have all the right pieces for people to

      [10:34]  1) start up the fabric

      [10:34]  2) be able to bootstrap a network

      [10:35]  3) be able to  join, create and deploy chaincode on multiple
               chains based on who is allowed to be in that channel
               (ie we have multichannels working)

      [10:36]  4) they should be able to do the full transaction from sending
               transactions to the endorsers (where a policy is set- for
               example one out four endorsers can approve the transaction),
               be able to send to orderer and have it ordered and then put
               into the ledger (whether couchdb or level db).. they should be
               able to query the result---> this should be able to be done
               against multiple channels

      [10:36]  5) who is allowed on the channel is important part of scenario

      [10:37]  As a result the items above- we took assessment where all the
               pieces are in the fabric (there are some holes as not everyone
               anted up information during hte call)... and highlighted what
               we thought we needed to be done.  So you will see categories
               of fabric, SDK, BDD (for testing) , documentation, and cop

      [10:37]  after that, and this is probably where the notes got fuzzy,
               Jeff Garrat took us through BDD showing how to bootstrap the network

      [10:38]  as this is already working and flowing an what minor pieces
               just need to be completed there

weeds [13:20] another quick conversation--> Now the thing that we
can do, we can run Jeff Garrat's BDD- capture the block, put in
sample directory and we run with that.  That allows our CLI to
work,.. that would allow the demo scenario to work with the new
configuration block.  With that configuration block- what would
we have to do to submit that transaction to the orderer.  Have
you look at config txt template stuff?  Basically there is under
config tx test thereis order template file and peer template
file.  This is the statically exported thing (not fromjeff's
tool) this is configuration tool.. and feed in new chain- and
spits out the transaction you have to spit it out to create a new
chain- there is no import cycles,etc,..

[13:21]  So what if you did this? bring up compose, another
docker container we boot up and tells people to console into it
(exec batch into it).. it has the CLi and it has a series of
commands... it can be any of those things. You can log into xyz,
you run CDE,.. and then your thing is initialized an dyou can run
your nodejs.sdk to run your transactions.  People just have a
hard time running CLI-- it allows us to use docker and not
vagrant.  Have a CLI container and do stuff.  We just add
additional commands- this is admin configuring the network.  So
you want to create chain and here's what you do.

[13:21]  We can do that easily without channel create. and
specify flag default cahnnel, use your template.

[13:22]  You can actually do interactive- whatever command you
run- you run batch script and then test just exec docker and run
as a command line and without invoking the container- htat is how
we did this last week, we put it in a container

[13:22]  As long as we don't hardcode, but include the
"generation part"... how many templates... let's just cli create
to take argument where CLI chain create command will it do it for
you.. we will call the templates

[13:23]  so now on board -- we are adding CLI channel create for
alpha

[13:24]  Jeff has this working in behave- it's completely
parameterized.. you get a language- you can add orgs, change
orgs, create as many channels you want, create as many order
networks.... will we intimidate developers to do that... Jeff
says- it would be good to do a python setup .. you can clone the
get... Actually, what we should really do is bake into the
image.. Behave stuff drives docker compose.. and you can drive
docker.. bind in the docker socket.

ghaskins [13:24] @vpaprots @harrijk @ramesh regarding:
https://gerrit.hyperledger.org/r/#/c/4359/

[13:24]  how do we want to proceed ?

vpaprots [13:25] talking with John atm..

ghaskins [13:25] ok

[13:25]  ill look to you guys: if you come back and are confident
my concerns are unfounded, ill remove my -2

vpaprots [13:25] John showed me that softhsm was not installed..
and I forgot that its debian..

harrijk [13:26] I think for the first step, we'll need to get
softhsm2 into testenv for fabric

ghaskins [13:26] ok, thats a very low-risk proposition from my
perspective

vpaprots [13:26] I do need it in asap, sitting on quite the few
changes that cant go in without it.. but.. found some issues with
how I specify pkcs11-slot.

weeds [13:26] what is important is they need to have an admin
thing that is clear-- so the only way to build an app is to use
the SDK.. we should have two simple scripts that create channel
to call the apis-- just to make it easy.

ghaskins [13:27] (sorry weeds, cross-talked over your stream of
consciousness ;)

weeds [13:28] We are set on CLI and run clis in an interactive
docker container.  So we are going to modify channel create.. it
will take default template and use it as the configuration (it's
ok greg- just trying to capture discussion here for your guys-
can't tell if you can even follow the stream of consciousness)

ghaskins [13:28] understood, just apologizing for interrupting it

weeds [13:29] Jason- how would in default template get cert---
you would have to regenerate the template. Basically the tool
that I keep alluding to essentially is order admin tool that
connects to and dumps a template chain by looking at the block

[13:30]  The tool does not exist- there is a static tool that
exists, but we need this to work at run time. then we would check
template in and can be generated... as part of the compose once
you are running services which dumps template and would be fed
into chain creation tool

[13:31]  My developer needs a private key- we self generate all
that stuff.  we will have docker image for the cli.. so we could
just use a shared volume to the local msp which is needed for
that key and bake it in ahead of time... hmmm.  the one jeff does
bdd does it through shared volumes.   someone is outside of
docker writing a node app.. he has to find stuff.. if we just
started a container rather than docker run, we can do docker
exec,.. you could template, keys being there,etc,..

[13:33]  in their application, where do we get their certificate
from- there in a shared volume- they are on local file system,,..
you could put that in... that would be the easiest thing to do..
REally Jason said he needs to talk about the SDK guys -  they
really should not know how to do that and pick up from template
and be able to print them,. .for now it's an efficiency, because
we only have templates working is in go.. but that really should
be in sdk at this point

[13:33]  Binh suggested maybe give them an api to implement?
Jason said- ok.. give them an api to use the templates we
generate. Open a JIRA or slack it to them?  Slack it to them.

[13:34]  Barry- maybe I have Latitia to help you?  Jason- I would
love to get more people to know how this works. It's tying hte
config and node program and spinning up something quickly.

[13:34]  (we need to forget not to miss the java sdk)

[13:35]  There are some questions for Jim in terms of validation
process for Barry and Latitia

[13:35]  We have an image, spins up fabric, runs templates,..
which crypto mounted to volume and then tell sdk here is how you
connect and use this.

[13:37]  Just to get someone writing ... the thing with  say I
had another image he spins everything up and it's a done deal for
me- i have all certs and network. if I run a behave (instead of
the cli) run the docker image that runs the behave- we mount
that.. in behave, you would have to generate all the cert stuff..
it will do it for you.. we just tell the end user.. hey sdk
developer- yo uare ready to go.  If you just basically toe do not
decompose.. if you can get an image.. put.  now we can hardcode
behave .. maybe that's an easier fix.

[13:38]  Which is better? at end of the day, people are going to
have to know how to create the configuration transaction and you
won't have all your stuff in one place and you will have to deal
with templates... Yes, that's true.

[13:38]  The big thing is can you make behave from inside a
docker container-- that's going to be the question- you can bind
docker socket into docker image.  That's unit test, but Jeff
might know.

ghaskins [13:48] @weeds: on that front, it was my intention,
though I have yet to prove it out that "make behave" would
eventually drive the behave tests with a "$(DRUN) behave",
similar to how we do unit tests

[13:49]  as part of that, I would be moving the python
installation stuff that we currently do in the baseimage to be
within the testenv container that is JITted as part of the build

[13:50]  from there, it should be straight forward to grant the
behave container permissions to dockerd for its own control of
futher containers, similar to what we do in other places

[13:50]  but where I am going with this is: I woulnt classify it
as "make behave" running in a container, as much as "make behave"
drives behave within docker

[13:50]  thats probably the same thing you meant, but good to
clarify

binhn [18:15] @ghaskins :+1: We were talking about what would be
the best way to help app developers set up a working environment,
and the thought was to run a bdd feature (pick an appropriate
one)

ghaskins [18:16] ah, as in use bdd to help create an app
developer environment?

binhn [18:17] yes, but we wouldn’t want developers to have to
install vagrant + other tools, just bring up a docker image to
run the bdd from it

ghaskins [18:17] ok, but we are already largely there, arent we ?

[18:18]  the majority of functions (excluding bdd) only need
make/git/docker/docker-compose

[18:18]  and I think bdd could be brought into that fold fairly
easily

[18:19]  some of what you are talking about reminds me of this
old issue:
https://github.com/hyperledger/fabric-chaintool/issues/5 GitHub
add "chaintool new" · Issue #5 · hyperledger/fabric-chaintool ·
GitHub Would be nice if the tooling could emit a skeleton project
to get things started, similar to "lein new".
 

binhn [18:19] i think the work is to enable bdd inside a
container to create images and launch other containers

ghaskins [18:20] I was envisioning a user doing something like
"chaintool new" and it will spit out a skeleton chaincode app

[18:21]  it would be fairly easy to make different profiles that
are both CCI based and those that are not

[18:21]  not sure if that is exactly what you were looking for
though

binhn [18:22] and “chaintool new” with an option to launch an env
and deploy the app

ghaskins [18:22] ok, i see where you are going

[18:23]  yeah, you could use chaintool code-generation
capabilities to spit out whatever you wanted, and then drive an
environment with docker-compose

[18:23]  it would mostly be a function of defining the templates
that we need

[18:24]  chaintool is currently based on the stringtemplate
engine (http://www.stringtemplate.org/)

binhn [18:24] right and that is done with bdd features today, so
we were thinking about capture that in an image, but it can
definitely chaintool

ghaskins [18:25] ok...i think regardless, moving towards
integrating bdd with the $(DRUN) stuff makes sense

binhn [18:27] agreed

[18:29]  @ghaskins btw, we could use some feedback on this
chaincode deployment proposal
https://jira.hyperledger.org/browse/FAB-1783

ghaskins [18:29] will take a look, thx

binhn [18:30] thanks

weeds [06:35] Ok Binh came by open area and a few people
congregated---> Here are some notes as a result

jyellick [06:35] Note that we also need to fix the hashing of the
data block, which is targeted to be done as a Merkle tree, but
again, unless someone is interested in maintaining the hash
chain, I'm not sure what the value of computing this hash is.

weeds [06:36] Chaincode Ednorsement policy did make it in- there
is still another 1/2 to go

[06:36]  For Chaincode REturn object - this one is in,.. and
everyone needs to rebase- this is going to change your chain
code... This guy is to return different status code on every
chaincode

[06:37]  Anchor peers is blocked because the peer needs the
handler finished which Jason Yellick has pushed some of this-- If
Jason's stuff is checked in, we can proceed

[06:38]  All peers connect to the ordering service- you need to
join the channel at bootstrap- that code has to be written,
because not all peers will get the identity channel--> Jason
Yellick owns this

jyellick [06:39] @weeds I can hopefully get this done today.

[06:39]  (Am on the hangout, but cannot hear anything)

weeds [06:39] We are almost done with the system chaincode
refactoring which will come in this AM-  Murali did that work

[06:39]  Chaincode calling chaincode is almost 1/2 way there-
Binh is debugging

[06:39]  CLI channel to create default-  barry is working on that
relative to the docker image

[06:40]  For ledger with Dave enyeart- there are change sets out
for finishing couch miscelanous items and query.. we ahve
questions on refactoring for chaincode API- he is going to get
with Murali

[06:40]  Change set on history of key values 9LEVEL DB) IS ALMOST
READY (SORRY CAPS)

[06:41]  the phantom read work done by Manish is readyy and
checked in for review and has +1 reviews from David- needs Binh
or Gari to review this.

[06:41]  One of the issues is that everyone is so busy- noone is
doing the reviews- we need help on this

[06:41]  In terms of getting couch environment into docker for
next week- Dave Enyeart talked to Barry - bmos299.. we left it
that after you get simple happy path, we will add couch to docker
compose.

rickr [06:42] @jyellick I think we will eventually need to parse
it to get the block number when monitoring what transactions have
processed.   The blocknumber will make sure we don't process this
again 1 reply Today at 06:43 View thread

weeds [06:42] For docker- we have basic path working, we are
adding sdk.. Adnan is adding the couch stuff to it

[06:42]  Barry is working with Adnan

jyellick [06:43] replied to a thread rickr 06:42 @jyellick I
think we will eventually need to parse it to get the block number
when monitoring what transactions have processed.   The
blocknumber will make sure we don't process this again
https://hyperledgerproject.slack.com/archives/fabric-dev/p1485355326001776
1 reply jyellick 06:43 rickr: You can certainly get the block
number, but I'm not sure why you need to compute the header hash?
https://hyperledgerproject.slack.com/archives/fabric-dev/p1485355392001779?thread_ts=1485355326001776&cid=C0YPYBVJM

weeds [06:43] On the finalized QSCC block tran structures- we
talked about that yesterday. I sent a draft of whta we talked
about and we will post in community on the channel- one of the
questions was get transaction by id- we trun the tran
protostructure, but header is above that, but header is
importnat.. that is transaction id, time stamp.. so we may need
to return the payload. it should be clear in the proposal for
that... Dave Enyeart to post this to get feedback from community

[06:45]  to ARtem- when we do state synch, are we calling same
api to get block from one peer to send to another peer? they are
using committer,.. but I think it does use same api.. we need to
see if it's a lower level of apis that manipulates bytes... the
lower level gets block by # and retunrs the unmarshalled block
proto... that's what synch wants to do. maybe we have to optimize
and suck the entire file over... Right now, it calls get block...
that's very inefficient. We do a lot of marshalling and
unmarshalling.. repeated.  Dave is saying we need synch that
works on serialized block then.  Artem says ok.  This is not for
immecdiate, but needs to be logged in JIRA so as not to forget
for optimization and performance (which is focus in February)

[06:47]  On the SDK- there is outstanding chainset that needs to
be approved.  we're still making progress on event support and
join chain. both are going in parallel. we are working on
initializing the MSP that is needed to send create chain request
to orderer.  All is still on going.  We are targetting event
support completion if we don't get all chain creation and chain
join-- is that ok? we will have to use CLI... that is the backup
plan .. there is a lot of moving parts for chain creation, but we
do want to get events support done.  WE haven't added the
references to ESCC or VSCC to deploy yet-- that is higher
priority it seems like.. this is so application can execute.

[06:47]  For event support- i merged chainset that Pat
implemented

new messages [06:50]  What is ESCC /VSCC is needed? this is
absolutely needed for endorsement. Has something changed?  There
are defaults being used.. there is an item that Murali has worked
called chaincode lifecyle and endorsement policy.   Currently
transaciton comes in, we just say ok fine... but once we have
endorsement policy which is mostly done- transaction must be
signed by John.  The work on the SDK side is adding a new field
to the proposal , identifying ESCC and VSCC by name, which is
really not significant,.. and we can add that support.. Policy
being things like 3 out of 10 sigs... We can defiintely identify
and add in there for policy or we can also default system for
this round.  Supposedly application should do preliminary
checking on responses- if it's not meeting the policy- it should
discard.  Right now, we are just sending things over where VSCC
will catch that.  I'd like to keep that as is for end of month
for alpha. Yes, sounds reasonable... we do think key to send in
ESCC, VSCC, and policy.  The CR that I talked about with
endorsement policy is out there. it's called post it notation..
end/a/b something like that. you need signature for a and b... is
that a string?

[06:50]  from application, we haven't decided from community
whether string goes all the way to the peer or deployment... or
the SDK would proto this into structure- i suspect it's going to
be at the peer for desing sake.

[06:50]  CLI we can do this already

[06:51]  Documentation- There is higher level pieces,.. maybe 7
or 8 separate higher level topics as an overview documentation
for the community. 2 that are basically done and we can complete
remainder in day or 2... and knock out the rest of the stuff with
the various people assigned.

[06:54]  we need a sample, Question is what do we show for
policy, MSP,etc,. and need some input from the community for this
first round ... We do need to probably talk about system
chaincode and the apis.. that has to probably come from Murali or
Binh at this point.  Performing a query against couchdb we do
need to include for complex queries should come from Dave Eneyart

[06:56]  When they do the docker compose for getting started- it
will have example 2 chaincode.

[06:57]  in text, you can create a channel, join a channel with
these # of peers, there is a CA set up, here is your node sdk..
do an enroll and signing cert ,.. we provide a very basic nodejs
program.. so at least people have some artifacts to give feedback
on.  text, you can create a channel, join a channel with these #
of peers, there is a CA set up, here is your node sdk.. do an
enroll and signing cert ,.. we provide a very basic nodejs
program.. so at least people have some artifacts to give feedback
on.

[06:58]  we have docker images published somewhere, the docker
compose that ties all together, and zip file with some generated
materials in generated location so people can connect to it- this
gives you network that works,.. another file that shows
application code, mpm install and run... seems like maybe that
will help get people get started next week?

[07:00]  One thing in the YAML we should remove- the fields in
security section need e removed -- all those really are not
appropriate- that security seciton is getting removed-

[07:00]  Chaincode interface chain really is a big bug-- that has
to get updated

[07:00]  someone could help that and rebase

adc [07:06] okay, @jyellick @jzhang @rickr, what I want to say is
that ASN.1 is preferable solution, I would say. We can avoid it
if necessary. If we do, let's have it properly documented

jyellick [07:16] @rickr @jzhang I'm still trying to understand
why the SDK ever needs to compute this hash

weeds [07:26] Binh had discussion with Elli and Angelo- I have a
function called check acl,. This is the chaincode calling
chaincode- before we set everything to invoke another chaincode
specification, we check the acl.. and what that means is what we
want to do is to check to see whether this transaction in
proposal the signature is valid on this channel.. so imagine that
chaincode 1 calling chaincode 2. chaincode 1 on channel 1,
chaincode 2 on channel 2, chaincode 1 is invoked by user 1... so
when proposal comes in, we verify the signature against that user
1 against the config block on channel 1... so now when chaincode
1 calls chaincode 2 on channel 2 passing along the proposal.. so
now we have to verify again the user 1 signature against the
channel 2 where chaincode 2 is on.. so this is what happens in
check acl.  but we seem in code to be missing a few pieces-

[07:28]  there is check sig from creator- message validation
go... it's a local function..  I think I can call this function,
but this function- is that it's local, so we need to change to
global. but the problem is this- it takes the information we only
have from a side proposal, which is at this point is in the
handler at this point.. the only thing we have is th eproposal,
we don't have side proposal.  I want to talk to someone who
created this- Elli, angelo, ale? do we need all of this- can we
work with proposal or side proposal to call this function?  We
can get message bytes is the side proposal is the proposal bytes
itself...

[07:28]  We either have to change our handler to pass the enitre
proposal.. versus just the proposal given by this function.

[07:29]  Is this happening on the same peer? you can assume that
the proposal has already been verified, because it's verified in
the first channel, so you don't have to verify anymore- if the
peer is malicious- it's malicious.

[07:29]  We have to assume the peer is doing the right thing-
let's assume that this user has access to channel 1 to do
something but this user does not have access to channel 2.. even
though the peer joins both channels.  So in this case you do need
this.

[07:30]  We do need to enforce the ACL on both channels-

[07:31]  that function calls from validate proposal and check
sig- creator is respect to this one chain.. is there a chain id
on that? yes... we are assumin the creator verified on channel
1.. that same creator instance can be used... so yes.. if you
have creator bytes you re fine.. so how do you check the read set
and write set- how do you know?  the read can be modified on a
different channel.  we don't do any of that except we verify tat
the user signature is verifiable on channel 2.. we need to
develop that (Angelo working on that)... ARe you saying you get
read/write set of chain? what does read/write set on 2nd chain?
how do we resolve version conflicts regardless of access control?

[07:32]  If you read the JIRA item- it's a read only and and
there is no read/write set for the called chaincode.

[07:33]  if the query is on the same chain as chaincode- you have
read/write set of the chainocde and verify vscc shcek . but on
different channel, we can ONLY do read and query only

[07:33]  there is no read set- we are not sending read set from
chain 2 inside.. the only thing proposal response has is the
read/write set is for the first call of the chain.

[07:34]  WE do have the read/write set collected on the same
channel and it's working-verified

[07:34]  but on different channel we do not want to collect the
read/write set on the 2nd channel- we only want to return the
value.

[07:35]  Now that you mention it- there is one more thing you
need to do when doing different chains-- but same logic calling-
it's going to try to include it and we need to fix that on the
2nd chain

[07:35]  From security point of view- we can check the signature-
yes?

[07:36]  the 2nd chain code is working like an oracle.. it might
be an endorser that might get a different value.. so you might
see a transaction be rejected.. yes, sdk would reject.  this has
to be calirifed to the developer.. it depends on how you
implement- if you go to oracle- give me the current value-
because endorsers might end up with different view, but security
of execution-- you do same process when proposal first came-- is
the oracle value has to be included what the endorsers endorse-
the read set... but not clear if this makes sense- it's up to the
calling chaincode if they want to... because eventually the value
is considered by calling another chainocde will effect the
outcome of the execution of that chaincode

[07:37]  if the value was idfferent, then the outcome is
different,.. and the end result of that proposal would be
different

[07:37]  there is no difference if you even have a regular call
outside the blockchain

[07:38]  how do you replay the blockchain in this case?

[07:39]  this would allow for non-determinism

[07:39]  if 3 endorsers get the same response- it will have same
simulation, endorsement will succeed and commitment will be
validated despite the chaincode is not replayable

[07:44]  you have endorsement- you send read/write set... you
signed agreeing to set of inputs and you got outputs.

[07:44]  proposal come in and you want to include external data-
you need to put it into key... you have to do that.

[07:44]  This is the same as keys we read without modifying

[07:44]  the big point is this there are rules for writing
chaincode

[07:44]  1) access only state variables on database

[07:45]  2) if you access something external and you are on your
own and you better record it somehow

[07:45]  This is true whether calling chaincode or calling
external source

[07:45]  @bmos299 please make sure in doc this is recorded
clearly point 1 and 2 up above

sandra.vrtikapa [07:48] joined #fabric-dev

sandra.vrtikapa [07:50] Currently I can only receive/access
chaincode events via block events. If I set a chaincode event in
user chaincode and that part of the code doesn't generate block
event later on I am not able to receive my chaincode event. Is
there a plan to support sending/firing chaincode events from user
chaincode independent of block events?

ghaskins [08:28] @pmullaney ^^^

pmullaney [08:39] @sandra.vrtikapa : if you set a chaincode event
in a chaincode, you will generate a block( or be included in a
block)

new messages [08:40]  if you use the upcoming eventhub in the
v1.0 api, you can just register for a chaincode event - eventhub
takes care of parsing the chaincode event from the block it
receives

[08:41]  I hope that clears the question up if not ask awaytext,
you can create a channel, join a channel with these # of peers,
there is a CA set up, here is your node sdk.. do an enroll and
signing cert ,.. we provide a very basic nodejs program.. so at
least people have some artifacts to give feedback on.

[06:58]  we have docker images published somewhere, the docker
compose that ties all together, and zip file with some generated
materials in generated location so people can connect to it- this
gives you network that works,.. another file that shows
application code, mpm install and run... seems like maybe that
will help get people get started next week?

[07:00]  One thing in the YAML we should remove- the fields in
security section need e removed -- all those really are not
appropriate- that security seciton is getting removed-

[07:00]  Chaincode interface chain really is a big bug-- that has
to get updated

[07:00]  someone could help that and rebase

adc [07:06] okay, @jyellick @jzhang @rickr, what I want to say is
that ASN.1 is preferable solution, I would say. We can avoid it
if necessary. If we do, let's have it properly documented

jyellick [07:16] @rickr @jzhang I'm still trying to understand
why the SDK ever needs to compute this hash

weeds [07:26] Binh had discussion with Elli and Angelo- I have a
function called check acl,. This is the chaincode calling
chaincode- before we set everything to invoke another chaincode
specification, we check the acl.. and what that means is what we
want to do is to check to see whether this transaction in
proposal the signature is valid on this channel.. so imagine that
chaincode 1 calling chaincode 2. chaincode 1 on channel 1,
chaincode 2 on channel 2, chaincode 1 is invoked by user 1... so
when proposal comes in, we verify the signature against that user
1 against the config block on channel 1... so now when chaincode
1 calls chaincode 2 on channel 2 passing along the proposal.. so
now we have to verify again the user 1 signature against the
channel 2 where chaincode 2 is on.. so this is what happens in
check acl.  but we seem in code to be missing a few pieces-

[07:28]  there is check sig from creator- message validation
go... it's a local function..  I think I can call this function,
but this function- is that it's local, so we need to change to
global. but the problem is this- it takes the information we only
have from a side proposal, which is at this point is in the
handler at this point.. the only thing we have is th eproposal,
we don't have side proposal.  I want to talk to someone who
created this- Elli, angelo, ale? do we need all of this- can we
work with proposal or side proposal to call this function?  We
can get message bytes is the side proposal is the proposal bytes
itself...

[07:28]  We either have to change our handler to pass the enitre
proposal.. versus just the proposal given by this function.

[07:29]  Is this happening on the same peer? you can assume that
the proposal has already been verified, because it's verified in
the first channel, so you don't have to verify anymore- if the
peer is malicious- it's malicious.

[07:29]  We have to assume the peer is doing the right thing-
let's assume that this user has access to channel 1 to do
something but this user does not have access to channel 2.. even
though the peer joins both channels.  So in this case you do need
this.

[07:30]  We do need to enforce the ACL on both channels-

[07:31]  that function calls from validate proposal and check
sig- creator is respect to this one chain.. is there a chain id
on that? yes... we are assumin the creator verified on channel
1.. that same creator instance can be used... so yes.. if you
have creator bytes you re fine.. so how do you check the read set
and write set- how do you know?  the read can be modified on a
different channel.  we don't do any of that except we verify tat
the user signature is verifiable on channel 2.. we need to
develop that (Angelo working on that)... ARe you saying you get
read/write set of chain? what does read/write set on 2nd chain?
how do we resolve version conflicts regardless of access control?

[07:32]  If you read the JIRA item- it's a read only and and
there is no read/write set for the called chaincode.

[07:33]  if the query is on the same chain as chaincode- you have
read/write set of the chainocde and verify vscc shcek . but on
different channel, we can ONLY do read and query only

[07:33]  there is no read set- we are not sending read set from
chain 2 inside.. the only thing proposal response has is the
read/write set is for the first call of the chain.

[07:34]  WE do have the read/write set collected on the same
channel and it's working-verified

[07:34]  but on different channel we do not want to collect the
read/write set on the 2nd channel- we only want to return the
value.

[07:35]  Now that you mention it- there is one more thing you
need to do when doing different chains-- but same logic calling-
it's going to try to include it and we need to fix that on the
2nd chain

[07:35]  From security point of view- we can check the signature-
yes?

[07:36]  the 2nd chain code is working like an oracle.. it might
be an endorser that might get a different value.. so you might
see a transaction be rejected.. yes, sdk would reject.  this has
to be calirifed to the developer.. it depends on how you
implement- if you go to oracle- give me the current value-
because endorsers might end up with different view, but security
of execution-- you do same process when proposal first came-- is
the oracle value has to be included what the endorsers endorse-
the read set... but not clear if this makes sense- it's up to the
calling chaincode if they want to... because eventually the value
is considered by calling another chainocde will effect the
outcome of the execution of that chaincode

[07:37]  if the value was idfferent, then the outcome is
different,.. and the end result of that proposal would be
different

[07:37]  there is no difference if you even have a regular call
outside the blockchain

[07:38]  how do you replay the blockchain in this case?

[07:39]  this would allow for non-determinism

[07:39]  if 3 endorsers get the same response- it will have same
simulation, endorsement will succeed and commitment will be
validated despite the chaincode is not replayable

[07:44]  you have endorsement- you send read/write set... you
signed agreeing to set of inputs and you got outputs.

[07:44]  proposal come in and you want to include external data-
you need to put it into key... you have to do that.

[07:44]  This is the same as keys we read without modifying

[07:44]  the big point is this there are rules for writing
chaincode

[07:44]  1) access only state variables on database

[07:45]  2) if you access something external and you are on your
own and you better record it somehow

[07:45]  This is true whether calling chaincode or calling
external source

[07:45]  @bmos299 please make sure in doc this is recorded
clearly point 1 and 2 up above