Providing usefulness while WebRTC performance/support solidifies

[jure]

There are a few issues with the performance of WebRTC in Chrome (see issue #7) and it's diminishing the usefulness of Scholar Ninja, which has its own bugs too. While the distributed WebRTC Chord-based network is being developed and Chrome-side bugs fixed (https://code.google.com/p/chromium/issues/detail?id=392651, https://code.google.com/p/chromium/issues/detail?id=373690) there are still a lot of things we can do.

In the next release, the distributed network part will be temporarily disabled but a different functionality will be added: searching through a combination of APIs (PLOS, EuropePMC, eLife, PeerJ, DOAJ).

At the same time, a part of the distributed indexing functionality will be retained, in order to index links from scientific papers to either other scientific papers or general URLs. This is a lot easier to structure compared to full-text parsing, and will allow us to build a graph database of connections between papers and other resources, for example:

subject: 10.1371/journal.pcbi.1003537
predicate: software
object: https://github.com/CompEvol/beast2

and

subject: 10.1371/journal.pcbi.1003537
predicate: paper
object: 10.1053/j.gastro.2009.02.006

and so on.

Each browser extension could be fairly easily used for signalling to the central graph database any new links it finds. Within the context of the extension (the content script specifically), this enables us to detect whether we are on a page that is referenced in the graph and if we are, suggest other things in the graph based on that. For example, "You might be interested in these other repositories:" directly on a GitHub page, which shows other repositories connected with the same papers as the parent repository.

WIP.