Starting the Hyperledger Indy test pool reachable on your WIFI network

Hyperledger Indy's README.md explains how to start the @Sovrin test pool on localhost using docker and in a docker network.


Doing it this way the pool is not reachable from clients that are not on your local machine.
Building a mobile app then has the problem that the phone can't talk to the test pool because neither localhost nor the private docker network are reachable.

Starting the test pool on a specific IP address

Dockerfile ci/indy-pool.dockerfile supports an optional pool_ip param that allows changing the IP address of the pool nodes in the generated pool configuration.

You can start the pool with e.g. the IP address of your development machine's WIFI interface so that mobile apps in the same network can reach the pool.

# replace 192.168.179.90 with your wifi IP address
docker build --build-arg pool_ip=192.168.179.90 -f ci/indy-pool.dockerfile -t indy_pool .
docker run -itd -p 192.168.179.90:9701-9708:9701-9708 indy_pool

To connect to the pool the IP addresses in /var/lib/indy/sandbox/pool_transactions_genesis (in docker) and the pool configuration you use in your mobile app must match.

Here is some Java code that creates a pool configuration. Be sure to put your IP address in there when you open the pool connection.

-------

Please contribute to Indy. Even if your company does not allow you to publish code please consider helping by improving the documentation.

Please sign-off your commits. git commit -s -m 'my first commit' README.md

Building an Android App with Sovrin

Thanks to the hard work of Mohammad Abdul Sami Sovrin enthusiasts now have support building libindy for Android in the master branch of our repo.


You can now build the libindy libraries for Android by just running a script. Yeah!
If you want to spare that building process you can download the libraries from Evernym. Thanks!

Now what? You have a libindy.so for arm, arm64 and x86, but how do you use it?

