The Private Blockchain Fallacy - <AUTHOR> https://berk.es/2018/09/19/the-private-blockchain-fallacy/ <comment><USER2> I've worked on private blockchain solutions for financial firms (in supply chain and commodity trade finance). The reason companies are doing these projects is because in a lot of scenarios no one trusts each other. Even if they do, there are not allowed to for legal and compliance reasons. As such huge parts of the industry are paper based. Because if there was a simple MySQL solution from a company they would have gone with that 2 decades ago.

The article talks about reasons for wanting a private blockchain. But I have never heard any of these reasons come up in any of my projects. I'm not sure what projects the author is talking about, but definitely not anything related to what most private blockchain projects companies are doing. That said there is a lot of hype in the space (not denying that).

You can make an argument that bitcoin in the whitepaper was defined as an open access system, and as such any closed access system is not a blockchain. Sure, but the developers on these projects (like me) are calling them blockchains nonetheless because most the of the tech is the same (except for things like consensus forming, you probably would never use PoW in a private blockchain).

\----

Companies are looking into private blockchains because they allow for systems where not one party is in charge of all the data and the network. But they require more than an append only log.

<comment><USER3> They might not trust each others but if they know each others, why can't they simply use a public private key solution? For a transaction to be valid it needs to have been signed by both parties.

<comment><USER4> They can and do. What's most useful about blockchain tech is the eventually immutable chronological ordering bit.

As an example, 2 parties can enter into a contract. The contract details are signed by both parties. The contract is placed on a blockchain that's visible to both parties and any interested regulators etc. You can even use the same chain for multiple competing parties simply by encrypting the contracts.

Note, this isn't acting as a transaction in the Bitcoin sense. It's simply using the basic mechanism of linked, hashed blocks to establish a permanent time-ordered ledger.

Time passes. Now, if there's any dispute, all parties have a shared view of exactly what occurred when. It's not practical to manipulate it as the parties know who they all are and can easily resort to external measures.

But it does solve a huge, very expensive problem that financial institutions and regulators have: a single, shared version of the truth. This is a multi- million dollar problem and blockchain tech can definitely be part of the solution.

<comment><USER5> > They can and do. What's most useful about blockchain tech is the eventually > immutable chronological ordering bit.

> As an example, 2 parties can enter into a contract. The contract details are > signed by both parties. The contract is placed on a blockchain that's > visible to both parties and any interested regulators etc. You can even use > the same chain for multiple competing parties simply by encrypting the > contracts.

> Note, this isn't acting as a transaction in the Bitcoin sense. It's simply > using the basic mechanism of linked, hashed blocks to establish a permanent > time-ordered ledger.

For this, you do not need a blockchain. Instead hashed and signed non-cyclic data structures suffice (e.g. hash lists [1], hash chains [2], hash trees). Note that the Merkle trees ([3]) that are used in Bitcoin are special cases of hash trees.

According to [3], "[t]he concept of hash trees is named after Ralph Merkle who patented it in 1979.".

What do blockchains solve that cannot be solved by these data structures that are 40 years old? The answer is: decentral consensus when the parties cannot trust each other. This was the missing building block that was necessary to build a decentral cryptocurrency.

