claim candidate goes to: this-edition A all three
Nobody buys it for the encryption: the features came from the constraint
Encryption is an important property, not a reason to choose a tool, and leading with it was a mistake Dinis made himself: if sgit succeeds it will be because it has better features and better workflows. Many of those came from the encryption as a constraint, because innovation needs constraints and the loop of trying, failing and shipping; the research is more careful than the slogan, an inverted U-shaped effect, some constraint helps and too much hurts. The same applies to design: take things away until it hurts, and stop there; the best product is not the one you use because you have to but the one that hurts when you stop.
Decided by. Nobody yet: a candidate for Dinis to read, comment on and decide (keep, rewrite, merge, cut, article first, later, not doing it).
Note. The research named is Acar, Tarakci and van Knippenberg, Creativity and innovation under constraints, Journal of Management, 2019, quoted: 'an inverted U-shaped effect of constraints on creativity and innovation'. Dinis declares a stake: sgit is his, and the article says the market will decide. A line for the cutter too: 'take things away until it hurts, and stop there, because past that point it gets worse.' Tension to watch with ship-now-ship-serverless, which presents SG/Send and sgit by their privacy property: the book should sell them by the workflow and name the privacy as the property.
Where it comes from
- The value of constraints The mistake I made first; Open source, as a constraint (newsroom)
What it answers in the 2018 book
- none named
Where it goes
Chapter Privacy by design: SG/Send, sgit, and the value of constraints, part Build it without a server (drafting); topic Be a founder (or a one-person service).
Other ideas proposed for the same chapter: Git for things you cannot put on GitHub: what an encrypted vault is, One string is address, authorisation and key; the read key derived from it is safe to publish, An app in a vault runs against the vault without ever being handed a key, Encryption on the client moves the problem from the data to the keys, and the sovereignty line to whoever holds them, Where the keys live: a password manager for the keys a person holds, a registry vault for the keys agents make, Append lanes: one POST from anywhere, readable only by the vault's owner, Client-side encryption reduces the exposure under GDPR; it does not take you out of it.
Node idea:nobody-buys-it-for-the-encryption in graph.json; see it in the graph. Source: admin/content/graph/ideas.json.