Sort query results alphabetically

[daveschaefer]

Let's sort the results alphabetically by notary name rather than by the order replies are received. This will help keep the UI consistent, and make make it less confusing when some replies are not received.

May help clear up issues like #107

[ghost]

I would go with: sort by most recent key seen longest (which becomes first key), with this key sort by length seen, then sort again by next longest key seen most recently etc. I think that would make more clear which key is the best quorum candidate. So something like that:

server5: -----d----- -----b-----
server2: ---d--- --b-- -----c------
server8: ---a----- ----c---
server1: ---a--- ---b-- ---d---
server4: --a-- ------c---------
server3: ---e--- ---d-----
server6: --f-- -d--
server7: 

Another option would be to find the key which is used by most servers as the recent key and then again sort by longest time seen. In that case all the servers with "a" would be the first ones.

And of course, the browser's key has to be the first entry.

[ghost]

Thinking about it a little more, here's my new proposal:

Update: the actual implementation is different in that in doesn't sub-group into "reached" and "not-reached" but this change isn't reflected in the graphic below. See the next comment.

1. group notary results by browser's key as most recent key → "browser keys"
2. group "browser keys" again by keys reaching quorum duration → "reached" + "not-reached"
3. sort sub-group "reached" and "not-reached" by latest key update
4. group all other results → "other keys A" + "other keys B"
5. apply step 2 and 3 again to each group of other keys
6. sort groups of other keys by the number of results that reached quorum duration (A=4, B=3)
7. append group of notaries with invalid signatures
8. append group of notaries with no response (time-outs)

[ghost]

I implemented this now in the tabinfo_restructuring branch (as it makes heavy use of UnderscoreJS). Apparently I misunderstood how required_duration is interpreted. get_quorum_duration() takes the oldest non-stale key and tries to find newer ones by looking at timestamp.end until a time-range of required_duration (e.g. 2 days) is reached. It doesn't matter however if the newer key changed before the old one ended. Is this a bug? E.g. in the green group consider the two results just before and after the "reached duration" line. Should they agree on the key even though the result after the line got a different key (coloured grey) at the time the other result got the last update?

[daveschaefer]

Very nice image! How did you make it?

My concern is that if we have a complex sorting method then non-expert users may get confused. Granted, most Perspectives users right now are probably more tech-saavy and security conscious than average, but I think it would be good to make a UI that everyone could understand.

How about some options so we have alphabetical sorting by default, and the option of using 'most recent key seen longest', saving the preference?

[daveschaefer]

get_quorum_duration() takes the oldest non-stale key and tries to find newer ones by looking at timestamp.end until a time-range of required_duration (e.g. 2 days) is reached. It doesn't matter however if the newer key changed before the old one ended. Is this a bug?

I will have to re-examine the code. Is this intended to be the same bug you reported in #137, or something different?

[ghost]

Very nice image! How did you make it?

I made it with LibreOffice :)

My concern is that if we have a complex sorting method then non-expert users may get confused. How about some options so we have alphabetical sorting by default, and the option of using 'most recent key seen longest', saving the preference?

Which information does alphabetical sorting add? Adding different sorting methods would just bloat the UI.

The standard user shouldn't have to look at the key history anyway. The only two reasons - I could come up with - why you would look at the history at all are:

1. You want to override a security exception given that the "key history pattern" doesn't look too suspicious.
2. You want to check why and how Perspectives decided to allow this site or how secure the override actually is.
3. You want to see a funny pattern :)

The current sorting method "by latency" and the proposed "by server-name" don't add any information for these use-cases. My consideration was to put "browser key" first (as any other keys don't matter anyway) and then again sort the "browser key results" by how much the notaries agree with the result. Thus for use-cases above you just have to check the first keys that are just beyond the stale line or just didn't reach quorum.

Is this intended to be the same bug you reported in #137, or something different?

No, but it is discussed in the "ambigious cases" in #137.