Re: New Work Item Proposal: Universal Wallet 2020

> A reference impl is rarely a gold standard in practice; often it is
slower or less scalable than other impls with better staffing. Also, even
if it is bug-free it often introduces additional features and/or
encumbering dependencies that are not part of the spec itself -- or it
omits important features because they would introduce those dependencies,
watering down the value prop.

+1 to this being closer to the working definition. Full disclosure, my
mental model of "reference implementation" was largely shaped by usage in
the java platform, which didn't have the weight of "gold standard".

Curious what precedents existing in w3c for what we're trying to do here.

On Wed, Jun 24, 2020 at 7:30 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> Extending some previous comments:
>
>    - A reference impl is rarely a gold standard in practice; often it is
>    slower or less scalable than other impls with better staffing. Also, even
>    if it is bug-free it often introduces additional features and/or
>    encumbering dependencies that are not part of the spec itself -- or it
>    omits important features because they would introduce those dependencies,
>    watering down the value prop.
>    - A reference impl creates a second oracle. The spec is supposed to be
>    the oracle for its own intentions.
>    - Code has a different maintenance lifecycle (and different
>    qualifications for contribution) compared to documents. A spec may be
>    perfectly stable after it releases, with no need to re-release for years --
>    but a reference impl might need to be updated on short notice to eliminate
>    a security vuln, for example. All of the features touted for ref impls
>    require that the code and the doc remain perfectly in sync. This is hard to
>    achieve periodically, let alone continuously. (Yes, it can be done. But now
>    spec writers are worried about CI/CD. Are we sure that the people
>    maintaining both types of artifacts will remain equally committed and
>    responsive and productive throughout the lifecycle of the concepts?)
>    - There are major political problems with a "gold standard" impl.
>    Whoever implements that one has undue influence -- or else you have
>    maintenance by committee, which is *really* hard.
>
> Despite these problems, I do see some value in this. But I think it only
> manifests if the scope of the impl is very small. A great example of a
> reference impl is the algorithms that the Unicode consortium published for
> UTF8 encoding and detection. These were not complete implementations of all
> things Unicode-related. They were not big projects that required complex
> maintenance. Rather, they were short (50-ish line) snippets of C code that
> made the abstract descriptions of the algorithms usefully concrete. Because
> they were narrow and crisp samples, there was little risk that they
> contained concept errors (the impact of the sort of unanswered questions
> Christopher is talking about). The consortium only produced such code for
> things where confidence was very high.
>
> Thus, a reference impl of a particular algorithm (say, resolution of
> relative URIs in DID docs) might make sense to me; a reference impl of
> issuance or verification of a VC is *way* too ambitious and politically
> fraught to clear the same bar.
>
>
> On Wed, Jun 24, 2020 at 8:06 PM Christopher Allen <
> ChristopherA@lifewithalacrity.com> wrote:
>
>> I know that I'm interested less in focusing on a reference implementation
>> as the first item for a group to focus on. I don't think we understand the
>> problem well enough for a "universal" wallet architecture.
>>
>> Joe Andrieu and I took a stab at this last year before #RWOT9 in Prague
>> as a topic paper, and feel like we just touched the surface. Take a look at
>> the topic paper:
>> https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/whats-wallet.md
>>
>> In particular, take a look at the diagram:
>> https://github.com/WebOfTrustInfo/rwot9-prague/raw/master/topics-and-advance-readings/media/ExpandedDecentralizedIdentityNetworkComponents.png
>>
>> We also identified in that paper 10+ missing areas that we didn't even
>> begin to break into pieces to put into the picture above. And I also feel
>> it is essential we also look at the issues of currency in wallets, as
>> clearly users expect to put credentials and money in the same wallets
>> (think not just your pocket wallet, but also Apple Wallet and Google
>> Wallet).
>>
>> I personally would like to see the community get together to better name
>> these different parts, or even better, name the connections between the
>> parts. Right now the three major platforms, much less small players like
>> BTCR, don't have any agreement on the naming conventions for the parts,
>> much less ready for a universal architecture.
>>
>> I'd hoped that at either RWOT9 or RWOT10 that we'd make some progress on
>> this, but clearly it will likely be a while before we get have another RWOT
>> to word together F2F, so figuring out how to do it virtually I think would
>> be a useful work item.
>>
>> — Christopher Allen
>>
>>