Federated network platform & protocols
A way to vet community information to build a better internet.

Any reference to specific technology here is to illustrate in concrete terms a possible implementation of the USHIN system specification. But in reality the implementation should continually closely follow our evolving understanding of requirements and the available technology. So far we understand some fundamental things about identity, tagging, data structures, data integrity, accountability, quality metrics, and annotation:

IDENTITY:

We want to support some concept of identity on at least two levels:

• users (at least authors) in the scope or namespace of a curator

• Curators in the scope or namespace of USHIN

Since the system spans multiple media, including offline, to fully specify the applicable methods of identification may be beyond the scope of this document.

Authentication of authors/publishers is delegated to curators. There is no global user identity within USHIN. Rather, each curator maintains a list of its authors/sources/users and authenticates them. User identity can be notated relative to curator, just as “user@host.com” identifies User within the namespace of host.com. Similar “user@organization” notation could be extended or re-used to identify e.g. “einstein@ushin” even though Einstein does not have an email address at USHIN but deposits his contributions in a dead drop from which USHIN personnel collect.

Likewise, curators authenticate to the USHIN network.

Short of specifying what technology would be used to implement that, we could say that it might borrow from the model of federated social networks such as Diaspora.

In general, given the existence and efficacy of public key (PK) cryptography, a signature by a given public key can be used to authenticate that one agent (which could be an individual person or organization) is the same agent as previously made particular statements or participated in particular interactions. And assertions can be made by third parties about that public key, in lieu of reference to any particular fully-identified person. Thus PK cryptography could be used to identify either a source to a curator, or a curator to the USHIN network.

TAGGING:

Each source must tag each piece of content with one of the eight elements of the Semantic Screen. USHIN has a prototype tag format, in which each tag begins with u[. This syntax may be modified or extended for compatibility with the syntax of Universal Resource Identifiers (URIs). For instance, depending on context, uri:ushin: or just ushin: could be prefixed to each u[.

DATA STRUCTURES:

Among the main data structures will be directed graphs, following the web’s structure, in which any page can point to any resource anywhere. One tool being used to develop USHIN is Freeplane, an excellent open-source mind-mapping program written in Java. Freeplane uses XML (a tree-structured document) as its native file format. A mind map can be represented as an outline or tree. But we want to generalize from a tree to a directed graph, to facilitate linking to, and search across, maps/trees contributed by other sources.

In the prior art, for the related problem of collaboration on mind maps, version control systems such as Git have been used. A Freeplane developer named Sébastien Georget released “Freeplane Collaborative Tools” integrating a Git client to check mind maps in and out of a Git repository. So this was able to implement collaboration by leveraging the Git protocols and their client and server code. But to merge versions with Git often requires more manual intervention than is ideal for a system of the size we hope to build.

We imagine a graph database may be among the more flexible types of database for servers in the USHIN network, so that it can support efficient addition and deletion of nodes, references among nodes, and search across graphs.

Some developers of Freeplane were consulted about making a next-generation distributed web-based system for collaborating on mind maps. So far the architectures share these elements:

– Client code (e.g. in Java or JavaScript)

– Server(s) maintaining a model of the mind-map

– Database

Phillippe Lewin, writing on the Freeplane developer forum, wrote:
“my architecture is:

– N Freeplane clients + 2-3 init scripts

– RabbitMQ

– Spring boot + Freeplane headless + Neo4j”

He described his init scripts:

“- one registers a map listener to publish all events on a RabbitMQ bus.

– one registers a subscriber to a RabbitMQ bus, receives update messages and updates the map in Freeplane.”

Another developer said that he planned to use:
Apache Cassandra for persistence
Apache Kafka for collaboration

PROTOCOLS:

The system will be built on web standard protocols, with an intention to maintain (and not break) support for Tor onion routing and other secure networking technologies such as I2P. Communication between USHIN curators should always use https or other secure connections and it is recommended that curators require these for communication with users, especially authors.

DATA INTEGRITY:

Early prototypes could implement the “verifiable public record” simply by having the curator sign the submission and return a copy of the signature to the source, so that the source could prove it had been contributed by a certain date and time. And in an early prototype, data storage could forego replication. But goals for the full system include a better solution to each problem.

A platform such as Ethereum might be used as platform to implement some aspects of USHIN, although this has yet to be fleshed out. Perhaps smart contracts on Etherium might be used to express some agreements between curators, and between sources and curators. Etherium’s “Swarm” may also be useful for sharing files between curators.

ACCOUNTABILITY:

Each source is accountable for her or his content: A curator agrees to cull it if the source does not respond to questions about it. This does not actually delete it. Similarly, curators are accountable to sources (to host their content and to disclose no more about them than agreed) and to USHIN (to uphold various agreements governing communication and storage of content).

QUALITY METRICS:

Quality metrics are per-user. Each user’s view of quality is computed from the graph, based on evaluations by a user and by sources or curators whom the user has evaluated as trustworthy. Each user can annotate each node to evaluate it according to USHIN’s Semantic Screen.

ANNOTATION:

The model in USHIN is more like the existing collaborative filtering and web annotation than it is like collaborative editing, in that users post their own content containing tags to refer to other users’ content. Contemporary systems implementing web annotation include Annotator.js, which support groups of members who can find one another’s annotations in a common database.