ZKPs for JSON-LD
ZKPs FOR JSON-LD
Tuesday 2E
Convener: Tobias Looker
Notes-taker(s): Orie Steele
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Slack channel: http://iiw.slack.com/archives/C012NAPF19T
Draft Spec: http://mattrglobal.github.io/jsonld-signatures-bbs-spec/
Draft spec repo: http://github.com/mattrglobal/jsonld-signatures-bbs-spec
BBS+ signature implementations: https://github.com/mattrglobal/node-bbs-signatures https://github.com/andrewwhitehead/ursa-bbs-py
JSON-LD signature suite to use with VC-JS: http://github.com/mattrglobal/jsonld-signatures-bbs
Regarding credential schema definitions in the vc data model: http://w3c.github.io/vc-data-model/#data-schemas
Proof formats in the VC Data Model: http://w3c.github.io/vc-data-model/#proof-formats
The paper for “provable security”: http://eprint.iacr.org/2016/663.pdf
A raw dump of the Zoom Chat follows
Mattr Global - Tobias Looker - ZKPs using BBS+ Signatures
http://mattrglobal.github.io/jsonld-signatures-bbs-spec/ http://github.com/mattrglobal/node-bbs-signatures
From CipherQueen to Everyone: (11:00 AM)
Am going to eat lunch, will be on mute.
From Tobias Looker to Everyone: (11:03 AM) http://mattrglobal.github.io/jsonld-signatures-bbs-spec/ https://github.com/mattrglobal/node-bbs-signatures
From Orie Steele to Everyone: (11:04 AM) Slack channel for this session is?
From Nader Helmy to Everyone: (11:04 AM) I can make one
From John Hopkins to Everyone: (11:04 AM) fullscreen presentation please
From timcappalli to Everyone: (11:04 AM) http://iiw.slack.com/archives/C012NAPF19T
From Me to Everyone: (11:05 AM) How do I get an account in the iiw slack?
From timcappalli to Everyone: (11:05 AM) http://join.slack.com/t/iiw/shared_invite/zt-e08ieit0-7~iZLzYJBIuaD6CG55YH7w
From John Callahan to Everyone: (11:05 AM) just click the link and it will walk u thru From Me to Everyone: (11:05 AM) Merci!
From Kaliya to Everyone: (11:06 AM) http://join.slack.com/t/iiw/shared_invite/zt-e08ieit0-7~iZLzYJBIuaD6CG55YH7w
From Rouven Heck to Everyone: (11:06 AM) @John - yet another Mr Login :)
From Brent Zundel to Everyone: (11:06 AM) #zkp in the iiw slack
From David Waite to Everyone: (11:06 AM) Let me know if the slides can be shared as well
From Me to Everyone: (11:06 AM) @rouven .. seriously ..
From Carl Youngblood to Everyone: (11:06 AM) Would also like a link to the slides
From Me to Everyone: (11:06 AM) Just offer proof of IIW attendeeship :)
From Dmitri Zagidulin to Everyone: (11:06 AM) ouch :) From Orie Steele to Everyone: (11:07 AM) http://iiw.slack.com/archives/C012NAPF19T ^ slack channel
From Me to Everyone: (11:09 AM) Would actually be straightforward with vc-authn-oidc that we demoed last IIW :) … but anyways .. really looking forward to this talk
From CipherQueen to Everyone: (11:16 AM) Hi. Am attending the ZKProof workshop. As part of the NIST submission, one goal is provably secure. Is provably secure one of your goals?
From malwhere to Everyone: (11:16 AM) for the signature? The signature is provably secure
From Andrew Whitehead to Everyone: (11:17 AM) I’ve got an early python wrapper here as well - no documentation and the API will likely change: http://github.com/andrewwhitehead/ursa-bbs-py From Orie Steele to Everyone: (11:17 AM) http://w3c.github.io/vc-data-model/#proof-formats
From Nathan George to Everyone: (11:20 AM) The credential definition was done in Indy as an efficiency thing, it lets systems cache more of what they use all the time. Can you comment on why inlining that seems like a better idea with BBS+?
From Orie Steele to Everyone: (11:21 AM) Because now you can use ZKPs with any system, not just coupled to a specific ledger.
From Stephen Curran to Everyone: (11:21 AM) I don't think that changes with this. Now you cache the contexts for the schemas of interest. The benefits outweigh - variable length schema and no ledger tie in. What Orie said :-)
From Nathan George to Everyone: (11:21 AM) You always could have those objects source anywhere from a crypto standpoint
From Stephen Curran to Everyone: (11:21 AM) Yup...can still be on a ledger.
From Nathan George to Everyone: (11:21 AM) Just wondering why you want them inline instead of reusable chunks
From Orie Steele to Everyone: (11:21 AM) Yes, you can still cache the JSON-LD contexts, its a best practice for stable ones.
From Stephen Curran to Everyone: (11:23 AM) From a dev perspective, CredDefs on the Ledger and in the wallet and having to be in sync has been painful. Dealt with in production, but friction in development.
From Orie Steele to Everyone: (11:23 AM) q+
From Brent Zundel to Everyone: (11:23 AM) what you're losing is the guarantees that having keys and schemas on a ledger provides.
From Charles Cunningham to Everyone: (11:23 AM) can BBS+ do range proofs? or is it purely masking verifiable attributes?
From malwhere to Everyone: (11:23 AM) No it can’t do range proofs its just selective disclosure, you typically combine BBS+ with another ZKP mechanism like Bulletproofs
From Stephen Curran to Everyone: (11:24 AM) @brent, I don't think so. Both parties generate the keys from the JSON-LD deterministically.
From malwhere to Everyone: (11:24 AM) or SNARKs
From Brent Zundel to Everyone: (11:24 AM) Ursa has tools for incorporating range proofs with bbs+ signatures
From Nathan George to Everyone: (11:24 AM) Yes, I think its a bit 6 for one half-a-dozen to another
From Nathan George to Everyone: (11:25 AM) I am trying to figure out why they decided to be different as it has big integration consequences
From malwhere to Everyone: (11:25 AM) Cred defs and JSON-LD contexts are the same here
From Nathan George to Everyone: (11:25 AM) Not really, because there isn’t any static serialization to JSON-LD
From Kyle Den Hartog to Everyone: (11:25 AM) And that can still be done using JSON-LD if the ledger can map the IRI to a JSON-LD object
From Nathan George to Everyone: (11:25 AM) I’m hoping Tobias shows that it means graph views or flattening are entirely unneeded
From Dmitri Zagidulin to Everyone: (11:26 AM) q+ to point out that the reverse is the case, re JSON-LD canonicalization
From Oliver Terbu to Everyone: (11:27 AM) Isn’t the canonicalisation defined by the ld suite? From Orie Steele to Everyone: (11:27 AM) Yes it is.
From Manu Sporny to Everyone: (11:27 AM) Yeah, I'm confused about the "We couldn't canonicalize JSON-LD" statement.
From Orie Steele to Everyone: (11:27 AM) There is JCS for JSON and N-Quads / RDF Normaliation...
From Juan Caballero to Everyone: (11:29 AM) Dmitri?
From Andrew Whitehead to Everyone: (11:29 AM)
I think the normalized form would have to change significantly to support range proofs From Nathan George to Everyone: (11:31 AM) There are also a lot of type normalization and schema-like thing that this may have a hard time covering compared to the serialization and encoding approaches others have already tried. I am optimistic but there is still a big hairball of functionality to address I’m hoping there is more on that later in the presentation? (Didn’t mean to derail Tobias’ presentation)
From Dmitri Zagidulin to Everyone: (11:32 AM) q- (manu can probably address my point better)
From Manu Sporny to Everyone: (11:33 AM) wait, Dmitri, what point?
From Nathan George to Everyone: (11:33 AM) Manu++ teach us the JSON-LD ways
From motoko to Everyone: (11:33 AM) where is the BbsBlsSignatureProof2020 type registered? I don’t see it in the @context attribute definitions, should the `proof` have an @context?
From Dmitri Zagidulin to Everyone: (11:33 AM) that canonicalization does not mean “more than one way"
From Manu Sporny to Everyone: (11:33 AM) oh, Dmitri - ok
From Orie Steele to Everyone: (11:34 AM) Where is the link to the paper?
From malwhere to Everyone: (11:34 AM) http://eprint.iacr.org/2016/663.pdf
From Kyle Den Hartog to Everyone: (11:34 AM) @motoko we’ve got a spec that will be added to the CCG for the ld proofs registries
From malwhere to Everyone: (11:34 AM) There you go Orie
From Kyle Den Hartog to Everyone: (11:34 AM) Not sure if it’s in there already or if there’s a few small things that need to be done to move it into there
From Tobias Looker to Everyone: (11:35 AM) Yes @motoko correct there is an extended context
From Me to Everyone: (11:35 AM) Agree ++1 awesome … we already working on support @andrewwhite has a python wrapper for the Ursa libraries
From Wip to Everyone: (11:35 AM) So this is just a node wrapper os ursa?
From Orie Steele to Everyone: (11:35 AM) Can we get the python link added to the session notes?
From Me to Everyone: (11:35 AM) Clare .. link is in slack and here http://eprint.iacr.org/2016/663.pdf
From malwhere to Everyone: (11:35 AM) I believe andrew already linked it
From malwhere to Everyone: (11:36 AM) @Andrewwhitehead can you link to your python code for folks
From Andrew Whitehead to Everyone: (11:36 AM) I’ll add it to the notes Okay, somebody beat me to it
From Nathan George to Everyone: (11:36 AM) Brent Zundel is the guy to follow up with. They did a lot of work on static serialization and data type normalization for cryptographic verifiability. We just want to make sure that part matches up.
From Kyle Den Hartog to Everyone: (11:37 AM) Linked the Python code in the notes
From Nathan George to Everyone: (11:39 AM) So as long as the derived proofs match the upstream credential it flows through
From John Callahan to Everyone: (11:40 AM) Ruby implementation: https://github.com/johncallahan/ruby-jsonld-signatures
From malwhere to Everyone: (11:40 AM) does the ruby implementation have BBS+?
From John Callahan to Everyone: (11:40 AM) no
From malwhere to Everyone: (11:41 AM) okay, its not hard now, Andrewwhitehead wrote the python one really quickly
From Nader Helmy to Everyone: (11:41 AM) Here's the python wrapper mentioned http://github.com/andrewwhitehead/ursa-bbs-py
From Orie Steele to Everyone: (11:41 AM) Looks like it only has Ed25519 and RSA… but if there was a portable binary of the Ursa lib for ruby… it wouldn’t be hard to add support
From John Callahan to Everyone: (11:41 AM) it’s a native implementation but I’d really like to see if we could have a benchmark set of ground truth for canonicalization (and back again) for interop
From malwhere to Everyone: (11:41 AM) Ursa has bBS+ Ursa has lots of signatures Orie
From johnnyfromcanada to Everyone: (11:42 AM) I am a novice regarding ZKP. Is there ZKP for “normal” JSON? What is the delta between basic (?) ZKP, ZKP for JSON, and ZKP for JSON-LD?
From Nathan George to Everyone: (11:42 AM) Another question: how do you prevent maliciously minimal disclosure. A common schema helps you know to ask for the right attributes to prevent you from being misled. I think, as John mentioned, we can find another way to address that, just another loose end to chase down.
From malwhere to Everyone: (11:42 AM) the NodeJS wrapper that Tobias is referring is wrapping Ursa’s BBS+
From Orie Steele to Everyone: (11:42 AM) Yep, my point was Ursa needs binding for ruby / go / java / python / node … then its all the same game :)
From Juan Caballero to Everyone: (11:42 AM) i wanna hear more about domain proofs if there's time
From Micah McG to Everyone: (11:42 AM) Nodejs/typescript project mentioned: http://github.com/mattrglobal/node-bbs-signatures
From Charles Cunningham to Everyone: (11:42 AM) the problem with “normal JSON” is serialising the data in order to hash/sign in an always-reproducible way
From Orie Steele to Everyone: (11:43 AM) http://tools.ietf.org/id/draft-rundgren-json-canonicalization-scheme-00.html
From Charles Cunningham to Everyone: (11:43 AM) JSON-LD provides a deterministic mapping of JSON( + context) to RDF
From Orie Steele to Everyone: (11:43 AM) And with JSON-LD 1.1 it also supports @json literals using JCS
From Kyle Den Hartog to Everyone: (11:43 AM) Nathan, schemas can still be made common through the use of anchoring a schema to IPLD for example. We didn’t see the need to keep the chronological ordering that a ledger provides for schemas.
From Nathan George to Everyone: (11:44 AM) +1 for Stephen, small bite-sized standards let cool new things integrate and take over more quickly. I’m excited for where this can take us.
From Manu Sporny to Everyone: (11:44 AM) This is *awesome*! :)
From Orie Steele to Everyone: (11:44 AM) Yes :)
From Joel Thorstensson to Everyone: (11:44 AM) @Kyle well if you want to have the ability to update and version schemas it might be useful to have chronological ordering :)
From Charles Cunningham to Everyone: (11:44 AM) this is very awesome yeah gonna see how fast I can use this XD
From Nathan George to Everyone: (11:45 AM) We have been working on variable schema credentials and signature improvements for a LONG TIME. Thanks to Mike and Brent and others that worked behind the scenes on the crypto that this builds on.
From Kyle Den Hartog to Everyone: (11:46 AM) Yes, huge thanks to Mike, Brent, and the Sovrin and Ursa communities who have been driving this forward behind the scenes
From Juan Caballero to Everyone: (11:46 AM) +1
From Stephen Curran to Everyone: (11:46 AM) +1
From Charles Cunningham to Everyone: (11:46 AM) +1
From Nader Helmy to Everyone: (11:46 AM) +`
From Kyle Den Hartog to Everyone: (11:46 AM) +1
From Orie Steele to Everyone: (11:46 AM) +1
From Manu Sporny to Everyone: (11:46 AM) +`1
From Oliver Terbu to Everyone: (11:46 AM) Awesome work!
From Nathan George to Everyone: (11:46 AM) Jack++
From Manu Sporny to Everyone: (11:46 AM) q+
From Dmitri Zagidulin to Everyone: (11:46 AM) +1
From Tobias Looker to Everyone: (11:47 AM) +1 so much prior art to recognize!
From Me to Everyone: (11:47 AM) Real kudos to Tobias and team … I am very impressed with the willingness to stare a hard problem down and make a really interesting contribution to the technology .. we are looking forward to collaborating and seeing where this can take us
From Manu Sporny to Everyone: (11:47 AM) http://json-ld.github.io/normalization/tests/index.html
From Nathan George to Everyone: (11:47 AM) John++ Tobias’ team has done some real heavy lifting here.
From Micah McG to Everyone: (11:48 AM) 🎉👌👏
From Nathan George to Everyone: (11:48 AM) Getting this stuff to come together could have great consequences for semantic concepts for decentralized web schtuff
From John Callahan to Everyone: (11:48 AM) Nathan++
From Me to Everyone: (11:49 AM) This is the http://en.wikipedia.org/wiki/The_Structure_of_Scientific_Revolutions … building on the work of others … :)
From malwhere to Everyone: (11:49 AM) that’s what I’m working on
From Nathan George to Everyone: (11:49 AM) Ursa builds to wasm, etc already. The blockers are mostly at the ledger resolver and wallet layers
From Brent Zundel to Everyone: (11:49 AM) speaking for Ursa: we accept PRs
From Juan Caballero to Everyone: (11:49 AM) :flex: emoji
From Me to Everyone: (11:49 AM) ++ to PRs :)
From malwhere to Everyone: (11:49 AM) WASM, Go, Java is what I’m working on
From rileyhughes to Everyone: (11:50 AM) 😂
From Kyle Den Hartog to Everyone: (11:50 AM) ++++++11111 Brent
From Charles Cunningham to Everyone: (11:50 AM) who wants to write a JSON-LD normaliser in rust?
From Andres Olave to Everyone: (11:50 AM) Congrats to all involved
From John Callahan to Everyone: (11:50 AM) a Rust impl would be great
From Nathan George to Everyone: (11:50 AM) _wants_ to or can be cajoled into it?
From Dmitri Zagidulin to Everyone: (11:50 AM) @Charles - depends on your budget :) (re normalizer in rust)
From Charles Cunningham to Everyone: (11:50 AM) XD
From Manu Sporny to Everyone: (11:51 AM) No, seriously, organizations need to start funding this stuff. :)
From Kyle Den Hartog to Everyone: (11:51 AM) Rust doesn’t have the greatest JSON-LD implementation so far. There’s a half baked implementation, but it could use some love too.
From Charles Cunningham to Everyone: (11:51 AM) I’d like to tbh because having as much as possible in a warm bundle would be awesome
From Manu Sporny to Everyone: (11:51 AM) haha, love the snail onto a turtle reference.
From Charles Cunningham to Everyone: (11:51 AM) yeah I saw that impl but its abandoned :(
From John Callahan to Everyone: (11:51 AM) I’m not volunteering for this, but how about a DSL using LLVM that could compile into different native language impls instead of a language-by-language approach. Just an idea...
From Nathan George to Everyone: (11:53 AM) Jack: Seen that multiple times, it isn’t pleasant. That is why I support Rust, it gets you most of the way to that without having to deal with the DSL.
From John Callahan to Everyone: (11:53 AM) You are probably right, Nathan. It would be complex
From Nathan George to Everyone: (11:53 AM) Find David Huseby in a hallway track, he will have you convinced.
From John Callahan to Everyone: (11:54 AM) :-) I know Dave
From Manu Sporny to Everyone: (11:54 AM) +1 to CCG... we might be able to get it into the LD Security WG if it's in good shape.
From Nathan George to Everyone: (11:54 AM) Then you should already believe ;)
From Juan Caballero to Everyone: (11:54 AM) domain proofs?
From Dominic Wörner to Everyone: (11:54 AM) Could yo
From Nathan George to Everyone: (11:55 AM) Manu++ the idea that any-old-data gets selective disclosure provability seems exciting in a “be careful what you wish for” sort of way
From Manu Sporny to Everyone: (11:55 AM) yep
From Dominic Wörner to Everyone: (11:55 AM) Could you say something about the advantages comparing to selective disclosure with signing a merkle tree of claims
From Manu Sporny to Everyone: (11:55 AM) it's the corner cases that are worrying :) -- but we have something to latch onto now :)
From malwhere to Everyone: (11:55 AM) flexibility
From Nathan George to Everyone: (11:55 AM) Its much more efficient from a signature standpoint as well
From malwhere to Everyone: (11:56 AM) ^^ @Dominic merkle proofs are large
From malwhere to Everyone: (11:56 AM) BBS+ is very efficient 100 attributes in a BBS+ only yields a 3.3Kb proof an that’s if you hide every attribute it goes down as you reveal attributes
From Nathan George to Everyone: (11:57 AM) You don’t want to have to define the disclosures that are possible or not possible up front, you want to be able to mix and match at presentation time, its harder to do that with merkle signatures
From John Callahan to Everyone: (11:57 AM) Awesome session… gotta 3pm EDT meeting now. BYE!
From Dominic Wörner to Everyone: (11:57 AM) +1
From Orie Steele to Everyone: (11:58 AM) Yes, Mattr is f***ing crushing it :)
From Rouven Heck to Everyone: (11:58 AM) +! Orie :)
From Juan Caballero to Everyone: (11:58 AM) +1
From Manu Sporny to Everyone: (11:58 AM) +1
From Xavier Vila to Everyone: (11:58 AM) +1
From Charles Cunningham to Everyone: (11:58 AM) +1 yeah Mattr with JWM as well, amazing
From Juan Caballero to Everyone: (11:59 AM) great paper awesome thanks
From Stephen Curran to Everyone: (12:05 PM) +1 to session on Indy and BBS+ to figure out what type of path we might want to follow.
From malwhere to Everyone: (12:05 PM) +1
From Brent Zundel to Everyone: (12:05 PM) incorporating bbs+ ld-signatures into Aries/Indy would be a session I'd be very interested in as well
From Juan Caballero to Everyone: (12:05 PM) +1
From mario Bonito to Everyone: (12:06 PM) +1
From Charles Cunningham to Everyone: (12:06 PM) +1
From Andrew Whitehead to Everyone: (12:08 PM) Maybe a technical session on range proofs & the JSON-LD approach
From Micah McG to Everyone: (12:08 PM) bbs+ ld-signatures => indy +1
From Juan Caballero to Everyone: (12:08 PM) I was saying Booo-urns! I was +1ing bbs+ ld-signatures => indy/ARIES, fwiw :D
From Drummond Reed to Everyone: (12:09 PM) Schemas should be able to have DIDs.
From Dmitri Zagidulin to Everyone: (12:09 PM) q for @Kyle - schemas don’t need to be chronologically ordered, but do they need to be (sem) versioned?
From Rouven Heck to Everyone: (12:09 PM) +1 Kyle - ledger agnostic
From Nathan George to Everyone: (12:09 PM) Careful with that generalization, ordering on those objects have some benefits to protect against broken entropy problems, but generally I agree.
From Charles Cunningham to Everyone: (12:09 PM) their versioned editions should remain immutable (like all versioning ideally), so a CAS seems fine right?
From Kyle Den Hartog to Everyone: (12:09 PM) Potentially and with the use of IPLD the CAH should change by doing that meaning a new IRI should be produced I believe
From Nathan George to Everyone: (12:10 PM) The bigger issues to address are around trust for data subsets without a complete data definition And how immutability affects that trust
From Nathan George to Everyone: (12:11 PM) You need to be careful to preserve independence between the issuer and verifier (including data access or DoS concerns)
From Andrew Whitehead to Everyone: (12:11 PM) I’d prefer a DID URL to a DID ;)
From Kyle Den Hartog to Everyone: (12:11 PM) Yup, and I believe immutability is valuable, but not necessarily the chronological ordering which is why I was thinking IPLD seems like a natural fit for this.
From Andrew Whitehead to Everyone: (12:12 PM) (or DRI)
From Drummond Reed to Everyone: (12:12 PM) Why would you prefer a DID URL to a DID if the DID took you directly to the immutable object?
From Rouven Heck to Everyone: (12:12 PM) yeah, immutability + context addressing
From Drummond Reed to Everyone: (12:12 PM) +1 to the immutability
From Orie Steele to Everyone: (12:12 PM) I prefer to use a URI… which might be content addressed… but might not be.
From Charles Cunningham to Everyone: (12:12 PM) yeah IPLD seems ideal, the DID approach it seems would also be immutable but brings in a variety of DID methods which are not really necessary I think
From Dominic Wörner to Everyone: (12:13 PM) Is a schema really the same as a ld context? The schema could tell what me what is required in a credential. The context tells me what attributes could be expected
From Drummond Reed to Everyone: (12:13 PM) “trust framework” = “governance framework”
From Joel Thorstensson to Everyone: (12:13 PM) What we do with Ceramic is creating updatable documents on IPLD which allows for versioned schemas :)
From Drummond Reed to Everyone: (12:13 PM) Cool!
From Charles Cunningham to Everyone: (12:13 PM) ^^ similar to like Tupelo? e.g. deltas on a piece of data as IPLD fragments?
From Andrew Whitehead to Everyone: (12:14 PM) @Drummond maybe it’s old fashioned but I like when a DID resolves to a DID doc, not a schema
From Joel Thorstensson to Everyone: (12:14 PM) Similar to Tupelo, but anchored on blockchains :)
From Nader Helmy to Everyone: (12:14 PM) ceramic network https://github.com/ceramicnetwork/specs
From Charles Cunningham to Everyone: (12:14 PM) very nice
From Dmitri Zagidulin to Everyone: (12:14 PM) @Dominic - re the difference between a schema and a context — so, there is SOME overlap, in the venn diagrams between them? But like you said, their purpose is somewhat separate.
From Dmitri Zagidulin to Everyone: (12:15 PM) @Dominic a @context is more of a ‘schema migration map'
From Drummond Reed to Everyone: (12:15 PM) @Andrew, the specific proposal is for the immutable object you are identifying to be IN the DID document you get back.
From Dmitri Zagidulin to Everyone: (12:15 PM) or like.. definition migration.
From Manu Sporny to Everyone: (12:15 PM) q+ to suggest we should change the spec!!! :)
From Charles Cunningham to Everyone: (12:15 PM) ooooohhhh ceramic === 3box all is clear now
From Joel Thorstensson to Everyone: (12:15 PM) :-) Will have a session on how Ceramic works in session 4
From Drummond Reed to Everyone: (12:16 PM) Brent and Ken Ebert came up with a very elegant proposal for doing just that for any immutable object you can render in a DID representing.
From Nathan George to Everyone: (12:16 PM) I like the idea of normalizing those into JSON-LD type language so they can be inline or referenced, then we get more awesomeness
From Drummond Reed to Everyone: (12:17 PM) Drummond just fainted :-)
From Nathan George to Everyone: (12:17 PM) Inlining has disclosure consequences, so yeah...
From Orie Steele to Everyone: (12:17 PM) Let the battle begin
From Nathan George to Everyone: (12:17 PM) It was Manu that said it, that means he will lead the effort right? ;)
From David Waite to Everyone: (12:18 PM) +1
From Manu Sporny to Everyone: (12:18 PM) haha, definitely not. :)
From Orie Steele to Everyone: (12:18 PM) We got this.
From Manu Sporny to Everyone: (12:18 PM) Parallel == more efficiency gains.
From johnnyfromcanada to Everyone: (12:18 PM) Thanks!
From Dmitri Zagidulin to Everyone: (12:18 PM) lol
From Manu Sporny to Everyone: (12:18 PM) http://github.com/msporny/dna clone instructions there ^^^
From Me to Everyone: (12:18 PM) Thanks all!!!
From Brent Zundel to Everyone: (12:18 PM) perfect!
From Me to Everyone: (12:19 PM) I captured the chat For the notes I expect