I have created an Android Studio sample application DroidLibIndy that you might use as a starting point (if you don't like reading blog posts).

Still reading? Here is a list of quirks you need in your flashy new Indy-App.

1. First you have to put the libindy library into the correct jni folder e.g.:
   app/src/main/jniLibs/arm64-v8a
   This other way to do this did not work for me.
2. Source code and Target compatibility have to be Java 1.8
   Otherwise CompletableFuture and other stuff do not compile
3. You need a network security policy because libindy secures its communication using zeromq and Android only accepts HTTPS as a secure protocol.
4. You might need a lint.xml to get JNA linked.
5. Copy libindy's Java wrapper code to your project using the path org/hyperledger/indy/sdk.
   

   cp -r ~pathto/indy-sdk/wrappers/java/src/main/java/org/ pathtoyourapp/app/src/main/java/

   I did not try the maven route here.
6. In your app's onCreate method set the environment variable 'EXTERNAL_STORAGE'
7. Of course you need to have all the dependencies configured in your build system.

As always: PRs are welcome! Please contribute to libindy. It's easy.

Have fun exploring Hyperledger Indy on Android!

Building openssl for libindy and Android

Building of the indy-sdk for Android is currently not supported out of the box. The underlying issue is that libindy is implemented in Rust and the Android platform is currently not supported.

To build openssl for Android on your Ubuntu system take the following steps:

1. Setup your build environment - missing tools are likely to be noticed by "configure" so you can install them then 
2. Download openssl (I used version 1.0.2n) and unpack it.
3. Setup the Android toolchain (command line tools are enough) and NDK toolchain for e.g. arm
   

   ${NDK_HOME}/build/tools/make_standalone_toolchain.py  --api 14 --arch arm  --install-dir ${NDK_TOOLCHAIN_DIR}/arm --stl=libc++

   or for arm64
   
   ${NDK_HOME}/build/tools/make_standalone_toolchain.py  --api 21 --arch arm64  --install-dir ${NDK_TOOLCHAIN_DIR}/arm64 --stl=libc++
4. Edit the script setenv-android.sh
   
   I have these values:
   _ANDROID_NDK="android-ndk-r16"
   _ANDROID_EABI="arm-linux-androideabi-4.9"
   _ANDROID_ARCH=arch-arm
   _ANDROID_API="android-14"
5. Run the script '. setenv-android.sh'
6. run this:
   ./config shared no-ssl2 no-ssl3 no-comp no-hw no-engine      --openssldir=/usr/local/ssl/arm/$ANDROID_API --prefix=/usr/local/ssl/arm/$ANDROID_API
7. Edit Makefile and add
   "--sysroot=/home/ignisvulpis/NDK_TOOLCHAIN_DIR/arm/sysroot/"
   to CFLAG and DEPFLAG
   Remove -mandroid where it occurs
8. Run make. This creates the libraries in the current directory
   make build_libs
9. Make install fails because the application openssl is not build for Android.
   So put a comment # in front of the install command.
   "#@set -e; target=install; $(RECURSIVE_BUILD_CMD)" in the target "install_sw". "make install" now installs the include files and the libs.

The include files are needed to compile libindy. The libraries need to be put into a place where the Rust build system can find them.
 

Minimize Ladder Length over Wall

Some time ago somebody had to solve this math optimization question for their studies and told me about it.

So there is a wall with height h, which has the distance a from a very high "building" and your task, should you accept it, is to find the shortest ladder over the wall that touches the ground and the "building".

So the function to minimize is L = sqrt((x+a)^2+(h+y)^2).
Because we know that y/a = h/x it follows that y = ah/x.
Using this the length become L = sqrt((x+a)^2+(h+ah/x)^2)
The minimum of that function is not changed if we leave out the sqrt and the derivation of (x+a)^2+(h+ah/x)^2 is (2 (a + x) (-a h^2 + x^3))/x^3
So the minimum x is where this function equals zero, which is if x³ = ah²,
and the length then is L = (a^(2/3) + h^(2/3))^3
 
Now the thing that I find strange. Please look at this drawing (which is not really correct because the two "y" do not have the same length).

If the angle ACD is 90° then the ladder has minimal length!
We know that ah=xy, so let's square that: a²h²=x²y² and because ACD is 90° xa=y² which yields

a²h²=x²xa and that gives x³=ah² which is exactly what we got by using the calculus.

Do you have a geometric explanation why L is minimal if ACD is 90°?


 

CSS Oddities: anonymous inline whitespace nodes

I learned something today. All started with a @Twitter post by @supersole that there is a new feature in @firefoxnighly that now allows debugging "anonymous inline whitespace" nodes in HTML pages.
https://blog.nightly.mozilla.org/2016/10/17/devtools-now-display-white-space-text-nodes-in-the-dom-inspector/

The post claims that imgimg on the page is rendered differently than imgcrlfwhitespacecrlfimg.
I could not believe this. That is stupid right? Which web developer would expect any difference?

Well, it seems that CSS rules - being what they currently are - lead to this unexpected difference.
The CSS spec describes the algorithm to process the HTML here in Phase I: Collapsing and Transformation.
In the second HTML fragment the whitespace is deleted by step 2 which gives us 
imgcrlfcrlfimg.
Step 2 tells us to handle segment breaks ("crlf"). That is described in the Segment Break Transformation Rules.
Those rule give us imgspacespaceimg. Which is then again continued to be processed by the Phase I steps 3 and 4. Step 3 does nothing in this example.

Step 4 reads:

Any space immediately following another collapsible space—even one outside the boundary of the inline containing that space, provided they are both within the same inline formatting context—is collapsed to have zero advance width. (It is invisible, but retains its soft wrap opportunity, if any.) 

 So the remaining two spaces are turned into one (or two - I don't care to check) empty text nodes with zero width but with "soft wrap".

Good to know - maybe. Is this a feature? I expected that everything between two HTMLElements that matches (whitespace)* is completely removed and not inserted into the rendering tree.

Maybe this should be discussed here?: https://github.com/w3c/csswg-drafts/issues
Not my cup of tea.

Thanks to @upsuper who pointed me to the relevant specs.

Twitter Markup

Twitter Cards are around for some time now and I recently wondered how commonly used they are?

There is a nice blog post on Blogger on how to integrate them there but clearly there should be ways for e.g. newspapers to promote their reports by providing summaries and a main image and author information that is not @Twitter specific?  Microformats and schema.org to the rescue?

What does Google do? It seems that JSON-LD is the recommended format.

How would a Twitter Card look in JSON-LD?

Twitter Cards or Rich Cards or @w3c Cards?

Time to standardize!

New Firefox Add-On: QRCode Login

Current login mechanisms suffer from missing support by browsers and sites.
Browsers offer in-browser password storage but that's about that.
Standardized authentication methods like HTTP Digest Authentication and HTTP Basic Authentication were never really accepted by commercially successful sites. They work but the user experience is bad especially if the user does not have an account yet.

So most sites are left with form-based authentication were the site has full control over the UI and UX. Sadly the browser has little to offer here to help the site or the user other then trying to identify signup and login forms through crude guesses based on password field existence.

There is no standardized way for sites and browsers to work together.
Here is a list of attempts to solve some of the above issues:

• All those NASCARs suggests navigator.openid
• Mozilla's Persona / BrowserID suggests navigator.id
• The OpenID Foudation's AccountChosser uses localstorage and redirects
• The W3C Credentialmanagement WG uses navigator.credentials
• Google's X-Auto-Login utilizes HTTP headers
• Google's requestAutocomplete for Google Wallet is proprietary
• WebID uses URIs to identify entities
• XRI / inames gives you more than =jane
• ...

Federations have their drawbacks too. Even Facebook login went dark for 4h a while ago which left sites depending on Facebook without user login.

In general there is this chicken-egg problem:
Why should sites support new-mechanism-foo when there is no browser support.
Why should browsers support new-mechanism-foo when there are no sites using it.

Then there are password stores. I use passwordsafe to store my password in one place. If I do not have access to that place (PC) then I can't login. Bummer.
Others use stores hosted on the Internet and those usually support most browsers and OSses through plugin/addons and non standard trickery.
I never could convince myself to trust the providers.

So. Drum-roll.
I started to work on a mechanism that has a password store on the mobile which allows you to login on your PC using your PC's camera.

The user story is as follows:

1. browse to a site's login page e.g. https://github.com/login
2. have my Firefox addon installed
   https://github.com/AxelNennker/qrcodelogin
3. click on the addon's icon
4. present your credential-qrcode to the PC's camera
5. be logged in

Here is an example qrcode containing the credentials as a JSON array
["axel@nennker.de","password"]:

The qrcode could be printed on paper or generated by your password store on your mobile. To help the user with the selection of the matching credentials the addon presents a request-qrcode to be read by the mobile first. This way the mobile ID-client can select the matching credentials.
(If you don't like to install addons to test this and for a super quick demo of the qrcode reading using your webcam please to to http://axel.nennker.de/gum.html and scan a code)

What are the benefits?

• no need to change the site's javascript, html markup or https headers. No changes whatsoever needed on the accepting site.
• no need to have an extra backend server to store your credentials.
• no need to have an extra backend server to help mobile and browser to communicate.
• no need for an enhanced browser or client. no need for the browser to know about new markup, new javascript APIs or HTTP headers.

What are the drawbacks?

• reading the qrcode from the mobile's screen very much depends on the light and camera. Printed credentials work reliably but qrcode on mobile screens sometime give me headaches.
• You have to install the addon.
• This is an alpha version. Your mileage may vary.

Screenshots:

Login page at githup with addon installed:

Screen after pressing the addon's toolbar icon. The qrcode helps the mobile ID-client to find the matching credentials:

Screen showing the camera picture which is scanned for qrcodes:

This is clearly only a first step but I believe that it has potential to be a true user-centric solution that helps me and you to handle the password mess.