Re: [saag] The Mathematical Mesh

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Apr 24, 2019 at 2:01 PM Ben Laurie <[e-mail]> wrote:

>
>
> On Wed, 24 Apr 2019 at 18:49, Phillip Hallam-Baker <[e-mail]>
> wrote:
>
>>
>> The reason that the World Wide Web exists at all is that Tim Berners-Lee
>> ignored the sage advice of the hypertext community that referential
>> transparency was essential and pressed ahead with 'scruffy links'. Nobody
>> did usability testing to decide whether the gopher or Web UI was the
>> approach to follow until long after we knew the answer.
>>
>
> This is a clear case of survivorship bias. The users did the usability
> testing. WWW survived (despite being technically terrible in many ways),
> the competitors did not.
>

The Web had 100 users in the fall of 1992 when it was first demonstrated in
public. There were at least two dozen competing network hypertext systems,
most of which were far better financed than the Web which had two full time
staff at the time.

Nine months later the Web had over a million users and it was game over for
every other network hypertext scheme apart from Acrobat which had already
begun merging itself with the Web to survive.

There was rather more than survivor bias at work there. One of the biggest
differences between the Web and everything else was that Eric Binna paid
immense attention to the quality of his software distributions. He provided
binary distributions for a start and the code compiled from source.

We paid a great deal of attention to usability but we never had the
resources to test any of it. There was never a testing lab at CERN for a
start. Or at NCSA as far as I am aware. Come to think of it, when VeriSign
acquired the old Netscape HQ, I pushed for the construction of a usability
lab. Which means that there wasn't one in the building when we moved in.

Right now, I have no means of knowing if an email from my bank is actually
>> an email from my bank or not. And that should be considered a problem. The
>> problem I have with discussions of usability is that the argument is made
>> that because we might not be able to serve every user we should just give
>> up and never try to change anything.
>>
>
> Well, the problem I have with discussions of usability is the argument is
> made that we should leave that until all the tech is figured out, or that
> we don't need to bother because the thing is obviously better. Going from
> .1% to 1% is clearly an improvement, but it is not a solution.
>

Like I said, I am more than happy to accept input on how to do UI better.
But I am not going to be blocked on those resources. At this point I have
one employee and a seven figure budget. To start thinking about UI testing
I need to have more developers and a bigger budget.



> BTW, my original question was not about QR codes (though I have my doubts
> about those), but about this assertion about usability: "Otherwise, there
> are many existing protocols that make comparison of 15-30 character base 32
> encoded strings as the basis for mutual authentication and these have
> proved effective and acceptable."
>

I have entered product activation keys and lived. Adobe managed to sell
software with that requirements for decades. So they are not a show stopper
for at least some part of the audience. I am requiring only comparison of
two codes, not entry.

I accept that this is not the ideal approach and in the spec I suggest
using BASE32K encoding based on dictionaries of words or images. Since the
connection mechanism only requires comparison for equality, we don't have
to be restricted to something that can be entered on a keyboard. Images
would be the ideal of course because they can be language independent. 'Are
these nine pictures the same' is a pretty easy question to answer. The work
factor for the UDF approach would be (9*15)-8 = 127. 2^127 is sufficient
for most purposes. Comparing nine pictures for equality is relatively
straightforward.

I haven't gone into this in detail as yet, but my rough strategy for
managing the dictionaries is to

1) Sort the entries into a canonical sort order
2) Form a Merkle tree of the result.
3) Publish the apex of the tree in some tamper-proof fashion.

This avoids the need to store the entire dictionary on every device which
is important even for unconstrained devices. The image dictionary is going
to be huge and word dictionaries have to be customized to the user's
language.


It has not escaped my notice that I could use this as a funding mechanism
for the Mesh itself. The million dollar image dictionary. Companies could
pay to contribute images to the corpus, part of which could be reserved for
advertising. If the system was used a million times a day, $1 would buy
nine exposures of the image per day in perpetuity. Or until someone decided
to do an advert-free version.