[1] [https://en.wikipedia.org/w/index.php?title=Hash_list&oldid=8...](https://en.wikipedia.org/w/index.php?title=Hash_list&oldid=816273346)

[2] [https://en.wikipedia.org/wiki/Hash_chain](https://en.wikipedia.org/wiki/Hash_chain)

[3] [https://en.wikipedia.org/w/index.php?title=Merkle_tree&oldid...](https://en.wikipedia.org/w/index.php?title=Merkle_tree&oldid=856193562)

<comment><USER4> > This was the missing building block that was necessary to build a decentral > cryptocurrency.

Indeed. But if that's not what you want then you can drop that bit and use the rest.

If your point is that nothing stopped people doing this a generation ago, if they'd thought about it, then I agree completely.

But the key bit is they didn't think about it (or think it was sufficiently important). What Bitcoin did was publicize the techniques and, crucially, show that the interesting bits work well.

Of course, if you choose to use a definition of blockchain that involves trustlessness then the usage I described isn't blockchain, by definition. By I tend to use Satoshi's definition, more or less, which is orthogonal to the idea of trust.

<comment><USER5> > If your point is that nothing stopped people doing this a generation ago, if > they'd thought about it, then I agree completely.

> But the key bit is they didn't think about it (or think it was sufficiently > important).

My opinion on this topic rather is: everything (except how to build decentralized trust) has been known for a long time. It is also known for a very long time that these techniques work well (otherwise Satoshi Nakamoto would never have come up with the idea to make them a central piece of Bitcoin). The central reason why it wasn't implemented before rather was that the people who knew about it did not have the charisma to convince "the people with money" that they should finance an implementation.

For example, already in 1989, there was an attempt to build a digital anonymous (though not decentral as far as I know) currency called DigiCash by David Chaum:

> > [https://en.wikipedia.org/w/index.php?title=DigiCash&oldid=83...](https://en.wikipedia.org/w/index.php?title=DigiCash&oldid=838558773)

What happened to them? This company simply went bankrupt in 1998.

<comment><USER6> DigiCash lacked the novel, decentralized proof of work consensus introduced by Bitcoin and I also suspect the general public was much better able to participate with 2008 broadband than what we had 1998

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> If the author is reading this, the most interesting thing about your article is that it creeps towards the recognition of something important (i.e. that data ordering and data permanence are quite different things) before it balks at the implications and adds unnecessary properties to its definition of a blockchain.

This makes the piece come across ideological. As a case in point, you write that the public aspect of a blockchain is what ensures its permanence but that is not at all the case. The public aspect is what guarantees open access. Open access in turn guarantee decentralization under conditions where decentralization is economically feasible. The only thing that guarantees permanence is the economic incentive structure that pays participants to store and distribute data.

We don't have a good taxonomy for discussing these ideas yet, but most people working on scale are beyond this. Ethereum is experimenting with rent. Bitcoin variants exist which have adjusted their genesis block manually. Some layer- two networks are designed be transient, while Saito uses a transient blockchain to put bandwidth-intensive applications directly the first layer. The direction of development in the space is tilting very clearly towards utility networks and disposable data-structures. The disagreement is over at what layer this needs to take place, and how to preserve things like open access while paying for things like bandwidth and storage.

<comment><AUTHOR> Thanks for your summary. Indeed it is very hard to explain these ideas, because so many terms are still vague, missing or explained in often contraditing ways.

I think, indeed, that with "permanence" i've made the mistake to pull that together with "immutability". My first draft had them as different points, but I found that this made the explanation too complex. So I decided to go only for "immutability" and to move the "permanence" under there.

In your definition of permanence (the correct one, BTW) this is not the same. Permanence needs economic incentives. As we can see with IPFS (and it not -yet- being permanent in practice). Immutability, however, needs (i) cryptography and (ii) conflict resolution and (iii) permanence. Which implies "being public". As I tried to explain.

Or did I misunderstand your comment, and do you mean immutability as well as permanence?

<comment><USER7> I really just wanted to comment because almost no-one gets what you wrote about the importance of data-ordering. So the piece started strong, but then felt like it started tripping over itself.

On the permanence/immutability issue, I guess my opinion is that permanence is distinct from immutability and that while all blockchains require immutability, they can exist with varying degrees of data persistence. I tend to think bitcoin would be perfectly safe running on a 100 year chain with periodic hardforks to upgrade the genesis hash, for instance, and that it would be a bit strange to suggest that this wouldn't count as a blockchain, even if the trade-offs would make the network lose some properties of "digital gold". At a minimum, arguing otherwise would seem to imply that UBTC isn't a blockchain, which is obviously wrong.

</comment></comment></comment><comment><USER8> I've worked for a company obsessed with blockchains. What really happens in my experience is that some clueless business person tells the boffins to work on it, because they're super scared of the hype that this new tech might destroy them. But they don't understand it all.

Exercise for the blockchain advocates: explain as simply as possible why a "private blockchain" is better than Git.

<comment><USER2> > Exercise for the blockchain advocates: explain as simply as possible why a > "private blockchain" is better than Git.

Because with git you either go:

\- The linux way with one upstream and everyone branching of the "main" repo: In a lot of ways everyone is relying on the centralized main repo of linux, and in every other way they disagree on the final state (eg. the final code).

\- The "github" way where there is one version hosted on a centralized service that everyone needs to trust.

Beyond the obvious security problems when trying to use git for actually important data ( for example: [https://shattered.io/](https://shattered.io/) ), git doesn't help you in any way to come to a consensus about what happened and in what order. Instead it gives tools to rewrite history as how you see fit (like rebase).

<comment><USER8> Basically in both cases the problem is a centralized repo, right? That's not really a problem with signed commits though, is it? E.g. Google's certificate transparency or Keybase. At this point we are arguing over the definition of Git vs private blockchain though. I just don't get the hype. Merkle trees have been around since the 70s.

<comment><USER2> Well in the first case the problem is the lack of centralized repo: there are a million and one forks of linux, and they are all linux however they have all different code (Linus maintains the one that most people call linux, but there all Linux nonetheless). Imagine if it wasn't code, but financial data that would not really work.. The problem with git is that it doesn't allow you to form any consensus with a group of people (that you can't always trust). git's answer to 2 people committing to the same file is to throw a merge conflict in your face: Git is saying: I can't figure out what the truth anymore, so please tell me. That only works if you can trust everyone.

> Merkle trees have been around since the 70s.

Blockchains didn't reinvent many things, 95% of a blockchain is basic cryptography. Merkle trees are awesome and they are used as well (for example when grouping transactions into blocks within Bitcoin). The reason why you need more than a merkle tree is because a merkle tree doesn't help you if:

\- You can't trust one single party to maintain (or host) the whole thing: yes you can use digital signatures to make sure they don't forge what you said. But what if they deny you access and ignore your messages? What if they change the order people said things? A merkle tree can't protect you from this.

\- You need to agree with other people in what order certain things happened, this is a hard problem in networks / distributed systems. Especially if you have actors trying to manipulate this very thing.

\- You need to align incentives in a way that breaking the complete system is infeasible from a financial point of view.

\----

Take Bitcoin as an example, a (kind of) anonymous payment system in the internet, the only things protecting everyone's money are public/private cryptography and the costs involved with rewriting history (51% attack). Bad actors attack it every day, but no matter who's door the police kicks in you only have to trust cryptography (the only other weak link is your personal private key, so if you they hit in your door - but there is no other middlemen).

> I just don't get the hype.

There is a ton of hype, and whether it's valid or not depends on if the world needs such a system. Blockchain proponents say that once you have a stable decentralized system that can run any code and cannot be corrupted in any way, you will see innovation flourishing similar to the internet: the internet brought complete freedom of information (and industries build on top were not imaginable in the 80s), some people think the blockchain will bring freedom to anything that is (or should be) scarce. Like money and commodities.

<comment><USER8> To be clear, what are you trying to convince me of? The target keeps moving. Are you trying to convince me that a blockchain is needed instead of Git for a currency like Bitcoin? In that case I agree. In fact I conjecture that blockchains are only useful for cryptocurrency. Or, are you trying to convince me that a blockchain is useful for businesses for something like "the supply chain" or whatever, without any cryptocurrency? If so, then I disagree. But please be clear.

If you're arguing for the latter, then try to explain to me as simply as possible how a blockchain with "proof of authority" is better to Git with signed commits. Or CT. Or Keybase. It seems that these business blockchains are inefficient, append-only Merkle trees. It's not particularly novel, and replicating the database across all nodes of the network and constantly engaging on a consensus protocol to agree on the state of the network while all peers are trusted anyway with proof of authority seems quite useless.

If I am wrong, then the blockchain people can do themselves a favour and make a simple comparison chart of their solution compared to possible alternatives. But I don't think they want to do thst. I think they baffle non-technical people with words like "decentralised", and "cryptographic signature" and polish it nicely until people believe in them. Just try reading Alex Tapscott's book "The blockchain revolution". I think it is snake oil. The emperor's new blockchain.

<comment><USER2> > To be clear, what are you trying to convince me of? The target keeps moving. > Are you trying to convince me that a blockchain is needed instead of Git for > a currency like Bitcoin? In that case I agree. In fact I conjecture that > blockchains are only useful for cryptocurrency. Or, are you trying to > convince me that a blockchain is useful for businesses for something like > "the supply chain" or whatever, without any cryptocurrency? If so, then I > disagree.

I just went on explaining why you want to use a blockchain (private or not) instead of git. It's a broad question so you'll get a broad answer. This is the only thing I went into:

> Exercise for the blockchain advocates: explain as simply as possible why a > "private blockchain" is better than Git.

I haven't talked about anything else. If you want to know what people think about using blockchains for A and B, you should ask that instead. My target hasn't moved at all.

> try to explain to me as simply as possible how a blockchain with "proof of > authority" is better to Git with signed commits.

I specifically explained where an append-only merkle tree doesn't cut it in the comment you just replied to (my previous one). Note that git is an append- only merkle tree. You are more than welcome to go into my points.

> It's not particularly novel, and replicating the database across all nodes > of the network and constantly engaging on a consensus protocol to agree on > the state of the network while all peers are trusted anyway with proof of > authority seems quite useless.

If all peers are completely trusted you are 100% correct, if you trust everyone completely you don't need a blockchain. However in the real world trust isn't binary. If a bunch of banks KYC each other and go into a blockchain consortium, they do this specifically because they don't trust each other enough. Else they would have gone with a straight forward solution like git a decade ago.

<comment><USER8> You talked about bitcoin. That's entirely different to a "private blockchain". So that is why I think the target keeps moving in this conversation. Or are you suggesting proof of work or something? If so, then I am exiting out of this conversation :-)

Anyways, perhaps a better exercise to clarify would be: Find a single example where a (precisely defined) type of blockchain makes sense vs possible alternatives such as solutions along the lines of Git, CT, etc. I conjecture that there are none beyond cryptocurrency.

<comment><USER2> > You talked about bitcoin. That's entirely different to a "private > blockchain".

I never said they were the same, however the similarity is that they are both blockchain systems. And you cannot achieve the same with git for exactly the same reason (you cna't trust all parties).

> Or are you suggesting proof of work or something?

Nope, definitely not. Not sure what made you think that?

> Find a single example where a (precisely defined) type of blockchain makes > sense vs possible alternatives such as solutions along the lines of Git, CT, > etc. I conjecture that there are none beyond cryptocurrency.

There are loads all over commodity trade finance and supply chain (the field I have experience). But I've spend an hour typing an answer out your initial question:

> Exercise for the blockchain advocates: explain as simply as possible why a > "private blockchain" is better than Git.

And now you state you aren't really interested in that explanation and want to have clarification on something completely different.

I'm done with typing out "examples and clarifications" when as soon as I do you start asking a different question, never going into my points. So "I am exiting out of this conversation :-)"

<comment><USER8> I know why you would use a blockchain: for cryptocurrency like bitcoin. As I say, I conjecture there are no other applications.

You made me think you might be suggesting some proof of work scheme instead of "proof of authority" because the example you chose was bitcoin. You also said: "You need to align incentives in a way that breaking the complete system is infeasible from a financial point of view.". So that's why I thought of it. Apologies if I was mistaken.

I don't quite understand why this conversation is getting heated for you. Perhaps because it is your career so you feel personally attacked or something. That's not my intention. Anyways, I'm still none the wiser as to why to use a "private blockchain". Blocking commits or whatever isn't really solved by a private blockchain. You don't need a blockchain for the problem of changing the order people said things either. And how many banking consortia were really moaning about these issues before a blockchain came along? A blockchain seems like a solution looking for a problem most of the time.

Comments like this:

> Blockchain proponents say that once you have a stable decentralized system > that can run any code and cannot be corrupted in any way, you will see > innovation flourishing similar to the internet: the internet brought > complete freedom of information (and industries build on top were not > imaginable in the 80s), some people think the blockchain will bring freedom > to anything that is (or should be) scarce. Like money and commodities.

Comparing blockchain to the internet? I think that is just crazy la la land. I _really_ hope I'm wrong because that sounds amazing. (Although I have no idea what "that" is, but the internet was a good thing and I like good things.) But I'm definitely not.

But anyways I agree with you that we should stop.

<comment><USER2> Not going into the topic, just the discussion itself.

I'm totally fine, hope you are too. I don't feel personally attacked at all. But on the internet a thick skin is required. I hope you don't feel attacked either.

> Anyways, I'm still none the wiser as to why to use a "private blockchain" > but I agree with you that we should stop.

That's unfortunate, I hope you do understand one day. I won't go into it now since you started with a different question (or technically an exercise). And after my lengthy attempt in explaining it you expressed that you don't actually care and instead ask questions about consensus algorithms used in different blockchains (like PoW and PoA) - which has nothing to do with why one uses a blockchain and not git.

So please next time if you are interested in something, don't start by asking something else. After that trying to steer the conversation towards your hidden objective all while you are accusing the other side of "moving the target" (you are moving the target from git towards consensus algorithms and blockchain use cases).

<comment><USER8> I hope I understand too. I hope blockchains become as useful as the hype suggests. But I bet my career on it that it won't. Let's set a reminder for 10 years and see what happens? :-) We could bake a bet into a smart contract. (Actually we probably couldn't.)

<comment><USER2> Honestly I'm also quite skeptical, I share your view.

Though I believe the deciding factors aren't very technical. For public projects it all depends on what people want (in reaction to government control, surveillance, financial and capital controls)

And for private blockchains in my experience (in finance anyway) it all depends on the regulators and what they will allow. They are also reacting to whatever is happening in the world.

Currently it all looks pretty bleak indeed.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Blockchain definition from article: _a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions_

Context from referred Nakamoto pdf: _In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions_

So this is not definition of blockchain by Nakamoto (There is no term blockchain at all in this pdf)

Definition from wikipedia (I agree with): _A blockchain is a growing list of records, called blocks, which are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a merkle tree root hash)_

From this definition git is also kind of blockchain.

So its hard to follow article with such vague definition from start.

<comment><AUTHOR> There is, this though.

> chain of hash-based proof-of-work

and

> chain of blocks

in this paper. His later communication does call this "block chain".

So you are right that he/them/she does not use the term "blockchain" in the paper. Nor "block chain" but the term can be extracted from there clearly.

</comment></comment><comment><USER10> It's a good time to point out that "permissioned" blockchain does not have to mean a "private" blockchain. While the validator nodes may be a whitelisted group, anonymous users can still be allowed to run observer nodes.

This is the approach the erstwhile InterPlanetary database was planning to take. IPDB shut down earlier this year. Some of us really wanted this so we're setting up an Ethereum-compatible, permissioned+public blockchain called Indium.Network: [https://indium.network/](https://indium.network/)

<comment><AUTHOR> Honestly curious what that solves, and how that would work.

If it is permissioned, does that not essentially mean its write-side is "private"?

What can an observer now _do_ in case the whitelisted entities decide to change history, other than tweeting about it? I'd argue that if the observer now has power to eject the rogue entity/ies from their power, it is a public system. Just via a separate layer.

And if it is permissioned, does that not automatically mean it is centralized?

<comment><USER11> >If it is permissioned, does that not essentially mean its write-side is "private"?

Not parent, but yes.

>And if it is permissioned, does that not automatically mean it is centralized?

That depends on your definition of centralized: if you mean "under the control of humans" then yes it does. If you mean "under the control of one human" than no it doesn't.

For example a common approach is to designate a set of institutions (e.g. not for profit foundations in several different countries) to be in control of the validating nodes. Under that model a quorum of those institutions would need to be subverted in order to censor transactions.

<comment><USER10> Yes, "non-profits with political, jurisdictional, legal diversity" is pretty much the approach we plan to take. In fact, to begin with we'll be borrowing from Sovrin (decentralized identity)'s governance model.

</comment></comment></comment></comment><comment><USER12> For most companies, securing funding and getting exposure in the media is significantly more important than using technically correct terminology to describe the implementation details of their product.

</comment><comment><USER4> Interesting logic. The author quotes Satoshi's definition of blockchain which doesn't preclude private blockchains at all.

He then quotes a "more accessible" definition that explicitly precludes private blockchains. So fine, if you define blockchain as being open then, sure, it can't be private.

He then has a flowchart that doesn't refer to either definition and follows that with a set of reasons why people want a private blockchain and refutes them. Two of these are fine: private data and access control. Two of these are just plain strawmen: scaling and confidence.

And of the 2 reasons that do make sense he makes clearly incorrect statements:

> A blockchain has to be public in order to ensure permanence or immutability.

No it doesn't. A restricted group of people can use identically the same features that a public blockchain has to manage eventual immutability. If that weren't true then it would imply that, say, the Bitcoin blockchain would not have it's current immutability properties if only its current users could access it. But that's simply not true.

> A blockchain has to be permissionless in order to ensure permanence.

Again, no it doesn't. Just because you restrict who writes to the end of the chain says nothing about the rest of the chain.

Now, it would be a reasonable argument to say that the useful properties of a blockchain are only available to people who have read access to the whole blockchain. And I'd agree with that. But he's not making that argument, as far as I can see, so his actual argument is either tautological or verifiably wrong.

<comment><AUTHOR> > the Bitcoin blockchain would not have it's current immutability properties > if only its current users could access it. But that's simply not true.

Interesting point. But I think this evolves around what makes "private" and what not. Is a network of ~10.000 anonymous nodes "private" if you now close it? I guess it would be called "permissioned" and not "private".

Further, my point is that when you would close the current network and disallow anyone to write and read from it, other than the currently online ~10.000 nodes, disallow new wallets and participants (making it private) you'd loose three things, essentially rendering the blockchain unusable: breaking it's immutability:

* There would be no new miners.

* There will be no increase in usabiltity: no future gain.

These two things will logically cause centralisation of the existing mining. After all: no new miners can join, and only miners can drop out.

A typical "private blockchain" so not one that started out public, grew large and then turned private, but one that starts out private, therefore has no need for PoW at all: it makes no sense, and adds no security that is not already there (through enforcements of access controls). Hence either the PoW is just nonense and (even more so) a waste of energy. Or it is left out.

And a blockchain without a PoW is just a DAG tree. Or cryptographically signed logbook.

Which can be useful in itself. But which is not a blockchain.

</comment></comment><comment><USER13> I think there is a space for private (or permissioned) blockchains and there are a few techniques that allow such a chain to inherit the trust of a public blockchain such as Bitcoin or Ethereum (side-chains, Plasma, etc) so that it's possible to use cryptocurrencies or other popular tokenised assets in a private setting without users having to trust the owner of the private chain itself.

In such scenarios, the role of block producer is centralised and limited to the owner of the private chain which means a less power-hungry consensus mechanism such as Proof of Authority can be used and have block interval times in the milliseconds.

A project I've worked on recently aimed at delivering a similar solution in a global company that has historically grown through acquisitions and mergers where the IT systems never fully integrated, meaning that despite operating under the same name, there are hundreds of BUs that don't "trust" each other.

</comment><comment><USER14> I loved _Doré Woodcut. Its only function is to make the layout look better. And these images are really nice themselves_

</comment><comment><USER15> There's a similar flow diagram in a 2017 paper titled "Do you need a Blockchain?" [1] which identifies 3 types of blockchain:

* Permissionless Blockchain

* Public Permissioned Blockchain

* Private Permissioned Blockchain

[1] [https://eprint.iacr.org/2017/375.pdf](https://eprint.iacr.org/2017/375.pdf)

<comment><AUTHOR> I (author) have read this paper, and think it is only partly correct.

However, the article describes a lot of examples that are clearly not blockchains, but cryptographic interesting solutions like a ledger that gets distributed amongst all observers. It even often concludes that "this is not a blockchain". But then goes on to call it "blockchain solutions like this".

If the paper would stop abusing the word "blockchain" for "anything with cryptography", and instead use more precise terms, it would be a very good paper. And it would underwrite what I am trying to say:

There's loads of interesting data-structures to solve many interesting problems that industries have. Lets' call them what they are instead: DHTs, DAGs, Merkle Trees, Pub/Sub buses, etc.

</comment></comment><comment><USER16> I think this is semantics, many people are talking about distributed ledgers more than Blockchains specifically.

"A distributed ledger (also called a shared ledger, or distributed ledger technology, DLT) is a consensus of replicated, shared, and synchronized digital data geographically spread across multiple sites, countries, or institutions." [1]

[1] [https://assets.publishing.service.gov.uk/government/uploads/...](https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/492972/gs-16-1-distributed- ledger-technology.pdf)

<comment><AUTHOR> But is a "distributed ledger" a blockchain?

Nowhere in my article did I say that "private distributed ledgers" are nonsense (allthough, writing it down gives me cringes).

But the whoe focus on "terminlogy" is in my article for pricesly this reason. I am not talking about how it is silly to have your excel sheet shared amongts a predefined set of participants using fancy bittorrent-streams (a distributed ledger).

But that a _blockchain_ being private is nonsense.

And allthough your average marketing department might hate to hear it, but your distributed ledger is quite certainly not a blockchain.

</comment></comment><comment><USER17> Looks like another overly simple blockchain article. The author lists a bunch of reasons why someone might want to use a private ledger and then dismisses all of them without any argument. Here's a whole bunch of reasons why private ledgers make sense in some context:

\- Control read / write - A list of companies in a consortium might like to maintain shared settlement resources but don't trust a single party for consensus. A private ledger offers a genuine improvement in security over other technologies during a breach. I.e. imagine if there are machines being controlled by authorized humans working with contracts on the private ledger. Hacking a few servers there isn't going to compromise the contracts which is really cool.

\- Scale better (scrap the distributed part) - Some of the newer ledgers are doing exactly that. When you cut node count it does reduce decentralization but the trade-offs are on a gradient. Again, not necessarily an incorrect choice. Look at something like Ricardian contracts on Corda for settling bank deals. The actual "settlement" isn't done on the ledger at all. All that occurs on Corda is a beautiful way to craft financial contracts that will be easier to audit by regulators. Private ledgers all help with that and would benefit from not using an entire flooding-based p2p network to do it.

\- So we can store private data - There are many companies and institutions that need to store private data. One can imagine advertising companies sharing demographics or hospitals sharing medical records. There's nothing novel here about acting as a database. What the author fails to grasp are some of the more subtle aspects of distributed ledgers. Like the more nuanced trust relationships between companies or business requirements (upgrading old technology, sharing the costs, incentivized standardization.)

Caveat: distributed ledgers are not blockchains. But my problem with this article is the blockchain fanaticism mixed with the authors seeming inability to think outside of black and white terms. He dismisses everything about enterprise ledger technology that doesn't fit in his narrow definitions and can't see any of the nuances of using them. The result is a person who fails to understand either public blockchains or private ledgers very well (like most people it seems.)

<comment><AUTHOR> > distributed ledgers are not blockchains.

Author here. Thanks for your criticism.

I think you are making my point too. And you do touch on the reason why I focused so heavily on the "terminology part".

What irritates me, is that anything "crypto" is suddenly called "blockchain". Signing transactions and including a pointer to a predecessor is not a blockchain, it's a DAG and we use it daily (git).

"Distributing your data" maybe even using merkle trees, is not a blockchain. Its "distribution". An interesting and broad subject in itself. Distributing a ledger is hardly new, though still a field very much in motion.

All the things you describe are really very interesting fields often tremendously complex.

They all usepieces of tech found in a blockchain too. But then again: the whole basis of bitcoin is really just a combination of existing tech put together in a novel architecture.

Many of the things you describe (like distributed ledgers) require quite novel concepts and most of all leaning heavily on cryptography. But none are "blockchain".

</comment></comment><comment><USER18> Contrary to what is claimed in the final section, BitTorrent is not actually an implementation of Merkle trees.

Because there are no trees.

The hashing used in BitTorrent metainfo files works by splitting the concatenation of all constituent files into equally sized blocks, individually hashing each block (using SHA1), and concatenating the hashes. Paths and sizes for all the files are also stored, but separately from the hashes.

</comment><comment><USER19> Isn't this all definition?

It seems reasonable for three companies to create a block chain only they see. It is public, in a sense, because the transactions span different trust domains. It is not public because it is not on the open internet like Bitcoin.

Multi company blockchains are the primary use I know of the term 'private blockchains'.

I don't see anything in this paper which argues against this...

<comment><AUTHOR> Well no, because for these cases the most important thing that a blockchain solves needs not be solved.

PoS (or PoW) are not needed because there is no sybil attack nor a byzantine- general problem to be solved. In fact, most "Private Blockchains" ditch the PoW and therefore can claim "tremendous scaling" or things like that.

Ditching the PoW solves most of the scaling issues. Sure.

But a blockchain without a PoW is simply a log that is cryptographically signed (but not secured). Because I could very easily just change block #2 and simply accept the cascading effect. People familiar with Git use this principle every day. A git --amend and git push --force is exactly this.

Once you can convince the participants in your private network (your colleagues) to use your branch, history has been rewritten. (And the old work is just one garbage-collection away from being forgotten forever).

So, yes, it is very much a definition question. But that is because "a blockchain" has it's requirements and its pro's and cons built into that definition. So if you start stretching the definition, you simply loose requirements. And you end up with something that really makes no sense.

</comment></comment><comment><USER20> As much of a fallacy as "personal cloud" (the new marketing term for NAS).

</comment><comment><USER21> Please correct me if I am wrong - but when people say private blockchain I think they mean multiple nodes that don't trust other, but not an unlimited number of nodes or the ability for just anyone to mint coins upon it.

<comment><USER22> The majority of the time I see the term "private blockchain" used it's in reference to something not dissimilar to a few companies keeping an append- only ledger.

In that case, each company is trusted to at least be authoritative for their entities and to be trusted to the extent that their identities are known and they may be held accountable.

In that situation, an append-only log with merkle-tree-like crypto could handle the situation just fine.

The key thing that isn't needed there is proof of work; participants do not need to be "rate limited" and, if a conflict arises, they can all be trusted to, say, arbitrarily pick the item with the lowest sequence number rather than needing a proof of work system.

In what situations do you think a private blockchain is warranted and specifically why is proof of work necessary in that scenario?

<comment><USER23> Blockchains have consensus built in at the protocol level. Sure, you could share an append only log, but who settles disputes? All that functionality has to move off chain, and that's a bigger risk, in my opinion.

<comment><USER22> > Blockchains have consensus built in at the protocol level

They have it built in based on picking the chain which the most work has gone into.

Arbitrarily assigning a number to a transaction and having everyone to agree to pick the smallest in the case of conflict is easier and works fine if your members are all trusted to not maliciously abuse that facet of the code.

Proof of work is throwing away resources to solve a problem you don't have if no one is crafting malicious transactions.

<comment><USER11> >Arbitrarily assigning a number to a transaction and having everyone to agree to pick the smallest in the case of conflict is easier and works fine if your members are all trusted to not maliciously abuse that facet of the code.

This would be like a traditional eventually consistent distributed database (using total order to resolve conflicts).

And we might ask "why did those deploying private blockchains not just use that kind of thing?".

I'm not sure, but potential reasons are:

1\. That kind of thing doesn't actually exist in a form that they can easily use, so they re-purposed existing, reasonably proven blockchain technology to achieve an equivalent functionality.

2\. The parties don't completely trust each other so in fact malicious transactions can be crafted.

3\. They don't trust their software to not craft malicious trasnsactions and the blockchain provides a neat way to filter them out.

<comment><USER24> Don't forget about potential reason number 4.

4\. Blockchain is very hyped right now and they want to show that they are hip and cool by keeping up with the latest trends.

</comment></comment></comment></comment></comment></comment><comment><USER25> Let's say the OP is correct. It doesn't matter — Whomever is using the word is using it how they want to and the recipient will understand the correct and incorrect meaning. If I was the CTO at a bank and I told the OP we were building a private blockchain for asset management, he would know what I mean. Now since the op is technical, he would probably ask more questions to figure out that what I really want is an openly audit-able immutable database, but his intellect would allow him to drill down further.

This _fallacy_ the same thing that happened for the word "Disrupt"/"Disruption"/"Disruptive Technology". Even Clay Christensen, the creator of the phrase, says most people misuse the phrase "disruption" when compared to his explanation in the Innovators Dilemma[1]. There are Tons[2] of[3] people[3] complaining that the term is misused. In the end, if you casually tell someone you've got an idea for a Taco Food truck that's going to _disrupt_ the food truck industry, people will know what you mean.

The definition of this word "blockchain" is being misused so much that it is changing faster real eduction can help. I think posts like this are great if you're technical, but as I said above — It doesn't matter what the fallacy is.

[1] - [https://www.amazon.com/Innovators-Dilemma-Revolutionary- Chan...](https://www.amazon.com/Innovators-Dilemma-Revolutionary-Change- Business/dp/0062060244)

[2] - [https://techcrunch.com/2013/02/16/the-truth-about- disruption...](https://techcrunch.com/2013/02/16/the-truth-about-disruption/)

[3] - [https://www.forbes.com/sites/vukivujasinovic/2017/03/02/its-...](https://www.forbes.com/sites/vukivujasinovic/2017/03/02/its- time-to-stop-saying-everything-is-disruptive/#62a5bbc708dc)

[4] - [https://www.newyorker.com/magazine/2014/06/23/the- disruption...](https://www.newyorker.com/magazine/2014/06/23/the-disruption- machine)

<comment><USER26> If it's private, it isn't auditable. You can keep a journal of all transactions, and when you decide that history needs to be changed, you make the change in your journal and roll it forward from there. If the auditors have half a clue, you can't do this for events that happened before the most recent previous audit, but if they have a whole clue, they won't accept the current state of your system as anything more accurate than your attestation.

The counterargument to "words mean what people agree they mean" is that "to computers, instructions mean what they have already been defined to mean". If you change Python's meanings, you need to tell everybody that you're using Python 3.5-Joe, not Python 3.5.

<comment><USER11> >If it's private, it isn't auditable

Clearly true, but in this field "private" is really being used to denote "not a Public Blockchain like Bitcoin and Ethereum".

It doesn't mean "actually private". It means "we built our own rather than pay to use Ethereum".

<comment><AUTHOR> No, because that would be another public blockchain.

Private really means what you think it is "a blockchain that only a small selected group can access". A lot of "Private blockchains" are just Ethereum- nodes running behind a firewall and with a secret genesis-block.

It does not, however, mean that it cannot be peer-reviewed. Allthough that still leaves the problem of not knowing if what you've reviewed is what is running.</comment></comment></comment></comment>


Faster Chips Are Leaving Programmers in Their Dust - <AUTHOR> http://www.nytimes.com/2007/12/17/technology/17chip.html?ex=1355547600&en=61dfe25f3006afd7&ei=5090&partner=rssuserland&emc=rss

<comment><USER2> Ok, so maybe I'm missing this whole multi-core dilemma. But I don't see that big of a problem. I just think that people are asking the wrong questions. The question isn't how can I write software for mutli-core chips, it should be "what problems are solved best with multiple cores?"

There are categories of "embarrassingly parallel" problems that have been solved for years using multiple cores: video rendering, 3D graphics rendering, etc... In short, anything that does repetitive processing on large datasets.

Now, people are upset, because we're not going to be able to improve the software for the average user with multiple cores, and they are correct if they want word processing and email to get better with multiple cores. The question that we need to be asking, is this: how can embarrassingly parallel problems make user software better?

How can we use multiple streams of video in software? How can 3D rendering improve my software? Or, what sort of very large datasets can I process with multiple cores on the desktop?

The companies that answer those questions (e.g GOOG) are companies that will make a lot of money in the next decade.

<comment><USER3> I agree.

At least half of the "dilemma" is pure, unadulterated marketing. In this article, the marketer is Microsoft, which is trying to convince end users that there's some kind of big problem, one which no mere mortal can comprehend, that is somehow preventing our expensive new Vista machines from being any better than the XP boxes they replaced. It certainly has nothing to do with Microsoft's incompetence, nor with their slavish devotion to Hollywood- approved, mind-mangling, box-breaking DRM. And it's certainly not their insistence on foisting incompatible proprietary crap like IE on the industry. No, it must be a Fundamental Problem of Computer Science that is holding us back. Naturally, this problem can only be solved by the big academic brains that work for... Microsoft!

The email example is a dead giveaway... it's laugh-out-loud funny:

"In the future, Mr. Mundie said, parallel software will take on tasks that make the computer increasingly act as an intelligent personal assistant."

Ah, the intelligent personal assistant -- it's the application of the future, and it always will be.

How do we know that intelligent email processing is not being held up by the lack of suitable coding techniques for eight-way parallel processors? Because I have a dual-core processor right now, and it spends the night contemplating its digital navel and counting to 2^64 by fives for fun. If there was something smart it could be doing with my email, why isn't it working on it right now? I am _drowning_ in unused processor cycles.

<comment><USER4> +1 Insightful

The Microsoft personal assistant example is just cracking me up. Firstly, Microsoft has been selling the whole 'automated assistant' thing to us for YEARS. Clippy is just one hideous example.

Secondly, automated inbox processing has been around for _years_. My POPFile open source program is now over 5 years old and there are older examples than that (I was doing automated emailing sorting in the late 90s and others before me). So multi-core machines are what's holding this back? What a joke.

Thirdly, it mentions features (looking at who I correspond with) that are already available (see Xobni and others). And automatic response systems are also around to deal with customer service.

Sorry, for the rant put two pages of fluff about multi-core processors with some freak out speculation about email processing that's been available for a long time.

How about talking about something interesting, like parallel aware languages (Occam, erlang, ...)?

</comment></comment></comment><comment><USER5> Nice article, but what a strange title. Faster chips are leaving programmers in their dust? Huh? I wasn't aware that I was competing with cpu speed. All this time, I thought more processing speed expanded my possibilites. After all, my entire field (mathematical optimization) would be pretty useless without lots and lots of processing power.

I talked to a dude with an OR background, and he said that in the 80s people laughed at the notion of using this kind of math to solve business problems. Processing power increases the opportunities for programmers, without question.

Anyway, fun to read, just a very strange take on the relationship between programmers and cpu speed.

<comment><USER6> The point is that more processor speed expands your possibilities _only if you are smart enough to actually use it_. Lazy (dare I say "blub") programmers _are_ being left in the dust.

(Of course, this isn't the first time some programmers have resisted change. I remember a great rant about how if you program in assembly and never hit in the cache, the Pentium 4 was no faster than the Pentium III and thus useless. That guy probably quit programming entirely when multicore arrived.)

</comment></comment><comment><USER7> Maybe those extra cores can be used to do a better job of remembering, learning, and anticipating what users will do. This could pre-load or unload applications or components based on historical usage, rearrange toolbars to have the most commonly used commands, and in general make the kinds of improvements to computing in general that the squiggly underlines did for spell checking last decade. Right now computers are largely deterministic and users have to learn how the computer works. That's why users hate computers. Some of that pain could be taken away. I think this will benefit OSes, thick clients, and installable programs more than the web.

<comment><USER4> Magic toolbar rearrangement is a world of pain. That's like having my SO notice that I always look for my keys before I go out the door so she moves them to the table near the front door, when I habitually put them in the vide poche near by desk.

<comment><USER7> I'm not saying that's what I would want, but have you ever watched a non- techie use the computer? Just looked over their shoulder and watched them? It's horrifying! I can only watch my wife for about 2 minutes before I start belting out things like "You don't need to double click links on the web!" or "If you double click on an app, you have to give it a couple seconds to load or else you're making the problem worse!"

What a smart OS would do was watch you for a while and notice what you do, and then make a decision based on the statistics: let's say 85% of the time, your keys are in the vide poche and you find them immediately, and the other 15% of the time they're somewhere else and it takes you 5 minutes to find them. Then it would warp them to the right place (the place your actions showed them was right) with a note and an option to "always do this". I shudder to think of MSFT's implementation of this (Clippy), but if a smart company along the lines of Humanized did it, and used statistics instead of some clever algorithm (didn't we just read about Google doing that?), it could be a godsend for average users.

</comment></comment></comment><comment><USER8> "Indeed, a leading computer scientist has warned that an easy solution to programming chips with dozens of processors has not yet been discovered."

weird I thought it was called erlang

<comment><USER9> erlang is not easy. At least, not for me, a mere mortal.

<comment><USER8> ok let me elaborate - it is "easier" to do parallel programming on erlang compared to other languages

<comment><USER9> I know this. I watched a video on this whole argument not long ago...link is floating around on YC somewheres.

<comment><USER8> well then why complain?

</comment></comment></comment></comment></comment><comment><USER10> The article seems to be a retread of the same thing that's been printed every day for 20 years. "New processors are going to make all these new things possible." And yet there's still no computer holding a reasonably intelligent conversation with you if you call Dell customer support. Actually, there isn't even a human doing that.

</comment><comment><USER11> If just a small portion of an application is non-parallelizable, then a million cores won't help you.

<comment><USER4> I think it's time for a refresher on Amdahl's Law.

<http://en.wikipedia.org/wiki/Amdahl's_law>

The non-parallel portion limits the available speedup.

</comment></comment><comment><USER12> PR.

<comment><USER8> I don't know why u got modded down - this is a submarine PR article for MS...

<comment><USER12> How do I tell if it was modded down?

Maybe I should explain my terse comment. But first, I agree that it's a submarine PR piece for Microsoft. How many software companies are cited in that article? How many technologies are mentioned and/or explored? In short it says "Multi-core processors have potential, and [only] Microsoft has the best minds trying to exploit that potential."

Parellelism has been available in less local forms for decades. Supercomputers, clusters, more recently grid computing. These aren't new problems for computer science, they are only new problems for desktop software developers that have always assumed a simpler processor architecture.

So imagine a program that could identify parallelizable sequences of instructions in other programs, and split the program accordingly. Such a program may be able to exist, but it appears to be a very hard problem (it's even a hard problem for humans). Vista is definitely NOT this program.

<comment><USER8> "How do I tell if it was modded down?"

your 1st comment had a -1 point on it

</comment></comment></comment></comment><comment><USER13> surely if MS could make it so threads were processed by spare cores automattically then this would make life easier.

Servers could use the cores to process more connections and lessen the need for more servers. I guess virtualization could be used.

</comment><comment><USER14> "...we at least have a nucleus of people who kind of know what's possible and what isn't..."

A sure fire recipe for missing the boat.

Honestly, which would you rather have, more power in your hand or a faster pipe to the rest of the world?</comment>


Duolingo Bots – Learn a language through conversation with AI - <AUTHOR> http://bots.duolingo.com/ <comment><USER2> If these work well (i.e. they don't teach you some weird, stilted version of the language), then this is the best use case for chat bots that I've seen.</comment>


Russian spies target Covid-19 vaccine research - <AUTHOR> https://www.bbc.com/news/technology-53429506 <comment><USER2> All Covid-19 vaccine research should be open sourced anyways.

</comment><comment><USER3> "vaccine research had not been hindered by the hackers."

The only thing that matters here.</comment>


Feds charge former SF building commissioner Rodrigo Santos with bank fraud - <AUTHOR> https://www.sfexaminer.com/news/feds-charge-former-sf-building-commissioner-rodrigo-santos-with-bank-fraud/ <comment><AUTHOR> SF is an expensive city to build in.</comment>


GitHub's down? - <AUTHOR> Getting the unicorn on any pageload <comment><USER2> I read about Github being down and know that it sucks for many people. What I find interesting is thinking about how quickly so many installations of distributed version control adopted a _de facto_ central server. Github is a platform that should not need a particularly high uptime from the point of view of any one user.

But of course it does because so much of its utility is that it substitutes for a lower level partition strategy for source code version control at the level of the individual user. By which I mean that the whole point of distributed version control is to have sufficient resources for working at hand regardless of what is happening remotely as the default condition.

Git is designed to be available and partition tolerant. Using it with the expectation of consistency is a mistake and Git requires manual intervention on the part of users to even get good-enough-consistency. Github can't change that.

None of which changes makes Github being down not suck for the people for whom it sucks.

<comment><USER3> > Github is a platform that should not need a particularly high uptime from > the point of view of any one user.

This is totally false. GitHub doesn't just provide a git server, it also provides ticketing and project management. When GitHub is down, projects that rely heavily on, for example, commenting on issues grind to a halt.

Yes, you don't need GitHub to be up 99.999% of the time to do a `git push` every once in a while, but there are other projects that use other features of GitHub besides the git server aspect.

<comment><USER4> And it's a shame this is the case, though.

I do publish projects with github because of the popularity of the platform, but I really don't approve github pull requests, and I also don't like github over-simplified issues. Together, these two features are probably what most projects depend on.

Github pull requests are definitely inferior to the patch-by-mail approach for a conversation within a closed group of people. It's clicky and looks friendly, but you don't have the patch to see in the mail notification (you have to be online), and again it's more convoluted to edit/apply using vanilla git.

Many people don't know, but git makes patch-by-mail handling extremely convenient to handle. In fact, it's more convenient to handle than using the several github command-line interfaces I tried(!). You submit the patch, have a conversation by regular mail, and then either edit the patch or merge it. Everything is always right there. Using github you have several side effects: people often add comments to specific lines in the patch, which will looks like garbage in the generated github notification. People will also naturally edit the comments, which won't generate notifications. I cannot count how many times I have to re-read comments because I had the feeling I missed something (and indeed, some comments were edited). This is bad. It shouldn't be allowed. It cannot happen with email.

Github has the advantage of making the conversation visible. But if you have a developer mailing list for your project, git and plain, regular patches _do_ work really well. It might take a bit more to get used to, but it pays back.

Issues are a different problem, since I still feel the distributed solutions are inferior. I experimented a lot with bugs-everywhere and simple defects (sd), two distributed bug trackers that store the issues in the repository itself. Both are nice, and have distinctive features from each other which I'm not going to discuss much. The main thing is that 'sd', at some point, even supported to sync issues with github, which allowed to have best of both worlds. Unfortunately, it's lacking maintenance at the time, but it would solve ticketing in a distributed way. It looks like there's not much interest in this, as _both_ projects are definitely not as active as the many available github clients which do 1/10 of what these projects offer.

Please, look into these two projects.

<comment><USER3> Thanks for the distributed issue tracker mentions; I didn't know they existed.

</comment></comment></comment></comment><comment><USER5> [https://status.github.com/messages](https://status.github.com/messages)

>Today

>11:32 UTC "We're seeing high error rates on github.com and are investigating".

>11:40 UTC "We're doing emergency maintenance to recover the site".

<comment><USER6> Just noticed an interesting design decision on that page. An 'everything OK' message once a day. One way to push previous downtime below the fold of the page.

<comment><USER7> It's also a way to show "yes, this status check is still reliably doing its job, it hasn't crashed".

<comment><USER6> OK I could take that as a reason.

</comment></comment></comment></comment><comment><USER8> For everyone who is currently loosing productivity, perhaps your time might be well spent reviewing `git daemon`: [http://git-scm.com/book/en/v2/Git-on-the- Server-Git-Daemon](http://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon)

<comment><USER6> OK I get what you're saying, but honestly, who is really 'losing productivity'? I suspect the ones saying they are in fact just getting on with other tasks they can do because they are, despite github, still using distributed version control and do have access to and the ability to commit to code repositories. You don't need to host your own git daemon or github clone to get that functionality.

I don't use github because it gives me a git daemon. I use it because the interface allows me interact with non-technical people when dealing with code and resources. I use github because, even though it is down right now, my stuff is backed up, I don't have to deal with the nitty gritty of ensuring backups succeed, I don't have to deal with the system when it goes down - someone else does that for me. Hence I would never want to run a local github clone.

<comment><USER9> It kinda sucks when you rely on continuous integration, though.

<comment> ad-hominem Can't you just run your tests locally?

</comment></comment></comment></comment><comment><USER10> Funny, I switched our projects to Gitlab a week ago and told the team: Because we should not trust a centrealized platform to keep our code decentralized.

<comment><USER11> So you switched from one central platform to another singular central platform? Am I missing something here?

<comment><USER12> This is what I don't get. I trust github as a central platform more than hosting my own gitlab in the cloud.

There's a lot of people spreading a holier than thou attitude in this thread.

<comment><USER13> GitHub is a much larger target, and has many, many more moving parts than your average Gitlab on, say, a Linode virtual server.

Github will probably have more downtime which you can do noting about, than your selfhosted gitlab, which will probably fail because you upgraded something, or tinkered with a configuration.

It's a numbers game. They have more people monitoring, they spend way more money than you do on uptime/services, but such a service doesn't get more stable as it grows.

I trust myself way more than I trust GitHub or other hosted/cloud services because I cannot affect/help them in any way when stuff happens.

Ultimately, I know this, I accept this, and I happily use GitHub, Bitbucket and such all the time.

<comment><USER14> >Github will probably have more downtime which you can do noting about, than your selfhosted gitlab, which will probably fail because you upgraded something, or tinkered with a configuration.

Personally I don't think you will see less downtime on your own server. The difference is, that when it goes down, there is something you can do about it, so you get busy fixing it.

When github is down we get to all get online and talk about our woes together.

The outages are usually pretty short. Go get a coffee and come back, or grab the team and go play a round of bowling. That has to be better than trying to manage and keep secure our own repos.

<comment><USER15> This - the last thing I want to do is be on the line when something happens to our git server and no one can work because our solution is my own custom one- off.

</comment></comment></comment></comment></comment></comment><comment><USER16> the d in github stands for distributed

<comment><USER17> how did you rotate b?

<comment><USER18> The joke is there is no 'd' in github, it's not distributed.

<comment><USER19> The joke is a reference to this old gem

[http://www.bash.org/?330261](http://www.bash.org/?330261)

<comment><USER18> Ah, a true classic :)

</comment></comment></comment></comment></comment><comment><USER20> That's when you notice how dependent you can be on GitHub.

You would think you can still develop an iOS app when GitHub is down, but a simple `pod install` requires access to repos hosted on GitHub.

</comment><comment><USER21> Time for a sword fight!

<comment><USER22> For those confused by this: [https://xkcd.com/303/](https://xkcd.com/303/)

</comment></comment><comment><USER23> So glad we don't rely on GitHub for our deployments anymore, we haven't had an outage to git in the past year yet it seems GitHub goes down more often than people realise. Obviously DDOS attacks are nearly impossible to mitigate for anyone but it should serve as a reminder of companies dependencies on external services.

Somewhat related I highly recommend both Gogs and Gitlab for internal git hosting.

</comment><comment><USER24> Yes, response times seem to have spiked: [https://status.github.com/](https://status.github.com/)

Could be another DDoS?

\---

Update 11:32 UTC "We're seeing high error rates on github.com and are investigating".

</comment><comment><USER25> Just use [https://git.directory/](https://git.directory/) :D

<comment><USER26> Cool to see you set up a GitLab instance for others to use, I had not seed that TLD before.

<comment><USER25> Thanks for GitLab!

<comment><USER26> You're very welcome, thanks for spreading the word.

</comment></comment></comment></comment><comment><USER27> To me, that looks like an angry unicorn ... does that mean it's another DDoS?

It would also be interesting to track loss of productivity in the software engineering professions when GitHub is down. Is this a single point of failure for your company?

<comment><USER28> Not just for a company, but for developer productivity in general, professional or not...

Think of all the package managers that pull straight from Github repos as part of their installation processes..

<comment><USER27> Exactly ... we've got Ansible scripts that do that. One of the current Java rockstars (not my description), Adam Bien, recommends pulling the source code for all third-party dependencies to build them locally and put them in a local repository. I suppose you can push directly back upstream to avoid having an extra step.

<comment><USER29> If you're using Java most of the build tools use the Maven repositories, for which you can set up a local mirror too. The company i work for runs a Sonatype Nexus so we're not really affected by others' downtime unless we need stuff that we hadn't ever used before.

<comment><USER27> Yes, for our Java projects we have a Nexus repository which mirrors everything locally. It doesn't protect us from someone deleting a project ... then we're stuck on the last available version without a way to address issues, but it's worked pretty well so far.

</comment></comment></comment></comment></comment><comment><USER30> Up again!

11:54 UTC "We've finished emergency maintenance and are monitoring closely".

</comment><comment><USER31> I was uploading a new profile picture sorry everyone.

</comment><comment><USER32> A few projects can help you monitor this:

Octobot iOS app: [http://octobotapp.com](http://octobotapp.com)

And my own service, StatusGator: [https://statusgator.io](https://statusgator.io)

</comment><comment><USER33> Probably people trying to clone curvytron because curvytron isn't currently playable at its own site.

It's like an unintentional pub crawl-- 400 people show up to party, empty the pub of booze, move on to the next pub that hasn't enough booze...

</comment><comment><USER34> Github is down again! And Slack too. The only page of slack.com that is available is their status page that says: "All's good under the hood, boss! Slack is up and running normally". UTC/GMT 19:06

</comment><comment><USER35> Every time GitHub is down I'm peering at Upsource:

[https://www.jetbrains.com/upsource/](https://www.jetbrains.com/upsource/)

<comment><USER36> UpSource IS not a repository. It is just a Viewer for your repository. You still need to host everything yourself.

As you can see here:

> > [https://www.jetbrains.com/upsource/roadmap/](https://www.jetbrains.com/upsource/roadmap/)

Git hosting is on the roadmap, not ready yet. Also Upsource takes a shitload of memory.

</comment></comment><comment><USER37> SE yesterday, gh today. Bad week for dev productivity.

<comment><USER38> SE?

<comment><USER39> Stack Exchange.

</comment></comment></comment><comment><USER40> Seems to be partly up, hurray! (maybe)

Update: "We've finished emergency maintenance and are monitoring closely".

</comment><comment><USER41> I'm just getting unicorns everywhere. Sprint review in an hour. Damn, I love wednesdays.

</comment><comment><USER40> Hopefully the responding on-call engineers aren't tired folks but folks in other timezones. The reason that the risk of compounding the situation is lessened, because trying to fix important shit when tired is like driving without a seatbelt.

Update: seems to be back, so it doesn't matter unless someone's having an early morning.

<comment><USER42> Probably? This is a very random concern to have, why would you think that Github has problematic on-call procedures?

</comment></comment><comment><USER43> 11:40 UTC "We're doing emergency maintenance to recover the site".

</comment><comment><USER44> Damn you github. Just tried making my first push in my new company and boom!

 _wasn;t me_

</comment><comment><USER45> Had to deploy an important service. And github is down.

<comment><USER46> perhaps a good time to reconsider depending on a third party for your important services to deploy?

<comment><USER45> Yes, but these decisions aren't under me plus setting up a github kind of thing is way too time consuming with all the features that we're used to now.

<comment><USER8> A GitLab droplet on Digital Ocean should run you only $10/month and literally sets up in ~10 min.

<comment><USER47> What makes the servers of digital ocean safer than github?

<comment><USER8> They're not GitHub. i.e. The chance of GitHub _and_ your GitLab instance on DO going down simultaneously is very slim. Spend an extra $10/month and you can set up another DO server in another data-center, and reduce the odds of simultaneous failure even further.

</comment></comment></comment></comment></comment></comment><comment><USER48> The 'one' day that I wake up at 7AM to get some quality caffeinated work done, and I can't pull.

It's all good though, I still have loco host to keep me busy until their resolve the issue.

</comment><comment><USER49> OK it's back.

</comment><comment><USER50> It's back to normal. Back to work guys!!

</comment><comment><USER51> I thought git was all about decentralization?

</comment><comment><USER52> IS there any opensource private github?

<comment><USER53> [https://about.gitlab.com/](https://about.gitlab.com/)

</comment></comment><comment><USER34> Slack is up. And github too.

</comment><comment><USER54> Back up !

</comment><comment><USER55> it's weird

</comment><comment><USER56> it's up

</comment><comment><USER57> it's back

</comment><comment><USER57> it's back now

</comment><comment><USER58> Not again.

</comment><comment><USER59> yep

</comment><comment><USER17> It wasn't me

</comment><comment><USER60> The site is live now

</comment><comment><USER61> Yes it is!

</comment><comment><USER62> :)

</comment><comment><USER63> looks like its time to go for lunch

</comment><comment><USER64> Yep. Down for maintenance.

</comment><comment><USER65> So the DDOS is basically all of us accessing status.github.com right?

</comment><comment><USER66> Back now! Orange octocat, "We've finished emergency maintenance and are monitoring closely".</comment>


BodyPix: Real-Time Person Segmentation in the Browser with Tensorflow.js - <AUTHOR> https://medium.com/tensorflow/introducing-bodypix-real-time-person-segmentation-in-the-browser-with-tensorflow-js-f1948126c2a0 <comment><USER2> Live webcam demo: [https://storage.googleapis.com/tfjs-models/demos/body- pix/in...](https://storage.googleapis.com/tfjs-models/demos/body- pix/index.html)

Relatedly, I've had good results with PoseNet: [https://storage.googleapis.com/tfjs- models/demos/posenet/cam...](https://storage.googleapis.com/tfjs- models/demos/posenet/camera.html)

</comment><comment><USER3> Exceleent library. But how does this differ from PoseNet and other libraries that pinpoint eyes, feet and other key points? I guess what I am really missing is a tensorflow library that can show me how far the body part is from the camera as well, that way I can have multiple people in front of the camera and can judge distances too</comment>


Lessons from Failed DocuSign Integration - <AUTHOR> https://profsmallpine.com/writing/lessons-from-failed-docusign-integration <comment><USER4> I was on this project and can speak a bit more on the technical details here.

A couple of high level goals:

1\. We wanted to use their embedded flows, to keep the experience within our application as much as possible.

2\. We wanted to avoid having to create a DS user for every user in our application that turned on this feature. We were looking for using 1 "API user" to make requests, handling data scoping ourselves within the application.

The actual issue in more detail:

1\. Go to an embedded page, authenticated as the "API user" (which _looks_ like you're sandboxed within DS to the embedded page)

2\. Refresh the page

3\. You now can click around the entire account - viewing any data that belongs to the API user (in our case, all of the data).

At this point (as the OP called out), we realized we had no choice but to create DS users. But we still wanted to hide this process from our users, keeping DS as embedded as possible. The issue was their "regular" user creation flow involves a email going out to the user to confirm - <USER2> this is unideal if our goal was to wrap DS and hide it's existence as much as possible from users.

DocuSign offered a workaround for this, which involved basically getting shifted to a legacy version of the API, with no hard promise of it _not_ being sunsetted. By then, we had had such a poor experience with non-answers from their team that we called it quits.

I hope this clarifies some of the technical problems we were trying to solve for.

Edit - I'm sure DocuSign can solve for some use cases. Obviously, they have a large user base and I'm sure most of them are at least satisfied, if not happy. But if you're trying to wrap an e-sign provider within your application, I would recommend HelloSign 1000x. HelloSign's API is a first class citizen whereas DocuSign's felt more like an afterthought.

<comment><USER4> I'd like to add a little more to this - our main frustration isn't necessarily because of these technical difficulties. Communicating implementation details and 3rd party integrations can be challenging, especially if one side of the convo is not super technical. That is totally understandable, and probably inevitable.

The main reason this felt so...sucky for lack of a better term, is that we had _multiple_ discussions about our use case and were told that this would be supported (again, this turns out not to be true? not a huge deal, it happens), and were asked to pay $20,000 upfront of which we got $0 back once realizing the original promises were not true.

As OP pointed out, 20k for a huge company like DS might not seem like much, but for a small start up like us it is. Just from a consumer perspective, this seems like a crappy way to conduct business.

<comment><USER5> Sounds like the - unfortunately very common - thing where sales people make promises which aren't delivered on.

Seems to be the sales people doing this get bonuses regardless, even though the customers get shafted, and their own tech staff generally get shafted too. :(

</comment></comment></comment><comment><USER6> Maybe the goal here wasn't to be technical (although I'm not sure why given it's an article about docusign api integration) but this is a WHOOOOOLE lot of text with basically nothing worth reading.

>I was annoyed that they didn't provide a secret key to authorize API requests

Yeah... they don't do that for a reason. They appear to support a fully fledged OAuth implementation ([https://developers.docusign.com/esign-rest- api/guides/](https://developers.docusign.com/esign-rest-api/guides/)). I haven't used it, so maybe it's terrible, but I'm suspicious of the author at this point.

>DocuSign API docs are very quirky

But no discussion of why, or what he would expect instead. This actually sounds like the author is lost because they don't understand OAuth again (and to be fair, I've implemented OAuth and it's easy to get wrong).

>Someone on the team noticed that if you refresh the page, you get logged in as the user that was making the API request. [...] About a week later, we were informed that this is intentional, and they were worried about breaking anyone that is using this as a feature.

This honestly sounds like they were politely telling you that you haven't implemented OAuth correctly. You should be making the request with the token of the delegated user, not a generic account.

>I got this working, but it took some janky work to re-work the JWT flow to manage hourly expiring tokens for all of our user that choose to enable the esignature feature.

This is what refresh tokens are for. I highly doubt the refresh token expired in an hour, but hey - I haven't used it so maybe I'm wrong.

\---

I honestly believe I can summarize this whole article as: Dev takes first steps into OAuth and gets lost...

<comment><USER7> OAuth is going to be hard to use if you don't create an account though, there's no way for DS to know what scopes to restrict the user to, it sounds like that was the core issue that broke their workflow.

<comment><USER8> I think it is very unclear what is real and not real. OP is mostly passing blame to DocuSign without achieving full understanding themselves. That is more an indictment on OP than DocuSign even if there is some actual session security problem with DocuSign (likely from the deprecated API).

<comment><USER9> Yeah and it sounds like they were trying to do something that makes no sense for DocuSign to support: use a single account to sign all users' documents.

DocuSign has a legal obligation here to prove authenticity, how are they ever going to be able to do that if everything is behind a single account?

They support oauth and that makes sense and should be the way to do it.

<comment><USER10> >DocuSign has a legal obligation here to prove authenticity, how are they ever going to be able to do that if everything is behind a single account?

By the signature.

I don't know how it works in DocuSign's internals, but there's no requirement for the signer to have an account. The point of the account is for users to see all of their documents in one place. In OP's case that's everyone's documents because they use a single account.

[https://support.docusign.com/articles/How-do-I-sign-a- DocuSi...](https://support.docusign.com/articles/How-do-I-sign-a-DocuSign- document-Basic-Signing)

<comment><USER11> Yep. I just signed things via docusign 2 weeks ago. There was no 'create an account' first. IIRC, there was something at the end indicating I could create an account _after_ the doc was signed, but I got a copy via email anyway which was all I needed. The last thing I need is _yet another_ account/login for what is essentially a one-time thing.

</comment></comment></comment></comment></comment></comment><comment><USER12> I had a project that used docuSign a few years ago. There were some very strange things going on with their API.

I remember having to call them asking where to find a template ID so I could save that and send out the proper doc to customers. It was not listed anywhere on the developer dashboard. The rep told me in a very condescending way that it template ID was part of the URL. I should have known to just use that!

My app was written in a python backend. They had a some API examples in different languages for their docs. The python example was a total embarrassment. It was clear that the person who wrote it had no experience with python at all. I am not trying to be mean, it was that bad. Every line ended with a semicolon (in python this is not an error, but is officially discouraged). The person also seemed to not be aware of a dictionary. They built their json paylod by concatenating text. It was the messiest python code I had ever seen. I think this particular bit of code is gone now, but it was incredible.

I felt so bad that I emailed them some suggested fixes and asked if they had python experience. They responded with a something along the lines of ya, we had the java guy do that. But the code stayed up there for a long time...

<comment><USER13> I also worked on a Python project that integrated DocuSign.

I was able to hack together solutions and skirt around DocuSign's many problems, garbage documentation, and general very-low-quality API, but in no circumstance would I ever recommend it to anyone. Late in the project I seriously considered throwing it away and switching to another API.

The other API I considered was: [https://app.hellosign.com/api/pricing](https://app.hellosign.com/api/pricing)

This is literally ten times the price of DocuSign and I don't know how long they'll be in business, so it's a hard sell to buy into that. The API docs looked way way better (like stripe or twilio or slack apis, rather than some janky enterprise nonsense), but development and hacking around DocuSign was a one time expense, and the API is an ongoing cost.

If remotely possible, I'd just sign stuff in person and mail or fax it, since all this stuff just adds difficulty, complexity, and cost, to very little benefit unless you have a LOT of people signing stuff. The application I worked one was for one or two signatures a month, so not worth the trouble.

</comment></comment><comment><USER14> I've done a docusign implementation, and I don't really agree with them. Their API is fine honestly, I think their documentation could be better and some things are named awkwardly. But the implementation really isn't hard, my only real complaint is that when we did it they pushes the DocuSign connect service really hard, which honestly was kind of a waste and didn't live up to many of their promises, but that's normal b2b upselling. It's a normal API, and definitely not as bad as this person makes it seem.

<comment><USER15> Whether an API is "good" or "bad" often is dependent on the requirements of the calling client. At the beginning of projects when client requirements are unclear, it is often hard to determine whether a supporting API/library truly meets your needs.

<comment><USER14> That is true. To move away from language like good or bad. I would say DocuSign is quite reliable, we had one outage that was their fault and we were an edge case. I would also say that their API is sufficient for 95% of use cases or more with very little work arounds. Their customer success architects or whatever they call them were also pleasant to work with and responded promptly.

</comment></comment></comment><comment><USER16> I am DocuSign's Lead Developer Evangelist. Thanks to Joseph (OP) for writing this up and to everyone who has contributed to this thread including both the positive and negative comments about integrating with DocuSign.

The problem OP ran into is really one of documentation and not a bug or security issue.

I agree that our docs for the embedded sender view should clearly state that the method's URL gives full access to the sender's account, and we'll fix that ASAP. As others have commented, the assumption of this API method is that each sender has their own account. I also agree that the OP's use case, which requires that the sender view's capabilities be strictly limited to the current envelope, is valid. It is under consideration for our roadmap.

A workaround: I recommend that API applications complete the sending process programmatically including document tagging, etc. This also provides the best user experience for the sender.

We actively monitor and reply to the "docusignapi" tag on StackOverflow (I'm "Larry K"), if you want to reach out to us there.

<comment><USER17> _I also agree that the OP's use case, which requires that the sender view's capabilities be strictly limited to the current envelope, is valid. It is under consideration for our roadmap._

If this case is valid, other customers besides OP are doing the same thing. They probably have the same vulnerability. It's also not clear how document tagging can stop this hole. If there is just one user then that user's users can't have that user's creds. Rather they must be limited to specific tokens that give them access to their specific documents.

</comment></comment><comment><USER18> Looking at the API description (very detailed BTW) [https://developers.docusign.com/esign-rest- api/guides/authen...](https://developers.docusign.com/esign-rest- api/guides/authentication/oauth2-jsonwebtoken) , it does look like they used a wrong flow for the use-case, and then invented some shortcuts to make it work (which understandably did not work out well).

It does look like onboarding failure, but there is so much you can do to steer the customers towards the right path. I am not completely convinced that this was Docusign's fault.

</comment><comment><USER19> FWIW, I've developed a lot of this sort of tool. For some reason, Adobe E-sign services (formerly known as EchoSign) rarely comes up, but it's actually quite good and cost-effective to develop with.

Docusign is indeed pretty terrible as an API, but it does have the benefit that users have heard of it so it has a certain institutional credibility - which is usually important if you're developing the sort of app that needs an e-signature process. On that front, all of our clients were very comfortable with Adobe as a secure service provider - it was something we publicized, in fact.

I've played a bit with Hellosign. While I've heard they have a nice API, they don't have the institutional credibility that Docusign and EchoSign have. Also, their pricing was way, way higher than EchoSign's, in my experience. I'd love to learn more about them, though.

<comment><USER20> Can you give any guidance on Adobe/EchoSign's API pricing? Seems like it's behind a "contact us" enterprise plan these days? [https://acrobat.adobe.com/us/en/sign/pricing/plans.html](https://acrobat.adobe.com/us/en/sign/pricing/plans.html)

It generally seems ridiculous to me that it's 2019 and APIs like [https://app.hellosign.com/api/pricing](https://app.hellosign.com/api/pricing) are priced per signature _request_. Even if each finalized signature comes with regulatory retention requirements, that's far from a linear cost... and these are PDFs we're talking about retaining, not videos. The whole ecosystem reeks of price fixing.

<comment><USER19> Yeah, there's little I hate more than opaque "contact us" pricing. To my surprise when I inquired EchoSign was actually much cheaper than the alternatives. At the time, I had an API license from EchoSign that cost a few hundred dollars a year for a very large number of monthly document signings, with no hard limit (but polite requests to buy additional licenses if you went above the limit). I don't know if they've kept this pricing model though.

</comment></comment></comment><comment><USER21> Advice: Skip straight to the situation paragraph as anything before that isn't about the DocuSign integration, not sure what the first section brings to the whole article.

<comment><USER17> This is the third entry in the blog. Author just had some stuff to get off his chest. He might want to split this into two entries...

</comment></comment><comment><USER22> The author seems to have buried the lead here: "Someone on the team noticed that if you refresh the page, you get logged in as the user that was making the API request"

And that is how the implementation works for many of Docusign's customers as a 'feature'. If that's true, that would seem like a potentially exploitable security hole. However, I'd have to question if that had something to do with the particular implementation, otherwise I'd expect more focus on the security repercussions.

<comment><USER23> From what I can tell, the issue is that the OP was using a single user to perform all calls. They didn't want to sign users up individually, so they took this workaround route and found out that it wouldn't work after all. TLDR; they weren't using the API as intended because they wanted the DS part of the UX to be transparent to the user.

</comment></comment><comment><USER24> We just completed an embedded signature integration with HelloSign. The HelloSign API plans were expensive - but still a fraction of what DocuSign charged (at the time HS was 20% as expensive - pricing seems to have gotten more comparable now).

Integration was easy. The Ruby SDK & JS lib worked great (we have Rails back- end / React front-end). Customer service has been good & responsive. They have to approve your UI before giving live access - but once we had the integration working it took < 1 day to schedule the meeting, do the screenshare, and get approved.

Two slightly annoying things: (1) they don't have per-request fees if you go over your allotted usage. You'll get automatically bumped to the next plan which gives you 3x the request and is almost twice as expensive. (2) they wouldn't let us go month-to-month since we had an existing annual plan that we wanted to be under the same account (so we can share templates). This is tough since it's difficult for us to predict how many requests we'll need.

</comment><comment><USER25> Just use HelloSign. Their developer support is the best I've had from an API company - you email them and you get support from an actual developer - <USER3> they smartly do things to save everyone trouble like creating an API debug console so you can see what they receive on their end. I wish all of our API partners followed their lead.

The best thing I can say about Docusign is that it is way, way better than Adobe Sign's absolute garbage support. The Adobe software may work but if you have the slightest problem with the API you will be in support hell.

</comment><comment><USER26> All those online signatures "click to sign" services are useless anyway, they have absolutely no legal value anywhere (their EIDAS/ETSI whatever are just buzzwords), even in France from where docusign is coming.

[https://www.cryptomathic.com/news-events/blog/us-court- rejec...](https://www.cryptomathic.com/news-events/blog/us-court-rejects- docusign-e-signatures-as-method-to-provide-digital-authorization)

<comment><USER27> That article is pretty clear that the docusigned documents were invalid due to that specific court's rules.

To quote from the ruling [0] directly:

> Although DocuSign affixations and other software-generated electronic > signatures may have a place in certain commercial and other transactions, > they do not have a place as substitutes for wet signatures on a bankruptcy > petition, schedules, statements, and other documents filed with the court, > and they do not comply with this court's local rule.

[0] (see page 7) : [http://www.caeb.uscourts.gov/documents/Judges/Opinions/Local...](http://www.caeb.uscourts.gov/documents/Judges/Opinions/Local/Mayfield- ForWebsite.pdf?dt=202716160)

<comment><USER28> A real solution is a proper PKI - a great way forward would be if the US federal government issued citizens with X.509 digital certificates when they get their passport renewed: they've done the task of verifying identity, they just need to co-sign a cert and give people $5 smart cards with their $100 passports.

With state-sponsored PKI we can eliminate so many headaches and rockblocks in the digital economy and paperless government.

<comment><USER29> Given the whole SSN debacle and the low passport ownership in the US, I see this as functionally impossible.

</comment></comment></comment></comment><comment><USER30> We tried something similar years ago with DocuSign, and needed the ability to sign in person with two different people, one acting as a witness, with a potential third person being remote via email. It was not supported at all. Built our own internal system to handle esignatures, worked great, never looked back.

</comment><comment><USER31> The article was a bit meandering (bit of a bildungsroman), but good to know to avoid docusign apis. Might have been able to find out how much it sucked just by googling more "docusign alternatives" or "docusign api sucks" =D

</comment><comment><USER32> When we tried to bring docusign on board back in 2015-2016, it didn't feel like a very robust product in terms of user accounts management.

They had a legacy instance and a v2 instance (w/ new UI). Enterprise integration was against the legacy instance. Accounts created in one instance does not carry over to the new instance. User who self registered in new instance some how makes authentication into the legacy instance very difficult.

As a user with admin access to docusign, there were a paltry of user management features. I had to delete individual users. No way to filter or batch any user oriented actions.

</comment><comment><USER33> We rolled our own bc out of box solutions were crazy expensive. Any one else do this? I'm kind of surprised how much people are willing to pay for something that is not that hard to build. You can't build your own twilio or Google maps but Hou absolutely can build your own signature feature.

</comment><comment><USER34> I've been working a lot on a project recently with a fair bit of Docusign integration.

Some notes:

* Their API documentation really is garbage. If you're signed in to your developer account, you get access to marginally better documentation. This makes it hard to abuse Google to find things you're looking for. Specifically, the documentation is incomplete and difficult to navigate, largely because they appear to have relied on Swagger to generate the whole mess.

* Their support sucks, and exists mostly to try to get you to pay for their team to write code for you to interact with their code, rather than fixing their documentation.

* The API has some warts. I wouldn't care about the warts so much if the documentation compensated for it, but it doesn't, so I've burned lots and lots (and lots) of hours trying to figure out the weird bits. For example:

> You specify the difference between an "embedded" and "remote" recipient by > setting a clientUserId attribute;

> But, if you specify both a clientUserId and a client name attribute, then > the API call to createRecipientView will probably return a "User not found" > error (see for example > [https://stackoverflow.com/questions/20500630/unknown- > envelop...](https://stackoverflow.com/questions/20500630/unknown-envelope- > recipient-but-the-recipients-actually-do-match\);)

> You send an envelope not with an API call like sendEnvelope, but by setting > the envelope status to "sent";

> Exceptions thrown during the authentication process by default set the > Exception's error message to "Error connecting to the API...". Guess how > much fun that was to debug?

* And their library for PHP is really a steaming pile. It's just a wrapper around curl, auto-generated by Swagger. It pretty much demands a wrapper around their library to be able to work with it effectively and compensate for all the warty bits.

I haven't quite got to the point of _hating_ Docusign, but I don't love them, and wouldn't recommend them to other developers. I did find HelloSign early on in this project, and their API documentation ([https://app.hellosign.com/api/documentation](https://app.hellosign.com/api/documentation)) is everything that I wish Docusign's was, and they clearly make a much greater effort to be attractive to developers.

I'd love to link some of the Docusign support articles and such I've filed under my "docusign_sucks" tag, but you need to be signed in to your Docusign developer account to view them...

</comment><comment><USER35> > we've tried to build as much as we can as to skip dependencies, I've spent > enough time in rails to appreciate debugging owned code - an argument for > another time...

Okay, I'll bite. I have no experience in RoR, but does this line suggest that RoR _encourages_ NIH?

This line feels like that scene in a horror movie, right at the beginning, when the camera lingers a little too long on the janitor's face as he cracks a smile that's wider than it should be.

Red flags:

* NIH (mentioned above)

* Using Go in production (more specifically, complaining about the lack of support for Go in production -- you should have known what you were getting into)

* Announcing a hacked-together MVP to the whole company

* Escalated to a VP for a technical issue

* Not using the company's recommended workflow, instead building your own

There's no way that the inability for the author to deploy DocuSign, an API that hundreds of companies successfully use, is on DocuSign.

Also, an maybe this is just a cynical view, but when you start your cautionary tale with a literal, "It all started when I was 11", it's kind of hard to relate.

<comment><USER36> What is NIH?

<comment><USER37> Not Invented Here, a term normally used to describe the thinking that instead of using libraries we should write all our own code.</comment></comment></comment>