[draft-pacu-wallet-eol] Best Practices for Zcash Wallet Application End of Life

[pacu]

would eventually close #773

[daira]

Suggested change

	End of Life / End of Service
	refers to a point in time where the wallet
	software will no longer be actively maintained or developed, therefore its
	operation cannot be guaranteed anymore or terminated indefinitely.
	End of Life (EoL)
	The expected point in time after which the wallet software will no longer be
	actively maintained or developed, therefore its operation cannot be guaranteed
	any more or will be terminated indefinitely.

I recommend using "End of Life", because this is not the same concept as End of Service as used for zcashd and zebrad releases. End-of-Service dates carry no implication that the software is being discontinued. In fact zcashd for example might have both an End-of-Life date, and an End-of-Service date for the current release, and they would be different except for an expected-to-be-last release.

[daira]

Suggested change

	End-user / User
	The final user of the wallet. An individual, group or organization
	that makes use of the wallet application. Terms end-user and user are treated
	as synonyms for the purposes of this ZIP.
	End user
	The final user of the wallet. An individual, group or organization that
	makes use of the wallet application.

There is no need to define synonymous terms (unless one of them is an abbreviation of the other). Just pick one. Also, this is a noun phrase rather than a compound adjective and so it should not be hyphenated.

[daira]

Suggested change

	Credits: Kris Nuttycombe
	...
	Credits: Kris Nuttycombe
	Daira-Emma Hopwood

[daira]

Suggested change

	Title: Zcash Wallet Application End of Life / End Of Service Best practices
	Title: Best Practices for Zcash Wallet Application End of Life

("End of Life" should be hypenated if-and-only-if it is used as a compound adjective, so either this or "Zcash Wallet Application End-of-Life Best Practices".)

[daira]

Suggested change

	Zcash Wallet Applications might no longer be maintained, supported or serviced by
	their maintainter from a point in time onwards. This ZIP defines a set of best practices
	and recommendations to minimize the impact of the End of Service of a Zcash wallet
	application onto its current or potential users.
	Zcash Wallet Applications might no longer be maintained, supported or serviced by their
	maintainer from some point in time onwards. This ZIP defines a set of best practices and
	recommendations to minimize the impact of the End of Life of a Zcash wallet application
	on its current or potential users.

[daira]

Suggested change

	Pull-Request: TBD
	Discussions-To: <https://github.com/zcash/zips/issues/773>
	Pull-Request: <https://github.com/zcash/zips/pull/782>

[daira]

Please rename to draft-pacu-wallet-eol.rst (or draft-gindre-wallet-eol.rst if you prefer).

[daira]

Suggested change

	The key words "MUST", "REQUIRED", "MUST NOT", "SHOULD", and "MAY" in this
	The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this

[daira]

Suggested change

	Wallet applications that require end-users to maintain a sovereign custody of their private
	keys and/or the input they originate from (E.g: entropy bytes or BIP-39 style mnemonic seed
	phrases)
	Wallet applications that require end users to maintain exclusive control over and custody of
	their private key material (e.g. entropy bytes or BIP-39 style mnemonic seed phrase).

"Sovereign" isn't given a technical meaning, and in common usage it has many meanings. I think my suggestion more precisely conveys the intended one. We wouldn't consider a wallet to be self-custody if another party has a key that they can use, or if we technically keep custody of the key but provide a API endpoint for someone else to make arbitrary use of it. But that shouldn't exclude cases where the key material is backed up in such a way that we still maintain control over it, for example in a safety deposit box (this is a bit fuzzy but unavoidably so).

[daira]

Suggested change

	shorter lifecycles. There are many reasons for them to reach a point in time where they will
	longer able to keep functioning. Whatever the reason might be, this document considers that
	the result for end-users is indistinct: they will not be able to carry on their usual activities
	on the application once the EOL/EOS day comes. To that end, this ZIP will discuss the topic of
	sunsetting end-user applications gracefully by anticipating the moment as an invariant of any
	product's lifecycle.
	shorter lifecycles. There are many reasons for them to reach a point in time where they can
	no longer keep functioning. Whatever the reason might be, end users will not be able to carry
	on their usual activities with the application once the EoL day comes. This ZIP covers the topic
	of sunsetting end-user applications gracefully, by describing an application's End of Life as an
	anticipated stage of its lifecycle and making recommendations about how this should be
	communicated and implemented.

[daira]

Suggested change

	This document aims to ensure the ability for user to exercise complete sovereign self-
	custody of their keys and funds related to them. Although it will refer specifically to
	non-custodian wallets (or similar applications that handle Zcash keys), it can also apply to
	custodian applications reaching EOS/EOL. The goal of this ZIP is to ensure that the user is in
	control of its funds (or access to them) at all times, and that they can be provided ways to
	keep that access beyond a specific product EOS/EOL in a "hassle-free" and user-friendly way.
	Maintainers SHOULD always be eagerly looking to provide well-tested, dependable and mission
	critical use cases that produce an application feature that can be made available to users in
	the case of an EOS/EOL scenario.
	This document aims to ensure the ability for user to exercise exclusive self-custody of
	their key material and funds related to it. Although it will refer specifically to self-custody
	wallets (or similar applications that handle Zcash key material), it can also apply to
	custodial applications reaching End of Life. The goal of this ZIP is to ensure that the user
	is in control of their funds at all times, and that they are provided with well-tested,
	dependable, user-friendly, and hassle-free ways to retain that access beyond a specific
	product End of Life.

The last sentence was a conformance requirement on wallet maintainers, which shouldn't be in the Requirements section. It was also confusingly written. I think that moving "well-tested" and "dependable" to the preceding sentence is enough to convey what it was trying to say. I also think it would be an overspecification to require the means of retaining access to be a wallet "feature" as such. On the contrary, it's more likely to be an aspect of the design of wallet key material storage, which is needed anyway regardless of EoL.

[daira]

Suggested change

	Non-requirements
	================
	Wallets that are considered to be "in testing", "alpha", "beta" or "developer preview"
	programs and openly adversiting that to their users, therefore, not considered to be deployed
	to an open audience as a finished product that is intended for end-users MAY opt not to follow
	this practices. Althought, they SHOULD consider implementing them as part of their process to
	delivering the application into production.
	The requirement to follow these best practices should not be imposed on wallets that
	are considered to be in "testing", "alpha", "beta", or "developer preview" programs and
	are clearly advertising that to their users.

This is actually a requirement on the specification: it would be incorrect to impose the best practices on these wallets. It's not that the specification does not need to consider these wallets, which is what a non-requirement would be.

[daira]

Suggested change

	What is an EOS/EOL event?
	-------------------------
	End of Life / End of Service: refers to a point in time where the wallet
	software will no longer be actively maintained or developed, therefore its
	operation cannot be guaranteed anymore or terminated indefinitely.

This is just duplicating the definition in Terminology.

[daira]

Change all "EOS/EOL" to "EoL".

[daira]

Terms should only be capitalized if it's usual to do so, or if they're defined in Terminology and the document capitalizes all such terms. The latter is optional.