On Dec 21, 2017, at 2:58 PM, jungle Boogie <jungleboog...@gmail.com> wrote: > > 3) Small green lock, like you see in your browser for https > 2) Unlocked & red > 1) Locked, but grey
That’s going to make the red-green color blind unhappy: https://en.wikipedia.org/wiki/Color_blindness#Red%E2%80%93green_color_blindness There are browser plugins to simulate the various forms of color blindness. It’s fascinating to play with them for a while. I’d recommend designing three distinct black-filled SVG icons, then style as follows: 1. Drop the opacity of all signedness-state icons to blend it with the background, giving a darker form of the skin’s BG color: svg.signState { opacity: 0.4; } 2. Change the inner fill color of the icons based on applied classes: svg.signed.inner { fill: deepskyblue; } svg.forged.inner { fill: firebrick; } The unsigned state has no tint in this example, but it should still have a distinct CSS class so that skin authors can recolor it to suit their taste and accessibility requirements. >> And where would they be placed? Beside the username? Works for me. > I think that's a good starting point, perhaps left of the username. I think right, simply because it’s currently ordered most-clicked to least-clicked, more or less. > How are the signatures verified? There are lots and lots of ways because there is no single best answer. Some ideas: 1. Add a column to the Fossil users table. Add a text input field on Admin > Users accepting a GPG public key. Also add an Admin preference for whether this column syncs between clones by default, which effectively controls whether trust is transitive. Downside: the Fossil Admin gets to maintain yet another authentication system. 2. Pull from a PGP key server by email parsed from the current Contact Info column. Downside: all the problems of PGP email. 3. Delegate identity to another provider via any of https://en.wikipedia.org/wiki/Federated_identity https://en.wikipedia.org/wiki/Identity_management_system You might need a pluggable architecture so that Fossil can ship with the first two, but BigCorp can swap in an LDAP or RADIUS back end. It *might* be sufficient to allow this to be done via Tcl, as that should give you access to quite a few protocol clients, and the ability to write more at need. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
